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'

[Christian Boos]

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.

[Remy Blank]

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.

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

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.

[Remy Blank]

Replying to 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.

This has been fixed in [7810] by checking that the OSError is actually an EEXIST. Permission errors now still generate an internal error, but the right exception message is now reported.

For non-admin users, this will show the short form of the internal error page, with the option to create a ticket on the local Trac. Admin users still see the complete traceback and have the option to create a ticket on Trac's Trac, which is not yet optimal.

I see three remaining improvement possibilities:

• Allow customizing the Trac URL where normal users can create a ticket for internal errors.

• For TRAC_ADMIN users, add a button to the internal error page for creating a ticket at that same URL, and reformulate the section about creating a ticket with Trac to say something like "If you are sure that this is a bug in Trac itself, you should |Create| a new ticket at the Trac project site…"

• Always display the short error page (without the backtrace) for certain exception types (OSError, OperationalError from the DB, …), as they most likely are installation issues. I'm not sure about that one, though.

Opinions?

[Remy Blank]

0.11-stable: Add option to report an internal error to another Trac instance

[Remy Blank]

The patch above addresses the first two points in comment:10:

• [project] admin_trac_url allows pointing to an admin Trac instance for reporting internal errors (use "." for the local Trac instance (default), or set to empty to disable).

• Non-admin users get the option to report the error on the admin Trac.

• Admin users can report the error on the admin Trac if it is not the local instance. Additionally, they can report it to the Trac project as before. Also, slightly more emphasis is given to the fact that internal errors are often local installation issues.

[Remy Blank]

I'd like to get this into 0.11.3.

[Remy Blank]

Patch applied in [7825].