Uploading files

From The Scuba Wiki

There are several potential stumbling blocks in getting file upload working correctly

• php.ini file usually is here: /usr/local/lib/php.ini

Frequently Asked Questions

Q: How do Wikipedia and other Wikimedia projects have a "Select a License" menu on the file upload page? How do we add a similar menu to our own wiki?

A: The Mediawiki:Licenses page is where the contents of the menu are defined. If you add options to that page the menu will magically appear.

Q: Why do I get this error, what can I do? Is there something I can put into LocalSettings.php?

Fatal error: mime_mMagic.php on line 506

A: Try adding the following line to the LocalSettings.php:

$wgMimeDetectorCommand = "file -bi";

Q: How do I enable uploading files on my MediaWiki installation?

• Add:

$wgEnableUploads = true;

to your LocalSettings.php. This causes an "Upload File" link to be displayed in the "toolbox" menu. Be sure there is no line:

$wgEnableUploads = false;

lurking elsewhere in your LocalSettings.php; such a line may be present by default (version 1.7.1).

• Note that in MediaWiki versions up to 1.4 the line to add to LocalSettings.php was:

$wgDisableUploads = false;

• Make sure the 'uploads' or 'images' directory is writable by the web server.

Don't forget to log-out and log-in again to see the "Upload file" link (this happens with 1.4.7 version).

Q: After setting:

$wgEnableUploads = true;

in LocalSettings.php, I still can't upload any image files. I get the following error (using MediaWiki 1.5.6):

Could not copy file "/tmp/phpWdGsMs" to
"/var/www/vhosts/railgunn.com/httpdocs/pipelinewiki/images/temp/20060317020027!Weird_uvs.jpg"

A: Make sure the permission in all the files below images are all set to rwx on linux/unix (use <code>-R to change files in subdirectories recursively):

chmod -R 777 images/

and - if php safe_mode is on - make sure that /images and all its subdirectories are owned by the same owner as the main script (index.php).

A: It is also possible that your host has disabled the allow_url_fopen property in the PHP server. Try to contact your host in that case.

Q: I did everything the FAQ and Manual told me to. I set $wgEnableUploads = true; and chmod -R 777 images/ safe_mode = Off, and ownership is all consistant and allow_url_fopen is On, but I still get the error:

Could not copy file "/tmp/phpWdGsMs" to "/var/www/vhosts/railgunn.com/httpdocs/pipelinewiki/images/temp/20060317020027!Weird_uvs.jpg"

what can i do?

A: The following section in LocalSettings.php worked for me after I had the same error. (You must also create and chmod to 777all the described-below subdirectories!)

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads       = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";

# This solution comes from:
# http://meta.wikimedia.org/wiki/Uploading_files#Safe_Mode_Restrictions
#
# "images, images/temp, images/archive, images/thumb"
# "all set to 0777 to allow apache to write to them"
#
## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
$wgHashedUploadDirectory = false;
$wgUploadPath       = "$wgScriptPath/images";
$wgUploadDirectory  = "/XXXXXXX/www/wiki5/images";

Fill your full absolute account home directory path in place of '/XXXXXX/' and your MediaWiki path in place of 'www/wiki5/'. (Still, I have thumbnailing error after that, in Safe Mode, though. Yet to solve this.)

If you are working with multiple apache web servers you might have to set the upload directory individually inside the httpd.conf or vhost.conf:

 <VirtualHost 1.2.3.4>
  DocumentRoot "/srv/www23/wiki/htdocs/"
  ServerName 1.2.3.4
  php_admin_value open_basedir /srvgeo/www/
  php_admin_value upload_tmp_dir  /srvgeo/www/
   ....
  </VirtualHost>

—Wikipedia:en:User:6birc, 14:04, 25 August 2007 (UTC)

Q: How do I enable uploading files on my MediaWiki install for IIS6 and mediawiki 1.5?

Q: But it says it has to be "specially set up to be secure"... how can I be secure?

• I'd highly recommend you clean up your config, yes...
• Also, I'd recommend you upgrade to the latest version... 1.2.0 has tighter controls on uploaded filetypes. See the RELEASE_NOTES file.

Q: Why do I get the message: "The file you uploaded seems to be empty. This might be due to a typo in the file name. Please check whether you really want to upload this file."

• One reason for this is that something below mediawiki such as PHP or the web server is limiting the size of http requests. See the next question.
• Try checking the ignore any warnings at the upload file page.
• Check also if the php config upload_tmp_dir is set.
• Check that the /tmp dir is not full (happened to me!)
• If you changed the any settings (e.g. php.ini) restart your apache server

Q: I am attempting to upload .doc files to a newly installed wiki. The localsettings.php file has been modified as desrcibed above. When I attempt to upload a .doc or .pdf, the following error message occurs:

".doc" is not a recommended image file format. 
Retrieved from "http://localhost/pgnwiki/index.php/Special:Upload"

Any ideas as to why this might still be happening? I tried modifying the check file extensions and the strict extsions options, but the problem still persists. Below is the relevant excerpt of my current settings of my local file. Any input feedback is appreciated.

Ehealy 17:52, 9 July 2007 (UTC)

There are strict restrictions on file types you can upload - by default, only four types of image files. You can change this setting somewhere, but I'm not sure where. 203.109.148.89 22:05, 19 December 2007 (UTC)
Q: What affects the maximum file size that can be uploaded?

• Change "upload_max_filesize = <Number>M" in your php.ini file, where <Number> is the limit in MBytes.
• Change "post_max_size =<Number>M" in your php.ini file as well and restart apache.
• If this php4 parameter is too low, you get the error message "The file you uploaded seems to be empty. This might be due to a typo in the file name. Please check whether you really want to upload this file."
• Apache has a directive "LimitRequestBody", which controls the maximum number of bytes allowed in ANY http request. If this limit is not somewhat larger than upload_max_filesize, the above message will appear for files near or above this limit. This directive may appear in various places in the apache configuration files, or in an .htaccess file. The effect of this directive may be global, or limited to a particular virtual host or directory, depending on where it occurs. Consulting the Apache documentation is advised if you run across this directive to understand how it is being used.

Some distributions use this directive to guard against denial of service attacks. For example the php module configuration for Apache2 on RedHat limits the request body size to 524288 bytes. Look at /etc/httpd/conf.d/php.conf. -- Other distributions may place the directive in other places according to their individual configuration file policies.

• MediaWiki's SpecialImport.php page has a hardcoded MAX_FILE_SIZE on the form that you may need to increase manually. You'll get a message saying This file is bigger than the server is configured to allow if you encounter this problem. Fix it by grepping includes/SpecialImport.php for MAX_FILE_SIZE and increase it from 2000000 on up to whatever you need. Note that if 'whatever you need' exceeds the sizes set in php.ini for POST size, Upload Size, and Memory that a script can use - then it won't work, and you'll have to go in there and increase the limits accordingly.[1]

<legend>" . wfMsgHtml('upload') . "</legend>
        <form enctype='multipart/form-data' method='post' action=\"$action\">
                <input type='hidden' name='action' value='submit' />
                <input type='hidden' name='source' value='upload' />
                <input type='hidden' name='MAX_FILE_SIZE' value='20000000' />

One way to tell where the problem lies, is to check your logs. If you're seeing messages about memory being exhausted, and the like - then go check out your php.ini. If you're not seeing anything in the logs, then chances are it's the SpecialImport.php that's the sticking point...

• PHP's memory_limit may also place a limit on the maximum file size. See the note below if you find that you are getting a memory exhausted error in the Apache error log.
• If you're using Apache2, and PHP is loaded as a module (in my case it was PHP5), then the phpinfo() function will tell you where it expects the php.ini file to be located at. That's all good - except that it doesn't read the php.ini file!!!! You'll know this because when you look at the results returned from the phpinfo() you'll see that the local value hasn't been updated to reflect the change you made in php.ini !!!! After much hair-pulling, gnashing of teeth, and lots and lots of Caffeine, I discovered the workaround to be putting the php values that I wanted to change in the php.ini file into the httpd.conf file. Restart httpd, and it's all good... Here's a sample of what I had to add to the httpd.conf file (I put them right after the loadmodule statements that load up the various modules I'm using (including php5):

 php_value upload_max_filesize "25M"
 php_value post_max_size "25M"
 php_value memory_limit "64M"
 php_value file_uploads "On"

(Hopefully this will keep some other hapless Sysadmin from having to visit the Hair Club...)

One other thing I noticed is that the upload routine appears to be a memory hog. I had the memory_limit set to "25M", and it died with a "overloading of the server..." error when I was uploading a 6MB file. Oddly enough, I didn't see anything logged. For giggles I upped it to 64M, and it worked fine. I should probably dig into this some day to figure out what's going on...

/tmp path not reachable?

Also make sure that the temporary path for uploading files is actually reachable. Your php.ini may refer to a temporary path that is not reachable from your webserver, if the server is running in a chrooted environment. If this is the case, you will get the message "PHP Warning: File upload error - unable to create a temporary file in Unknown on line 0" if error logging is enabled. Change the file_upload_path to one which is reachable by your webserver, such as '/var/www/temp' in a typical Apache environment.

Safe Mode Restrictions

If you get a safe mode Restrictions in effect error, it is caused by your host running php in safe mode. PHP might be able to create directories for the uploaded files but that depends on the php config.

Q: Is there a workaround to this safe mode problem? I would like to be able to use images in my wiki. Embedding external images is nice but it requires absolute URL's, which I hate. Couldn't Mediawiki handle some sort of "static-images" folder?

## If you want to use image uploads under safe mode, 
## create the directories images/archive, images/thumb and 
## images/temp, and make them all writable, along with images/ . Then uncomment 
## this, if it's not already uncommented:
# $wgHashedUploadDirectory = false;

(you can find this variable in includes/DefaultSettings.php)

See the PHP manual entry on safe mode for details.

A quote from a comment to the PHP manual: Beware: Safe mode will not permit you to create new files in directories which have different owner than the owner of the script. That is, in safe mode, images/archive, images/thumb and images/temp must be owned by the user who executes the PHP script - depending on your server setup, that would be the owner of the apache process (when using modphp), or the owner of the index.php script (when using suphp).

A small note: After adding the the additional directories, and chmodding them to 777, I still had a problem with safe mode where it failed to upload because the scripts could not access the uploaded files that apache was making (in safe mode, scripts owned by one user cannot access scripts owned by another). To get around this, I did the following from shell as root:

• Find the default owner for files on your site - I use ensim, so the first site admin, is the user 'admin1'
• Create a new group called 'wiki_users': 'groupadd wiki_users'
• Add admin1 (or whatever your admin user is) to that group: 'usermod -G wiki_users admin1'
• CD to the wiki root folder and: 'chown -R apache:wiki_users *'
• That makes all files owned by apache and members of the wiki_users group. So, apache should be able to upload and move files about, and admin1 should be able to access all scripts.

I'm not sure how secure this is - I use it on a private server, but it worked for me.

Another small note: After I tried these suggestions, my upload still didn't work. I set $wgHashedUploadDirectory to false, but made the directories writable. This worked for me.

Another HowTo
This worked for me(with a shared host under safe_mode):

 # wikiroot/images, wikiroot/images/temp, wikiroot/images/archive, wikiroot/images/thumb
 # all set to 0777 to allow apache to write to them
 $wgHashedUploadDirectory = false;
 $wgUploadPath       = "$wgScriptPath/images";
 $wgUploadDirectory  = "/absolute_path_to_wiki_root/images";

Images Not Working

Q: Can anyone help with this problem?? http://meta.wikimedia.org/wiki/Talk:Uploading_files#Images_Not_Viewable

A: I found guidance here: http://www.linuxquestions.org/questions/showthread.php?postid=1722568 . I added an index.html file to the images directory, and double-checked that my permissions were set, and it started working. Elonka 03:11, 11 November 2005 (UTC)

A2: If your running apache on debian, you might want to check for an "Alias /images/ /usr/share/images/" in your httpd.conf. Comment that line out and you'll be golden.

Fatal error: Allowed memory size of 8388608 bytes exhausted

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 80629 bytes) in .../includes/Parser.php on line 206

Editing pages with lots of content.

php.ini -- memory_limit = 8M -- increase it.

This also resolves "The file you uploaded seems to be empty. This might be due to a typo in the file name. Please check whether you really want to upload this file." when uploading files, when all other things mentioned on this page do not work.

The memory_limit set in php.ini may be overridden by LocalSettings.php. Check for a line that says something like:

ini_set( 'memory_limit', '20M' );

In this case, update the LocalSettings.php file instead.

A related error is

PHP Fatal error:  Allowed memory size of 20971520 bytes exhausted (tried to allocate 9088 bytes) in
.../includes/Image.php on line 1230

This can happen when the specified memory limit is exhausted while the PHP function imagecreatefromjpeg operates on image files in the EXIF variant of the JPEG format as used by many digital cameras. One result of this is that the wiki will generate a blank page for the image description page.

Besides increasing the memory limit it often helps to strip the metadata that the camera inserted into the image file, for example using a tool like jhead. The discussion section in the php manual for imagecreatefromjpeg has some more info on this problem.

Another A related error is

PHP Fatal error:  Allowed memory size of 20971520 bytes exhausted (tried to allocate 9088 bytes) in
...Bitmap.php

I tried to upload a png file exported and got this error. Raising the php memory limit did not fix the problem. The solution was to convert the png image into a jpg! Now I was able to upload the image.

"Sorry, not logged in" when uploading files

If having trouble uploading files, it could be a permissions issue.

How to Upload Non Image Files?

I have to upload non image files like Excel spreadsheets (*.xls), Word documents (*.doc), etc. How to do this?

Add

$wgFileExtensions = array('gif','png','jpg','jpeg','svg','xls','doc');

to the LocalSettings.php.

Certain types of files are banned from upload (exe, php, html, etc).

See $wgFileBlacklist in DefaultSettings.php -- Uploading Non Image File

The PHP server takes the last standing line as the relevant one, so be sure that there is line contradicting what you are inputing. Check if there isn't a second '$wgFileExtensions' in the DefaultSettings.php.

Also possible, Try adding:

$wgCheckFileExtensions = false;

where would you add this.

In my Wiki I had conflicting arrays of file extensions LocalSettings <> DefaultSettings.

(Florian, 82.150.200.4 13:23, 20 February 2007 (UTC))

It doesn't work either, but what it's explained under does: -- dgil 28 July 2006

$wgFileExtensions = array('gif','png','jpg','jpeg','svg','xls','doc','ppt','wmv','swf');
$wgVerifyMimeType = false;
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;

Verified. Appears to work --Graham

This seems to be a problem with the file utility. I find that running

file -bi file.xls

on the server returns nothing, and this is the way that mediawiki determines the mime-type. It seems that

$wgVerifyMimeType = false;

is required for xls uploads. Jim

If you're still having trouble, I noticed that the white list of allowable extensions did not work without at least one item in the blacklist present. After doing that it worked for me.

Template for showing links to files with appropriate icons

For a template to enable files to be shown as links with relevant icons, as well as a link to the file's wiki page, see here.

This is for wikis that support embedding external images - which is most personal, corporate and organisational wikis based on MediaWiki. Notable exceptions are Wikipedia and Meta. Because Meta can't render this template, here is an image of how the template appears: File:PDF file example.png

Is it possible to let only some users upload Images?

Yes. The easiest way to do this, under 1.5, is to remove the upload access from users, and assign it to a separate group.

Add the line

$wgGroupPermissions['uploadaccess' ]['upload']          = true;

to the end of your /LocalSettings.php file. This overrides the following line in your /includes/DefaultSettings.php file (don't edit that file!):

$wgGroupPermissions['user' ]['upload']          = true;

Anyone you want to give upload access to, add them to the uploadaccess group (Special:Userrights). This gives them global upload access, but you can restrict it. Sysops, under this change, still keep upload access.

The file is corrupt or has an incorrect extension. Please check the file and upload again.

Q: What should I do? I add $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'svg', 'txt', 'bin', 'rpm', 'pdf', 'java', 'doc', 'ppt', 'tar.gz', 'zip', 'rar' ); but some files (such as .doc and .zip files) will not upload.

A: (first see: http://www.mediawiki.org/wiki/Manual:Mime_type_detection) Mediawiki is trying to validate the mime type of your upload. You can either turn this feature off or fix it. The error can also be triggered by insufficient temporary space to upload the file.

To turn it off:

• See: http://mail.wikipedia.org/pipermail/mediawiki-l/2005-July/005878.html, http://www.mediawiki.org/wiki/Manual:$wgVerifyMimeType
• Add $wgVerifyMimeType = false; # to LocalSettings.php (You may need to comment this line out in includes/DefaultSettings.php as it seems to override LocalSettings.php)

To fix it:

• See: Uploading of 'corrupt' files, http://www.mediawiki.org/wiki/Manual:%24wgMimeDetectorCommand
• Add $wgMimeDetectorCommand= "file -bi"; # to LocalSettings.php on Linux
  • mime type is now 'cannot' - probably SELinux problem - 'cat /var/log/messages | tail -n 100', try 'cd maintanance; php rebuildImages.php', is mime type corrected now? if so, try 'yum install selinux-policy-targeted-sources' and '1. Reach the SELinux policy source directory: ...' on [2]
• Add $wgMimeDetectorCommand = "c:\cygwin\bin\file.exe -bi"; # to LocalSettings.php on Windows with Cygwin

Or to fix otherwise:

• Check the MIME Magic file used by PHP. In a phpinfo() section, check the mime_magic section to see if it's a) switched on (the mime_magic.magicfile exists in the php.ini & points to a correct magic-formatted file) and b) doesn't produce any errors. To check the latter, add (or alter if they exist) the lines "mime_magic.debug = On" and "display_startup_errors = On" to the php.ini & then run one of the wiki's maintenance scripts from the command line (rebuildImages.php is a good candidate) - redirect the error output to a file & check if there are any errors in the magic file. --Barthax 12:41, 31 January 2006 (UTC)
• Check the mime.types file used by mediawiki. It defaults to include/mime.types. If your file's extension is not mentioned in that file, or it does not match the returned mime type, you will get this error. For example: Mathematica notebook files have the extension .nb and the type text/plain. The standard mime.types file does not include this combo and the upload will fail.
• The MIME type detection depends upon the fileinfo PECL extension. Instructions for fedora core 5 are:

yum install php-devel
pecl install fileinfo
chcon -t httpd_sys_script_exec_t  /usr/lib/php/modules/fileinfo.so
cat <<EOF > /etc/php.d/fileinfo.ini
; Enable fileinfo extension module
extension=fileinfo.so
EOF

For Fedora Core 6 and CentOS 5 users just run:

yum install php-pecl-Fileinfo

Ubuntu quirks

Ubuntu seems to take a bit of work to get this working properly. The problem stems from the fact that the fileinfo module isn't installed.

In my particular case I was able to upload image files, MS Word files and PDFs just fine but PPT and XLS files gave me a headache. The $wgVerifyMimeType = false; and $wgMimeDetectorCommand = "file -bi"; have had no effect on it at all.

You have to install the fileinfo php module using PECL, but you have to install php5-dev and libmagic-dev first using apt-get because the phpize function has to be installed. Then run pecl install fileinfo, edit your php.ini to include fileinfo.so and restart apache.

That fixes it up for everything but files that trigger a file size warning: "function.finfo-open: Failed to load magic database at '/etc/magic'. in /includes/MimeMagic.php on line 502". Simply copy /usr/share/file/magic to /etc/magic.mime and it seems to have no problems from there.

I get a Blank Screen (IE) and a Blank Upload Form (FireFox) after uploading an image

Q: I am using apache 1.3 and wiki 1.5. Looking at the directory, the file is not uploaded. Any suggestions?

A: Check the limit of upload_max_filesize and post_max_size in your php.ini.

I did as your instruct but I still can't upload files. A blank screen is always displayed after uploading images.

• I'm experiencing the same problem. I can upload small .wmv files (which were added to the allowed uploads), but not large ones... somehow it all must be related... Jcobbers 18:40, 30 January 2006 (UTC)
• Large (>3meg) wmv files won't work (This page cannot be displayed IE error). However, small wmv's work, and large (>10meg) flash or mp3 files do work. Also, the small wmv files that upload are claimed to be MIME type: text/plain (it is not!). In LocalSettings.php I have set:

# enable other files to be uploaded
$wgFileExtensions = array('gif','png','jpg','jpeg','svg','xls','doc','ppt','wmv','swf');
$wgVerifyMimeType = false;
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;

I suspect the MIME type encoding is wrong. So something related to that is either choking or disabling uploads for WMV files. Jcobbers 13:53, 31 January 2006 (UTC)

I fixed it! I'm running on a linux environment, so 'file -bi <name of file>' is a valid command. When I turned ON this method of identifying the mime type in LocalSettings.php, it worked.

# Sets external mime detector program. B/c using mime_content_type($file) did not work for wmv types (returned text/plain, 
# and then it was searched for malicious code in the file--causing something to hang).
$wgMimeDetectorCommand= "file -bi"; #use external mime detector (linux)

Why did I need to do this? Because wmv files were recognized as text/plain when not using 'file -bi' -- and the Sanitizer in SpecialUpload tries to scan the file for malicious code. It is too big of a file, and it choked. For more details, read this thread [3] or contact me Jcobbers 20:58, 2 February 2006 (UTC)

I get the blank upload form too, but it's not just Firefox but all browsers (including IE and Safari). Is this a different problem or is this related? I'm not using Apache, though, and I have to use "ugly" URL's.—Gniw 20:20, 14 February 2006 (UTC)

I had this problem with large files (under Fedora Core 4 and Apache) and fixed it by increasing the memory limits in LocalSettings.php:

ini_set( 'memory_limit', '64M' ); # Did not work when set to 20M

and in php.ini

memory_limit = 64M      ; Maximum amount of memory a script may consume (8MB)
...
upload_max_filesize = 100M

15:48, 25 February 2006 (UTC)

I have it installed locally to organize my work (apache on windows,php,mysql), I did all that, still, doesn't work, cannot upload files larger than 5 or 6 megs, get a blank upload form. Ideas?

I had the same problem, tried everything above but it still didn't work. Increase the 'post_max_size' variable in php.ini.

Error loading file under XP SP2

Running a small test site on my laptop works fine. However, trying to upload a small jpg, I get this error:

Could not copy file "C:\WINDOWS\TEMP\phpB6.tmp" to
"c:\Inetpub\wwwroot\mediawiki/images/c/cd/NyTimesUnschool.jpg".
Error in GlobalFunctions.php line 1534

At line 1534 is the default:

	# Now go forward creating directories
	$createList = array_reverse( $createList );
	foreach ( $createList as $dir ) {
		# use chmod to override the umask, as suggested by the PHP manual
		if ( !mkdir( $dir, $mode ) || !chmod( $dir, $mode ) ) {
			return false;
		} 
	}

In localsettings.php I have

$wgUploadPath       = "$wgScriptPath/images";

My versions are:

    * MediaWiki: 1.8.2
    * PHP: 5.1.6 (isapi)
    * MySQL: 5.0.24a-community-nt 

I tried making the directories "c" and "cd" under "images", but no change.

I also used Windows Explorer and changed the "Image" directory to UNclick the "read only" option.

I note the unix/win slashes - could they be the problem? If so, how to change?

Any help MUCH appreciated.

Try

$wgUploadPath       = "{$wgScriptPath}/images";

"Could not find file "/var/tmp/php31aWnF" or similar errors

Note that the open_basedir directive in 'php.ini' needs to include both the destination upload folder in your MediaWiki installation ("{$IP}/images") and also the 'upload_tmp_dir' folder (default system folder if not set). The addition of the 'upload_tmp_dir' can avoid messages like "Could not find file "/var/tmp/php31aWnF" (where in this example the 'upload_tmp_dir' is '/var/tmp'). Read more about this behaviour at php.net - look particularly at the comment by nlgordon at iastate dot edu.