Cannot attach a file to a ticket, it seems because of file system permissions

[leo.devida@…]

I created a ticket using Trac, and then tried to attach a file to it. It failed, probably because of file system permissions, but I think the problem wasn't properly reported, and it just threw an error.

Since I cannot attach the file to the ticket, or find out what's wrong, I decided to create a ticket here. The About Trac link says its version 0.10dev

Thanks

Traceback (most recent call last):
  File "/usr/local/python2.4/lib/python2.4/site-packages/trac/web/main.py", line 316, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/python2.4/lib/python2.4/site-packages/trac/web/main.py", line 201, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/python2.4/lib/python2.4/site-packages/trac/attachment.py", line 343, in process_request
    self._do_save(req, attachment)
  File "/usr/local/python2.4/lib/python2.4/site-packages/trac/attachment.py", line 475, in _do_save
    attachment.insert(filename, upload.file, size)
  File "/usr/local/python2.4/lib/python2.4/site-packages/trac/attachment.py", line 180, in insert
    os.makedirs(self.path)
  File "/usr/local/python2.4/lib/python2.4/os.py", line 156, in makedirs
    makedirs(head, mode)
  File "/usr/local/python2.4/lib/python2.4/os.py", line 159, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/home/brs/isode-trac/attachments/ticket'

[cboos]

This is a local configuration issue.

But you're right, the problem wasn't properly reported.

I suggest that we catch the above OSError, raise some a specific TracError (TracInstallError?) and render that error in a specific "install_error" template, making it obvious that this is a local installation error that the local Trac administrator should fix.

[rblank]

This still happens on 0.11-stable, but the error message is even less helpful: "Failed to create unique name: {path}.100.{ext}". This is due to create_unique_file() incrementing the index appended for duplicate file names for all OSError, including permission errors.

Replying to cboos:

I suggest that we catch the above OSError, raise some a specific TracError (TracInstallError?) and render that error in a specific "install_error" template, making it obvious that this is a local installation error that the local Trac administrator should fix.

Is this still the preferred way to solve this issue? If yes, I would like to try and implement it.

[cboos]

Replying to rblank:

Replying to cboos:

I suggest that we catch the above OSError, raise some a specific TracError (TracInstallError?) and render that error in a specific "install_error" template, making it obvious that this is a local installation error that the local Trac administrator should fix.

Is this still the preferred way to solve this issue? If yes, I would like to try and implement it.

IIRC what I had in mind, was that this class of local permission errors (or similar, like disk full) would lead the user to an error page where he could create an issue on the local Trac, using a "Create" button like we have in the normal error.html, but simpler, without the backtrace.

Any other idea welcomed (and as a first step, simply catching the first permission error, reporting it as such, would already help).

[ebray]

Replying to cboos:

IIRC what I had in mind, was that this class of local permission errors (or similar, like disk full) would lead the user to an error page where he could create an issue on the local Trac, using a "Create" button like we have in the normal error.html, but simpler, without the backtrace. Any other idea welcomed (and as a first step, simply catching the first permission error, reporting it as such, would already help).

Though creating a ticket on the local Trac would be nice, it would be even nicer to somehow make this configurable so that these local errors can be reported to a specified Trac environment. That is, users wouldn't have to junk up their own Trac instance with such service tickets, but could instead submit them to a local service Trac instance.

[cboos]

Good point, that setting could also be used in the normal error.html page.

[project]
trac_for_trac = http://admin/trac

or metatrac? ;-)

[osimons]

We already have a setting for the owner email - would it not be more natural for that class of errors to report to the owner by email? Even if there are multiple Trac projects, some errors will likely affect all projects equally - including any 'master' projects.

[cboos]

Replying to osimons:

... some errors will likely affect all projects equally - including any 'master' projects.

True, but any kind of error reporting could also suffer from bugs, including automated error reporting by e-mail. Imagine a problem which would somehow trigger at every user request - that would end up spamming that admin e-mail account a lot, or worse depending on the robustness of the smtp setup. Offering the possibility to report the error in Trac itself (or a dedicated one as Erik suggested) also goes together with the possibility to search for duplicates (through a Search button, see error.html). Or the user can decide to pick up his phone instead, or do anything else. Somehow I have the feeling that this is a better option than having an automated error report through e-mail.

Note that if you where instead thinking of offering the user with the possibility to send that error report, then of course my objections to the automated part don't apply, but I don't see how this is better than creating a ticket (the user couldn't even check if that problem has not been reported before).

[ebray]

Replying to cboos:

Good point, that setting could also be used in the normal error.html page. {{{ [project] trac_for_trac = http://admin/trac }}} or metatrac? ;-)

Yes, definitely for the normal error.html page too. We modified it by hand anyways, and if we hadn't you would be getting a great deal more "database is locked" tickets, as well as tickets for an error in one of our internal plugins.