# Manual talk:Configuring file uploads

## Images not displaying after upload; 404 page displays following image link

I'm using Bluehost, with Mediawiki 1.20.5, PHP 5.4.13, MySQL 5.5.30. Images directory in /w is set to 777

Local Settings:
$wgEnableUploads = true;$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";  AND  php.ini file_uploads = On  The upload process on the wiki itself seems to work fine-- the upload screen shows the thumbnail of the image about the imported. Once the upload is done however, no image displays-- just empty thumbnail boxes. When I click on the image link itself, it takes me to a 404 screen with the URL /w/images/'number or letter'/'number or letter'/'my filename'. No folder or file is created in /images, however. I've also tried configuring php.ini to move the uploaded file, using: move_uploaded_file($_FILES['userfile']['tmp_name'], "{IP}/images") although I'm not sure if I did that right or not, or if that is even the problem to begin with

Any ideas?

Same Problem here after I upgraded from MW 1.19 to MW 1.23. Still searching for the real cause. --213.196.168.246 22:58, 8 June 2014 (UTC)

I looked in apache logs. The following error "sh: /cp: not found" appears each time I try a new upload. (I use MW 1.23.)

      I may know the problem because i think i have the same problem. it could be that the server


## Upload link not shown in Toolbox

The Upload option is not displayed in my toolbox. My LocalSettings.php upload configuration is this:

$wgEnableUploads = true;$wgGroupPermissions['autoconfirmed']['upload'] = true;
$wgGroupPermissions['autoconfirmed']['reupload'] = true;$wgGroupPermissions['user']['upload'] = true;
$wgFileExtensions = array('png', 'gif', 'jpg', 'jpeg', 'doc', 'xls', 'mpp', 'pdf', 'ppt', 'tiff', 'bmp', 'docx', 'xlsx', 'pptx', 'ps', 'psd', 'swf', 'fla', 'mp3', 'mp4', 'm4v', 'mov', 'avi');  The Server Settings seem to be right, but if not that wouldn't prevent MediaWiki to show the Link wouldn't it? 09:27, 17 December 2010 (UTC) Solved the problem there was another "$wgEnableUploads = false" in the File.

91.37.53.90 09:54, 17 December 2010 (UTC)

I have the same problem, same LocalSettings.php configuration, but no upload option in my sidebar. Thanks! --213.203.135.77 08:57, 11 May 2011 (UTC)

## Cannot upload file name for the gbk code

I want to provide a convenient way to upload,But in the program utf-8 mediawiki cannot upload file name for the gbk code.Please try for this file name.

新建文本文档.pdf

Is the server running Windows? Max Semenik 09:42, 8 December 2010 (UTC)

### Can upload file name for gbk code, but cannot point it(the url is error)

The server is running in Windows。I can upload the file with chinese name to server as follows,

标志.jpg


but the file is renamed to corrupted characters in the server directory as follows,

鏍囧織.jpg


And then, the url in the file page is error as follows,

The requested URL /ismwiki/images/1/15/æ ‡å¿—.jpg was not found on this server.

• MediaWiki version: 1.16.1
• Mysql:5.5.8
• PHP:5.3.3
• OS:Windows Server 2003

## Cannot upload PDFs

I cannot upload PDFs to my wiki. I am logged in as a sysop. I can upload images just fine. The research I have done leads be to believe these changes in LocalSettings should do the trick, but they don't... The public directory is now 777. I don't an error message.

$wgEnableUploads = true;$wgAllowExternalImages = true;
$wgAllowCopyUploads = true;$wgAllowImageMoving		= true;
# $wgUseImageMagick = true; #$wgImageMagickConvertCommand = "/usr/bin/convert";
# allow more file types:
$wgFileExtensions[] = 'pdf'; # trying to get pdfs to work$wgVerifyMimeType = false;
$wgStrictFileExtensions = false;$wgCheckFileExtensions = false;
## $wgMimeDetectorCommand = "file -bi"; ini_set( 'memory_limit', '64M' ); /** This is a flag to determine whether or not to check file extensions on upload. */$wgUploadSizeWarning = true;


Any advice? --Two7s clash 16:08, 23 April 2010 (UTC)

$wgEnableUploads as the very last line. Setting it to true before setting$wgAllowExternalImages and $wgVerifyMimeType can cause errors. See '".[FILE EXTENSION]" is not a recommended image file format.' below. --Brian F. 19:46, 10 August 2010 (UTC) ## Clarifications ### False folder permission After uploading images I'm not able to see them because the subfolders don't have the permission 755. Can I change that automatically or do I have to change them after every upload? It would also be ok if all images would be stored in the images/ folder instead in the images/firstletter/firstletternumber. I hope someone can help me. ### MediaWiki's$wgEnableUploads vs. PHP's file_uploads

How come when editing MediaWiki's $wgEnableUploads between true and false becomes noticeable immediately (unable to upload vs. upload enabled) but editing PHP$file_uploads (if already 'on') is not impacting/denying my upload experience at all?

You have to restart Apache for your PHP config changes to take effect

### End User

Who is the "end user"; someone accessing the wiki using a web browser, or a local user on the machine running the wiki?

In this case, "end user" refers to the user accessing the wiki using a web browser.

### File Types

Are file uploads only for images, or for any type of file?

You can configure MediaWiki to accept additional file types using the $wgFileExtensions configuration setting. ### Chmod Shouldn't the chmod for the upload directory be 744? That gives rwxr--r--. 755 gives r-x, which I thought was what we were trying to avoid... Execute privilege on directories is required to access files inside them. (Yes, this is confusing. Blame AT&T.) --Brion VIBBER 00:47, 19 February 2006 (UTC) There are pages on this site that say 744,755,777. Could someone explain wich to use when? -- anon The important thing is that the webserver has write access. Thus if the upload directory is owned by the webserver user ( e.g. www-data ) 755 would suffice. If the webserver is not owner, but is in the group owning the directory, 775 would be better. 777 is the extreme case where all users on the system have full access. In most cases this would not be advisable. -- anon Thanks for that. Actually the bit about setting the owner to www-data just helped me. As an additional note on this, I think I'm also seeing (on a standard ubuntu apache set-up) that setting the directory to 777 will trip some other security checks thus preventing access. But could be my imagination. So combining these things, I needed to set 755, but also set the owner of the file and the group of the file to 'www-data'. I also needed to do these things recursively because I was restoring from a backed up directory tree: chmod -R 755 images chown -R www-data images chgrp -R www-data images The page currently doesn't mention what the owner should be set to. It's important no? Of course 'www-data' wont always be the correct username. Worked for me on ubuntu. -- Harry Wood 16:44, 21 June 2011 (UTC) For me this worked: chown -R username:psaserv /var/www/vhosts/mywiki.com/httpdocs/wiki/images/ chmod -R 775 /var/www/vhosts/mywiki.com/httpdocs/wiki/images/ --Subfader (talk) 15:15, 25 January 2014 (UTC) ### Making Uploads Lowercase Does anyone have any idea how to allow files to be uploaded and named with lowercase letter, for some reason all uploaded file default to a capital letter for the first letter of the file name? 24.3.123.174 21:13, 3 May 2006 (UTC) wuh. just under a year response time. Anywho: A technical limitation of Mediawiki is that all pagenames have to start with an uppercase letter. this is most likely the cause for all files beeing renamed.195.230.62.186 12:24, 2 May 2007 (UTC) ## The file is corrupt or has an incorrect extension. Please check the file and upload again. I did as mentioned. It's a little frustrating, but it seems like mediawiki does not bother that I changed settings in localsettings.php. I added zip as an extension, than I turned off the extension check, then I turned of mime check etc. Still I can only upload images and no zip files. what to do? ### How I fixed it I had to set$wgVerifyMimeType=false; in my LocalSettings.php which means my mime types are probably screwed up. Its an symptomatic fix to a bigger problem, i suspect.

Perhaps have a look at Manual:Mime type detection -- Duesentrieb 11:10, 6 March 2007 (UTC)

## ".[FILE EXTENSION]" is not a recommended image file format.

I have set file extensions to allow wmv and avi, set $wgStrictFileExtensions=false; and$wgVerifyMimeType=false in LocalSettings.php, but get the message " ".avi" is not a recommended image file format. " (same for .wmv) when I try to upload avi (and wmv) files. Files sizes are under the cap in php.ini. I have not problems uploading static image files (eg .jpg, .png).

With $wgStrictFileExtensions=false, you will still get that warning, but should be able to override it ("upload anyway" or some such).$wgVerifyMimeType=false has nothing to do with this, it just tells MediaWiki not to check if the file actually is an avi file (failing that test would result in a different error message though). -- Duesentrieb 11:45, 21 April 2007 (UTC)
Thanks for the speedy response. Unfortunately no override option appeared on the screen. I just got "Upload warning" header above the "not a recommended image file format" message. This also happened when I check "Ignore any warnings" on the upload screen. However, I then rearranged the order of in LocalSetting.php so that $wgStrictFileExtensions=false appeared before$wgEnableUploads=true and $wgFileExtensions = .... I can now upload video files without any difficulties. Turning of$wgStrictFileExtensions seems a little dangerous. I fixed a similar problem I was having with xls files by adding the following line to mime.types:
application/msword xls
Depending upon the mime detection engine on your server, certain types are misidentified. The true solution is to fix the engine, but this is a pretty safe alternative. - dan

MUst be server pixies then. -- Duesentrieb 13:21, 21 April 2007 (UTC)

## This file is bigger than the server is configured to allow

How do you change the maximum allowed size of a file for uploading?

This is what I have in my php.ini:

; Maximum allowed size for uploaded files.
upload_max_filesize = 250M

You may also have to change post_max_size in the same file. Apache itself might also have a limit set. And keep in mind that you have to restart Apache for any changes to the PHP configuration to take effect...

On my system I'm apparently using PHP FPM, so the file to edit is /etc/php/7.2/fpm/php.ini (editing /etc/php/7.2/apache2/php.ini had no effect). After doing that you need to restart the PHP FPM process.

Is there a way to set it so that only SysOp can upload files?

Is there a way to allow users to upload files without logging in?

That'd be a great help for corporate environments where only a limited number of people can access the wiki (server) anyway...

• Edit SpecialUpload.php file in the includes folder
• Comment out the following two lines:
$wgOut->errorPage( 'uploadnologin', 'uploadnologintext' ); return;  Now users will not have to login to reach the upload form. Simpler method, modify LocalSettings.php: $wgEnableUploads       = true;
$wgGroupPermissions['*']['upload'] = true;  ## In which file is variable$wgFileExtensions?

Im trying to change my extensions list, but it is not in LocalSettings? Where is it?

• The default is set in includes/DefaultSettings.php. But you shouldn't change it here. Just copy the line into your LocalSettings.php and alter it the way you like here. The intention for this procedure is just that the DefaultSettings is responsible for everything that is NOT explicity set by yourself. Also if you like to make an update someday you won't destroy your current settings, cause the LocalSettings.php won't be touched through an update.

## Check directory security

In the manual page, it says under "Check directory security" that "The upload directory needs to be configured so that it is not possible for an end user to upload and execute other scripts, which could then exploit access to your web directory and damage your wiki or web site."

Unfortunately, the PHP function that makes subdirectories is:

function wfMkdirParents( $fullDir,$mode = 0777 ) { ... }

and many places that call this use the fault mode 0777 which is world-writable. For example, everywhere in Image.php it uses one argument calling this method, such as:

./includes/Image.php:1078: wfMkdirParents( $thumbDir ); The consequence of this is that every directory recursively under images is world-writable. The files themselves seem to be fine (mode 644), however, any user who can login to the system on which the MediaWiki instance is running can copy or destroy files at will. Can we get wfMkdirParents (and everywhere that 0777 is passed to that method) to use a mode of 0755 instead? --Caswick 21:09, 15 March 2007 (UTC) ## How to link "other" file types on pages? Case 1 - When i want to upload images, i follow the following steps • go to page edit • write a suitable name • make it into an image link by clicking the 6th button from the left on the edit menu • save page • view page, the link is shown in red. • click it and upload the image Simple. But with file types other than images,it give an error as to "not a jpeg format", there is no such option. I have to link the thing by copy/pasting the exact names everytime. There must some other way around! Please help me on this !! --Ankit.madan 07:12, 21 August 2007 (UTC) ## Error when uploading from URL Fatal error: Call to undefined function curl_init() in /path/to/wiki/includes/SpecialUpload.php on line 165 Any idea what could cause this? I've googled it, but it seems only the chinese have experiences this problem. Using MW 1.11 - followed the directions on the configuration page. Regular uploads work fine. I solved this by typing on Ubuntu: 'sudo apt-get install php5-curl' followed by 'sudo /etc/init.d/apache2 restart' ## Folder permissions & SUPHP If you are using suphp you might want to check the suphp configuration file ( /etc/suphp.conf ) and ensure the Umask value is set to something sane (so when the folders get created they get the proper permissions) Umask to set, specify in octal notation umask=0022 You can also set the umask locally at the LocalSettings.php: umask(0022); ## Multiple Uploads Is it possible to upload multiple files at one time (like for a photo gallery) rather than uploading each file individually? Or if I FTP them to my server without using MediaWiki's upload page, can I still use the <gallery> tags to display them somehow? There's Extension:MultiUpload, havn't tried it though. If you upload files directly to the server using FTP or SCP or whatever, you have to import them into MediaWiki to make them work wiki-style: That is done using maintenance/importImages.php but it requires shell access. I believe some of the bots that exist for mediawiki also support file upload, but I havn't looked into that. There's also the commonist upload tool, which was designed for wikimedia commons, but can be adopted to other sites as well. HTH -- Duesentrieb 06:56, 11 April 2008 (UTC) Thanks so much for the info! I do have shell access, and I think FTP and import would probably the fastest for lots of images. I may use MultiUpload as well - it would be nice if I had just a few files. Just saw that I do not want drag'n'drop mutple upload via interface. Too much abuse. Will also try MultiUpload. Thanks --Subfader 04:55, 7 December 2008 (UTC) The absolute best extension for this is Extension:SpecialUploadLocal which currently works for all version but 1.16. Adamtheclown 08:35, 15 November 2010 (UTC) ## Image File Names I'm webmaster of http://venciclopedia.com, a Spanish language wiki. We recently moved from one hosting server to another and it took us weeks to finish the migration because of problems with the names of some images. The main problem was that our former hosting (yahoo) didn't allow the creation of files or folders with certain characters, but wiki did it anyway and we didn't care until we moved away. Our former wiki could read the folders and images in them, but we could not see them or ftp them out of yahoo because of invalid characters in the names. This was most likely solved by our move to a new hosting and upgrade to the latest wiki, but after so many problems I simply don't want to risk it. My question: There's way to forbid users from uploading files with names containing symbols (as in #, @, etc) and accented words (as in "ó")? Right now we are running with a modification I did to Specialupload.php in line 426, where I changed this: $filtered = preg_replace ( "/[^".Title::legalChars()."]|:/", '-', $filtered );  To this: $filtered = preg_replace ( "/[^a-z0-9\\040\\.]|:/i", 'x', $filtered );  With this change users cannot upload files with symbols or accented words, but they still can upload the "ugly" and nondescriptive file names created by my patch. Meaning, words with a bunch of X's where the symbols or accented words used to be. • So, is there a way to just reload the page and say, Please change your filename, such and such characters are invalid? • Is there a way to transform accented words like "ó" into plain "o"s? In Especial:Allmessages I found a message titled illegalfilename that warns against using invalid characters, so I guess there's some sort of option without having to change Specialupload.php directly. Thanks in advance, here's my upload page in case you need to test it. http://venciclopedia.com/index.php?title=Especial:Upload --Mark 09:55, 25 April 2008 (UTC) reload the page and say, Please change your filename -> yes, you can write a piece of code using the hook UploadVerification (you can adapt UploadBlacklist extension for this purpose) --Yannouk (talk) 12:05, 9 January 2013 (UTC) ## Upload files to FTP server Is it possible to upload files to FTP server? Yes, then use /maintenance/importImages.php Read above section. ## Odd filenames? Hey, I recently installed the newest Mediawiki and any files (I only tried images though) I upload always come up as Image:[USERNAME]--[IMAGENAME].[extension]. Is there any way to make it just go to the file name? Thanks. --Ratmaster 21:37, 21 November 2008 (UTC) I'm getting this too on a small wiki I'm an administrator on. There doesn't seem to be any obvious setting in includes/specials/SpecialUpload.php, does anyone have any clues they could offer me on where to look? Bryan Derksen 06:27, 15 June 2009 (UTC) After digging a bit further on this site I found the answer here: Project:Support_desk/Archives/Images/002#(RESOLVED) Preloaded Image Names?. Apparently the "KeepYourHandsToYourself" extension is responsible. Commenting out the line 'extensions/KeepYourHandsToYourself.php' --$wgHooks['UploadForm:BeforeProcessing'][] = 'prependUsernameToFilename';

seems to be one way to fix it. Bryan Derksen 06:35, 15 June 2009 (UTC)

## File size and postgres

Hi,

I'm using mediawiki1.7 with postgres. When uploading a file, the pg_query() can't write in img_size in the image table and I get an error message -

ERROR: value "202205" is out of range for type smallint


and some other details...

...out of range for type smallint in /usr/share/mediawiki1.7/includes/DatabasePostgres.php

I have modified $wgMaxUploadSize and$wgFileExtensions in LocalSettings.php

## Logon

I've added this topic to the main article. I spent a few hours trying to get my uploads working and it wasn't until I saw the Upload File option under Special Pages that it finally told me I had to register and logon. This would be expected for Wikipedia but for own wikis starting up people (like me) won't necessary register and logon to set it up. 118.209.221.29 21:04, 11 October 2009 (UTC)

## Fails to rename if tmp and image dirs reside in different volumes (Windows)

I had the following problem with mediawiki installed on Windows with wamp server and it took me pretty long to solve it:

If the temp directory is in a different volume that the image directory, then the error "could not rename x to y" error arises. That's because PHP (at least version 5.3) does not like renaming files among volumes. In my case I had wamp installed on C: (so the temp directory was the default one c:/wamp/tmp) and wamps webroot directory installed on D: (so the image directory was something like D:/wamp/www/mediawiki/images).

I know this is no strictly a mediawiki issue, but it would have saved me lots of time if a note about this was included in the article.

--Mmutilva 13:23, 25 November 2009 (UTC)

## finding php.ini

 Typical location of where php.ini maybe found. post_max_size and upload_max_filesize in php.ini

neither of the commands on the main page worked for me in putty.exe or find php.ini, so searching the internet i found this:

For an example of where the php.ini file is: see Where is php.ini located?. Igottheconch 08:43, 16 January 2011 (UTC)

I have a problem, I don't think I have the file at all :/ No idea why, but what to do now?

I have the same issue. I'm running MW 1.23 and don't see these folders or the file mentioned. Maldarthe1st 13 February, 2015

Hello, I've started uploading photos and it worked great except for some photos. I have the following warning " Could not create directory "public/archive/e/ef" ". This is strange as php.ini allows upload, $wgEnableUploads is set to true, and especially it worked OK before and after these 2 photos. I run MW1.16 with php5, image directory is fully writable as well as subfolders "archive", "e" and "thumb". but where is this "public" folder? Any clue? thx! — Preceding unsigned comment added by 89.246.214.0 (talkcontribs) 10:42, 1 March 2011 So, I found and I'll let you know! basically, the subfolder "e" had no special right and no new subfolder could be written. I simply gave it full authorisation... Sorry and envoy MW!!! — Preceding unsigned comment added by 89.246.214.0 (talkcontribs) 11:20, 1 March 2011 ## Could not rename file "/tmp/phpH4iyTE" to "public/9/9b/Germany.png". Trying to solve this, any idea? same as the post just above you, folder 9/9b does not have the correct user rights. Go into your files and change the folder attributes to 777. Igottheconch 00:09, 24 September 2011 (UTC) Maybe the owner of the directories is different from the user that the apache process is using (see section Chmod). --91.213.61.23 15:37, 1 October 2012 (UTC)  ## Maximum file size: 7 KB (a file on your computer) Recently I have upgraded media wiki from 1.16 to 1.17. Since the upgrade my upload page is displaying the message "Maximum file size: 7 KB (a file on your computer)" and throws me the warning "This file is bigger than the server is configured to allow." when I try to upload a file of modest size. in the php.ini Localsettings.php file I have the upload limit defined as follows ## Set upload limit$wgMaxUploadSize = "50M";


and in php.ini, I have these settings (pertaining to file upload)

upload_max_filesize = 50M
post_max_size = 50M


What's missing in my configuration? Any idea? --124.195.194.2 04:45, 2 October 2011 (UTC)

Yea, take a look in your includes/DefaultSettings.php file. Copy the upload size code over to you local settings and edit the '100' to be the size you're looking for. There is also an example in there for uploads from different sources.. url or other. --Pher122s (talk) 17:23, 20 January 2014 (UTC)

What is the problem on uploading files in linux godaddy. When I had my mediawiki on windows, I've uploaded files, but now on linux I can't site

Hello everyone. Is there anyway to configure a mw wiki to allow users to upload more than one image at a time? Say I have a folder with 20 various icons I want to upload for a template (let's just say smiley faces), is there anyway to upload them all in one shot instead of one file at a time? Is there an extension out there that will allow this? Thanks for any ideas or suggestions dealing with this. -- ShoeMaker   ( Contributions Message )   23:09, 11 July 2012 (UTC)

Extension:MultiUpload is what you're looking for, although it's unmaintained.Jasper Deng (talk) 23:17, 11 July 2012 (UTC)

## .htaccess file in images folder causes images not to load

Today I recognized that images in my wiki do not load. So I checked the logs /var/log/apache2/error.log :

[Tue Aug 14 21:24:47 2012] [alert] [client 86.56.32.27] /var/www/wiki/images/.htaccess: RewriteEngine not allowed here, referer: https://example.com/wiki/index.php/Datei:2012-08-13_11h25_37.png


This is the content of the .htaccess file under /var/www/wiki/images:

# Protect against bug 28235
<IfModule rewrite_module>
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase] RewriteRule . - [forbidden] </IfModule>  I just renamed this file so everythings starts working again, but I would like to reveal the cause of this error. I Think the error originates from my apache's "sites-available", maybe someone could give me a hint. Do I need to set the "AllowOverwrite" option in the images segment? cat /etc/apache2/sites-available/default-ssl  <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride AuthConfig </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride AuthConfig Order allow,deny allow from all </Directory> <Directory /var/www/wiki/images> Options -Indexes </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/ssl_access.log combined Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 </Directory> # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on SSLCertificateFile /etc/apache2/ssl/cert/server.cer SSLCertificateKeyFile /etc/apache2/ssl/cert/server.key <FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>



Roemer2201 (talk) 19:47, 14 August 2012 (UTC)

## Error 500 suddenly appears

I'm using MW 1.18.0+PHP 5.2.17 on IIS. I've been using it for several months now with no problems. Suddenly for no apparent reason, I cannot upload files anymore. I get error 500 for regular upload file, and cannot open file error for import. What could be the reason? I checked php.ini and LocalSettings.php. They did not change and both allow uploading. Thank you Osishkin (talk) 06:02, 23 August 2012 (UTC)

When uploading files I'm getting "File extension ".jpg" does not match the detected MIME type of the file ()." and when $wgVerifyMimeType = false; is set I get "An error was encountered when opening the file for ZIP checks." The first error showing in the log is PHP Warning: is_file(): open_basedir restriction in effect. File(C:\Windows\Temp\phpC132.tmp) is not within the allowed path(s): (C:\inetpub\domain.com\live) in C:\inetpub\domain.com\live\includes\filerepo\backe nd\FSFile.php on line 42 I've tried adding C:\Windows\Temp to the open_basedir line in php.ini, but it doesn't seem to change anything. I've also tried everything I can find to change the temp folder to something else with upload_tmp_dir and others, but they also seem to not have any effect. I have IUSR and IIS_IUSRS set to full for testing on both temp directory and images directory with no luck. I'm at a complete loss as to whats going on. Any help would be greatly appreciated! ## EXE uploads Administrators-only? I would like to know, is it possible for administrators - and ONLY administrators - to upload EXE files? What can I add to LocalSettings.php that makes it so? ## File name capitalization It seems that mediawiki capitalizes all files, and all I could find to prevent that is to disable this feature for article titless. Is there a way to keep filenames as they are, but capitalize articles? We want to store certain files that require exact filenames. Bump. ## Fedora 19 and selinux Some of the commands I've just used to enable file upload: grep bash /var/log/audit/audit.log | audit2allow -M mypol  setsebool -P httpd_setrlimit 1  grep mysqld /var/log/audit/audit.log | audit2allow -M mypol  semodule -i mypol.pp  semanage fcontext -a -t httpd_sys_rw_content_t 'images'  restorecon -v 'images'  setsebool -P httpd_unified 1  You can use SELinux Troubleshooter (on System menu) to fix detected problems ## Images in skins/common/images I have just inherited a MediaWiki and a fair number of images are in the regular images directory, but some are duplicated in skins/common/images. I'd like to clear those out, but I'm concerned that I don't know how they got there in the first place. Any ideas? ## BZ2 Does Not Match Detected MIME Type My Wiki is invitation only, so I trust the editors enough to allow ZIP uploading. I followed the guide here to add the extension in and remove it from the blacklist and everything works great. However, several users want to upload UNIX/LINUX archives using BZip2. I've added "bz2" to the$wgFileExtensions array and MediaWiki allows for them to be selected, but when I hit "Upload" I get back:

File extension ".bz2" does not match the detected MIME type of the file (application/x-bzip2).

I'm pretty confident that the BZip2 file has the correct headers and isn't corrupt in anyway, as I have compressed it myself using two separate programs. I've looked at $wgMimeTypeBlacklist, but it doesn't prevent bzip2 by default. Anyone have any luck with this? --TheAlmightyGuru (talk) 21:59, 16 September 2014 (UTC) ### Resolution A reader named Duncan was able to put me in the right direction for this problem. The problem lies in the ./includes/mime.types file. My existing line read: application/x-bzip gz bz2  Which considers BZip2 files as regular BZip files. I fixed it by changing the line to read: application/x-bzip2 bz2  Now, BZip2 files are identified as a mime type of BZip2. GZ files are already covered in a line further down in the file, so it's safe to remove it. I also added the following line to my ./includes/mime.info: application/x-bzip2 [ARCHIVE]  So the Wiki would be able to accept BZip2 files. This may not be the most correct way of doing it, but it did allow my users to upload bz2 files properly. If anyone has a better way, please post here. ## Mediawi Image uploads succeed, but can't view images I'm having a trouble with a new, clean install of Mediawiki 1.23.9 (advanced one-click method in hostgator's QuickInstall). Images can be successfully uploaded, but they are not usable in wiki pages: attempting to click and view the just-uploaded image yields an Internal Server Error (500). On a wiki page where the image is embedded, the image simply doesn't display- instead I just see the image title. How can I fix this and make uploads usable on wiki pages? Possibly helpful info: - Turning off short URLs does not fix this problem- it just clarifies that the internal error is a 505. - ImageMagick, file upload.. etc are all set to true. - Via SFTP, I can download the image (and thumbnails). The files aren't corrupt. (Mediawiki even reads the image metadata correctly- it just doesn't display the image!) - The permissions on the "images" directory (and subfolders) are drwxr-xr-x, the default setting. The file size is 600 KB, well below the upload limit. A smaller image gives the same problem. I tried EVERYTHING, I'm desperate. Please help for me and any future person that gets the same problem! Have you solved it?--Jipre (talk) 10:53, 9 September 2015 (UTC) ## Cannot open .oft or .msg files in Internet Explorer 11, but can with Firefox Hey there, I've scoured the internet on this topic. I may have even came across the answer, but if I did - I couldn't understand it. I've enabled file uploads for a few files (specifically .oft - a Microsoft Outlook 2013 template). I've successfully uploaded them. When I open it in Firefox, it opens great. When I open it in Internet Explorer, I get something like this: ÐÏ�à¡±�á>�þÿ ������þÿÿÿ�ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿRoot Entry��ÿÿÿÿÿÿÿÿ� Á²ô¹UÏ� À*__properties_version1.00�ÿÿÿÿÿÿÿÿÿÿÿÿLÐ�__nameid_version1.0(��ÿÿÿÿÿÿÿÿ�ðK²ô¹UÏ� Á²ô¹UÏ�__substg1.0_0E04001E*��ÿÿÿÿ�ÿÿÿÿþÿÿÿ�ýÿÿÿÿÿÿÿÿÿÿÿ���7E �����@������������ !"#$%&

Imagine that, except about 1,000 lines worth. What am I doing wrong? Thanks!

You're doing nothing wrong. IE just can't handle .oft files. --186.79.68.0 18:14, 17 May 2015 (UTC)

Mediawiki seems to associate a bogus MIME type with these files: MIME-Typ: chemical/x-mdl-rgfile. At my site, we're only able to open them via Firefox if right-clicking and saving the file (else 0kB). In IE11, additionally you need to change the .htm extension to .oft, then IE11 can delegate them to Outlook. MichaelKesper (talk) 14:11, 13 January 2016 (UTC)

## Upload Files Into Subdirectories

I already have hundreds of files and images set in my site directory structure, i.e., Media/Photos, Media/Documents. I can set the default upload directory to "Media" but is there a way to use the subfolders I already have? I've found and installed the UploadLocal extension to "upload" all of these files that are already on the server into MediaWiki, but I'd really like to retain the directory structure I already have because of previous usage and links to these files. I really don't want to start from scratch on THAT and try to catch all of those -- and I don't want all of these files in one directory. These files are used by several different programs and website areas -- I need to retain these directory structure paths.

Is there a file upload configuration that will allow me to specify the use of these subdirectories? Or is there an extension that would allow me to select a subfolder when uploading a file? I was able to change upload directories to test the UploadLocal extension, and it will put them where I want them, but I can't access them through MediaWiki after that, of course, with the upload path of only "Media". Thanks.

## ZIP checks error

I'm using a localhost wiki, but every time I upload an image, I get this error: An error was encountered when opening the file for ZIP checks.

How do I fix it? I am running MediaWiki 1.25.2, PHP 5.6.11 (cgi-fcgi), MySQL 5.6.25-log, and IIS 7 on a Windows 7 Home Premium.

--68.45.51.161 23:48, 17 December 2015 (UTC)

## Media links yield wrong version of uploaded files

Hi,

We have a corporate wiki and been having some issues with uploaded files with multiple versions.

General use case is this: Someone uploads a certain file1.docx to the wiki, creating a link to it using [[Media:file1.docx]] on a certain article/page. So far, so good. You can click the resulting link to download the file (call this the original, version 1).

As time goes by, another user decides to update file1 so he goes to /File:file1.docx and clicks "upload a new version of this file". He uploads a new version (call it version 2) of the file and everything seems to be ok, as both versions appear on the file's version history.

Now, if you try to download the file again (either from the article linking to the file, or from the file description page itself) you'd expect to get the second version of the file, however, we keep getting the original one (version 1) instead.

It seems to be some sort of cache issue, but I am not familiar with the MediaWiki code to look any deeper.

Here's our setup:

• Linux server on shared hosting (dreamhost)
• MediaWiki 1.26.2
• PHP 5.6.29 (cgi-fcgi)
• MySQL 5.6.25-log
• Installed Extensions: CategoryTree; Cite; DynamicPageList3; EmbedVideo; NumberFormat; ParserFunctions; SimpleMathJax; Google Analytics Integration

Any help, comments, ideas will be greatly appreciated.

--Rbirmann (talk) 17:15, 30 January 2017 (UTC)

UPDATE: This error seems to be happening only on files with non-ascii titles. Still investigating.
--Rbirmann (talk) 18:27, 30 January 2017 (UTC)
UPDATE: I tried to replicate this error on my user page here on this wiki, but failed. The uploaded file (FILE_NON-ASCII_TITLE_Ã Ó é ü TEST FILE.pdf) worked perfectly. Tried the exact same thing on our wiki with both .pdf and .docx files and it also worked, so I am guessing it is not related to the non-ASCII characters (still inconclusive, however). Bottom-line is we have this error in some files on our wiki, but can´t really seem to replicate it deliberately :(
--Rbirmann (talk) 19:43, 30 January 2017 (UTC)
If you open the file using private browsing, if you get the old version then it's being cached on the server, otherwise it's being cached on your browser. In the second case, the server may be sending too far expires: HTTP headers causing browser to cache the URL a very long time. --Ciencia Al Poder (talk) 21:10, 30 January 2017 (UTC)

## reused reference

Tried to reuse reference <ref name="kavoir" /> in section Manual:Configuring_file_uploads#Set_maximum_size_for_file_uploads but there's some weird interaction between the <translate> tags I don't understand. Can someone fix that? Thanks. NE Ent (talk) 18:52, 7 March 2017 (UTC)

Convert is used for thumbnailing. I think you can disable convert entirely (set $wgUseImageMagick to false) and uploads should work. However, no thumbnailing would be done. --Ciencia Al Poder (talk) 09:15, 10 October 2017 (UTC) ## small uploads works, large don't I have increased the upload limit to 500mb. When i upload smaler files > 6mb everything works fine, but when i upload larger files (30mb, 100mb etc..) the site stops working and chrome shows "ERR_SPDY_PROTOCOL_ERROR". Sadly the wiki itself or php don't show any errors. My wiki runs on IIS 10, wiki version 1.29.1 and i have done the "Image Authorization". Edit: i have found the error, i had to increase the maximum allowed upload file in the iis itself. ## MediaWiki also has a$wgMaxUploadSize option statement
The statement, MediaWiki also has a $wgMaxUploadSize option, but that is currently not enforced for normal uploads (when uploading a local file). The only way of restricting the upload size is through the use of modifying the php configuration., does not appear to be a true statement. I have observed on MW 1.27 leaving this unset and uploads greater than the default 100MB value fail. I took the value up to match the php.ini settings which were set higher than 300MB and the upload worked. Can we update this statement if it is no longer valid. Or update it if it is valid for older versions of MW? Thanks Hutchy68 (talk) 23:25, 25 October 2017 (UTC) Reading further down the page, there is even a reference to update$wgMaxUploadSize to upload up to 2GB files along with the server setttings. So these two pieces of information are at odds with each other.
I've enabled file uploads on my MediaWiki 1.33 and Nginx 1.17 environment, but I always got an error message saying that mwstore://local-backend/local-public/x/y/filename was blocked. I tried a lot of things, such as change /image folder ownership and permissions, LocalSettings.php variables etc. Nothing worked. So, I just defined /images folder owner as apache (is it a problem from MediaWiki code?) and now I can upload files!