Error when uploading files - Mantis 1.0.1

dsavercool · Post by **dsavercool** » 10 Apr 2006, 17:05

"APPLICATION ERROR #503

Invalid upload path. Directory either does not exist or not writable to webserver"

I migrated our old working version of Mantis (19.2) from an older machine running Red Hat 8, to a newer machine running Fedora Core 4 and Mantis 1.0.1. I figured that migrating over all the config files would have handled settings, but I receive the above error whenever I try to upload files. All of the originally uploaded files are still linked properly and download just fine.

Please help!

chschulz · Post by **chschulz** » 11 Apr 2006, 07:18

I get the same error (but other error number):

APPLICATION ERROR #15
File upload failed. File is not readable by Mantis. Please check the project settings

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Also, already existing file attachments do no longer appear. Already existing attachments appear now as information under Additional Information. There I only see something like:

File: abo_de_contentbuilder-EN.txt
File: default_contentbuilder-EN.txt

dsavercool · Post by **dsavercool** » 11 Apr 2006, 13:53

I can view my desired upload folder if I goto it. The folder is called /data. So if I goto 192.168.1.101/data/ I can view all of my files, but I can't find where this is defined in the config files, or what permissions I need to allow this to work. The folder itself is the frowned upon 777 just so I can test this.

Please help.

dsavercool · Post by **dsavercool** » 11 Apr 2006, 14:30

Mainly I just want to know where you define the upload directory, and if you have to add anything to config files to allow people to upload there.

Narcissus · Post by **Narcissus** » 11 Apr 2006, 14:40

I believe the upload path for attachments is (can be) different for each project.

Check out the 'manage projects' page for each project and check the 'uploaded file path'.

It may be possible that there's a default path that gets used if these project values aren't available, but I don't know...

Lincoln.

atomoid · Post by **atomoid** » 14 Apr 2006, 17:25

See this other thread too http://forums.mantisbt.org/viewtopic.php?t=504

I find that the error is different depending on the file size:

This never occurred in Mantis 1.0 (mere coincidence?)
My configs all seem correct (and havent changed since 1.0):
php.ini: post_max_size = 90M
php.ini: upload_max_filesize = 90M
my.cnf: max_allowed_packets = 90M
config_inc.php: $g_max_file_size = 90M (yes, my $g_file_upload_method = DATABASE;)

files less than about 10mb upload just fine.

If i try to upload 41mb file:
"Fatal error: Allowed memory size of 199229440 bytes exhausted (tried to allocate 62914320 bytes) in /home/httpd/mantis/core/error_api.php on line 319"

If try something less, like a 15mb file, i get:
"APPLICATION ERROR #401
Database query failed. Error received from database was #2020: Got packet bigger than 'max_allowed_packet' for the query: INSERT INTO mantis_bug_file_table
(bug_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, content)
VALUES <a bunch of binary chars fill up the browser>

dsavercool · Post by **dsavercool** » 17 Apr 2006, 14:33

I managed to get this resolved, made a new directory and moved the files into it. May have had something to do with the folder being copied from the different Linux system.

thraxisp · Post by **thraxisp** » 17 Apr 2006, 23:09

atomoid wrote:See this other thread too http://forums.mantisbt.org/viewtopic.php?t=504

I find that the error is different depending on the file size:

This never occurred in Mantis 1.0 (mere coincidence?)
My configs all seem correct (and havent changed since 1.0):
php.ini: post_max_size = 90M
php.ini: upload_max_filesize = 90M
my.cnf: max_allowed_packets = 90M
config_inc.php: $g_max_file_size = 90M (yes, my $g_file_upload_method = DATABASE;)

files less than about 10mb upload just fine.

If i try to upload 41mb file:
"Fatal error: Allowed memory size of 199229440 bytes exhausted (tried to allocate 62914320 bytes) in /home/httpd/mantis/core/error_api.php on line 319"

If try something less, like a 15mb file, i get:
"APPLICATION ERROR #401
Database query failed. Error received from database was #2020: Got packet bigger than 'max_allowed_packet' for the query: INSERT INTO mantis_bug_file_table
(bug_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, content)
VALUES <a bunch of binary chars fill up the browser>

The first message is quite clear, Apache/PHP is running out of memory by retrieving the file before storing it in the database, then failing in the error handler trying to print an error. I would suggest that you need to allocate a minimum of 256M to PHP (in it's config file).

The latter error needs to extent the size of the packet allowed by MySQL. Have you restarted the server after changing the setting?

For files of this size, it's much faster and more efficient to store them in the filesystem.

atomoid · Post by **atomoid** » 17 Apr 2006, 23:21

Many thanks thraxisp,

i'll give that a try.
As far as setting the file storage to go to the filesystem (i currently have the default setting, which is: "database") i wasnt able to find any notes on how to do this so i didnt try it out. im not exactly a unix admin, but im guessing i just set the variables in the config_inc.php and it wil all work out as long as the destination directory exists?

atomoid · Post by **atomoid** » 20 Apr 2006, 18:34

when i set $g_file_upload_method = DISK;

...then what happens to the existing file stored in the db? i guess they will stay in the db. somehow i'd like to 'clean' the db so everything is in the folder and the db will only contian table data. so how can i dump these preexisting files out and re-hook them up to be externally stored files? must i do it manually one bug at a time, downloading and reattaching all the attachments?

...will small image files such as screen shots which i set to display in the Mantis browser take a performance hit ...or improvement? (i guess ill find this out).

Thanks for all your help so far, its appreciated!

Narcissus · Post by **Narcissus** » 21 Apr 2006, 02:10

If you go to http://your_server_name/mantis/admin/system_utils.php (assuming you still have your admin directory) there's an option there to move attachments from the database to disk.

I've never used it before so I don't know what the 'prerequisites' are, but I daresay it will tell you if there are any problems.

Also, I don't know if it actually deletes the files from the DB or not... I just had a quick scan over the code and couldn't see either way.

Anyway, that should get you started, at least!

Lincoln.

atomoid · Post by **atomoid** » 12 May 2006, 02:14

I set my
$g_file_upload_method = DISK;
$g_absolute_path_default_upload_folder = '/home/httpd/mantis-files/';

Yes, this attachment method appears to prevent the file upload errors !!
---------------------------------

Its odd that the files that get uploaded to my directory are a bunch of binary hash junk (to me anyway), as i was hoping for the original intact and useable files that i could access outside of Mantis.

Is there anything i can do about this aspect?
---------------------------------

However, im having an issue with the
mansits/admin/system utils: "move attachments to disk"
I get errors for all of them, one example:
46 UVMappingEditor.jpg Destination /home/httpd/mantis/ not writable

I'm expecting that it should be trying to write to my specifed upload folder as noted above, and not merely dumping them to the 'mantis' folder as it looks like its trying to do.

Im hoping that it will keep the links active so the files can be downloaded, but i didnt really see any documentation on the admin stuff in the manual. is it somewhere else?

Since its not possible to download any attachments from the bugs anymore, since they come out 0K (thats zero K, which is definately not OK) (im assuming this will work when the data finally gets Moved this way), ive had to reset it back to "DATABASE" for now.

atomoid · Post by **atomoid** » 01 Jun 2006, 19:29

Finally got back to this and got it working, with a few nits:

Regarding the problem where i still couldnt upload files larger than about 9mb even though i had changed all the php.ini, my.cnf, config_inc.php stuff and our overworked IT experts and their horses couldnt fix it either.

Was fixed by setting the config to save attachments to DISK rather than database:
$g_file_upload_method = DISK;
$g_absolute_path_default_upload_folder = '/home/httpd/mantis/mantis-files/';

This is great, however, using the mantis/admin/ tools to move the existing datbase embedded attachments to disk, i discovered that there are a few quirks:

-Bug?- : Moving the attachments fails with a "not writeable" error.

It turned out that what fixed this problem was using 'Manage' section and changing each Project's "Upload File Path" to the location on disk:
/home/httpd/mantis/mantis-files/
After doing so, then the move will be successful.

- The attached files are Removed from the database SQL file (slimming it down substantially) and placed in the destination directory, so of course the resultant SQL file's `mantis_bug_file_table` now holds a pointer to the file on disk, and the binary is no longer stuffed in that table column.

-Bug?- The 'moved' files appear in the directory as they should, in that they are useable regular files. But newly uploaded files however, appear to be in binary, and they are not compressed, they appear with confounding hash names such as "c368f2e128c883981f150515bc12a38c"

- Is there any way to change this so that the files are stored in useable form on disk? It seems that the admin script did this. Is this a bug or is it intentionally hashed for some security reason?
(im using Mantis 1.0.1)

atomoid · Post by **atomoid** » 05 Jun 2006, 23:51

I set my uploads to DISK.
..then i used the admin tool to "Move Attachments to Disk".

As a result, many files that had duplicate filenames, such as screenshots with filenames like "picture1.png" etc. were overwritten. It turns out that when the files were dumped, it overwrote any that may have had duplicate names int he same destination directory, resulting in the loss of valuable data from the bug reports.

So perhaps thats why the filnames in the upload to DISK type operation are hashed. so that something like "picture1.png" becomes the duplicate-resistant "c368f2e128c883981f150515bc12a38c"

I'd hope at some point that the "Move attachments to Disk" function could be fixed. As this is serious data loss. Until such time that it is fixed, perhaps a caveat regarding this pitfall should be posted below the function description in the script page (system_utils.php) that the function is called from. The script should probably also have a confirmation dialog before it executes. This same problem may also affect the "Move Project files to Disk" as well but i havent tried.

Anyway, if it were possible, id suggest instead appending the hash to the existing filename, not entirely replacing it, that way the user could still manually figure out what the file was. so it could be something like: "c368f2e128c883981f150515bc12a38c_picture1.png"
just a suggestion...
I added a bug for this problem http://bugs.mantisbt.org/view.php?id=7176

GrandeLand2 · Post by **GrandeLand2** » 17 Mar 2010, 20:11

Atomoid or anyone. I have successfully saved the documents to disk mimicking the settings from all the suggestion in the post but with one caveat. I can only attach a document with a create a new "Report Issue." If the issue has already been created and I attempt to add a document after the fact I get one error message that says "access denied" [proceed] button underneath it. Any ideas?

Mantis Bug Tracker - Forums