If you have upload issues, read this page - entirely! The Coppermine dev team considers this page to be the most important page of the entire documentation, simply because there are many different things that can go wrong when uploading. This is caused by different webserver setups mostly.
We repeat - check/apply your permissions on the /albums, /albums/userpics, and /albums/edit directories. All should usually be 777 or 755 (depending on your webserver configuration) or whatever is needed on your webserver setup to allow the coppermine script write access.
If you are experiencing issues with coppermine's upload process, temporarily change your coppermine settings as suggested below to get more detailed error messages. This applies to all upload methods, not only HTTP uploads.
DetailsWhen troubleshooting uploads in CPG 1.5, you are advised to activate 'Debug mode' in the config console. Changing this setting negates some of the error masking done in the multiple upload setting. This will allow you to access more detailed error messages.
You should try using http uploads, even if you experienced troubles using another upload method. You should get a more detailed error message if something is wrong that tells you what exactly goes wrong with your uploads. If the error message doesn't mean anything to you, search the support board for the error message you get.
If you don't get an error message at all, you probably have overloaded the server with previous attempts - please review the server-sided limitations that might apply for you.
Not sure what to do now? Read on:
This is a step-by-step guide that is meant to explain in a fool-proof way what settings you need to make when asking for support on the Coppermine support board.
We assume that you have applied tight permission settings, so we'll go through this a bit more complicated than actually necessary on most setups: the instructions below are meant to allow upload troubleshooting for the supporter even if the rest of users of your gallery isn't allowed to upload or if you don't even allow user registration in the first place. If you know your way around, you can of course skip the steps that explain the creation of an extra group if all your registered users are allowed to upload anyway. In the end, the important thing that counts is that the supporter can go through uploading untill he/she can see what actually goes wrong during the upload stage.
Click on "Upload file". If you don't have that upload link, you have failed to set up permissions properly - review the steps above carefully.This is how your support request posting could look like (make sure that you populated the stuff in red with actual content from your case):
| Error message | Possible cause | Suggested fix |
|---|---|---|
|
Impossible to move somepic.jpg to albums/userpics/ Warning: move_uploaded_file(/tmp/phpezCYKr) [function.move-uploaded-file]: failed to create stream: Operation not permitted
|
PHP's temporary folder is missing or doesn't have the needed permissions |
You should contact the admin of your webhost because you usually can't change the location of the website's temporary directory for file uploads, yourself (it is part of PHP configuration) . If the open_basedir restriction is in effect on your site then the temp directory for file uploads should be one that you can access. |
|
Impossible to move somepic.jpg to albums/userpics/
|
The coppermine script doesn't have permissions on the filesystem of the server to create the thumbnail or intermediate image within the specified folder | Apply permissions on the albums folder and everything within it as suggested in the section Setting permissions. This error message is the most frequent one, as many users tend to skip reading the permissions section. At least when getting this error message, you should read it thoroughly. |
|
Warning: opendir(./albums/edit): failed to open dir: No such file or directory
|
|
|
|
Warning: Undefined variable: HTTP_POST_VARS in include/init.inc.php on line 43
|
|
Check if your version of PHP fullfills the minimum requirements for Coppermine. If your version is 4.3.0 or better, then this error is probably caused by a misconfiguration of your hosting server, and not a Coppermine issue. If the server isn't yours to configure properly (that is: if you're with a webhost), you can try this workaround (at your own risk): Edit the file "init.inc.php" and look for $PHP_SELF = isset($_SERVER['REDIRECT_URL']) ? $_SERVER['REDIRECT_URL'] : $_SERVER['SCRIPT_NAME'];
Replace it with$PHP_SELF = $_SERVER['PHP_SELF'];
|
|
Sorry there is no album where you are allowed to upload files
|
|
|
|
Fatal error: Allowed memory size of XXXXXXX bytes exhausted at (null):0 (tried to allocate XXXX bytes) in /var/www/html/include/picmgmt.inc.php
|
This error occurs when using GD and attempting to upload a high resoltuion image. It's not the size of the file that matters here; it's the number of pixels that determine memory use in GD. This is not a soft error triggered by Coppermine, but a hard error from PHP that shines through Coppermine from PHP. |
There is (at least in theory) no limit in Coppermine to the file size or dimensions that the script can handle. However, there is at least one limit existing on the webserver: resizing images (to create intermediate images and/or thumbnails) consumes memory and burns CPU cylces. To prevent the server from crashing, the server admin has to restrict the amount of memory that a PHP script is allowed to consume. The error message mentioned above means that the limit imposed by the server admin has been reached, i.e. the image that the script tried to process consumed to much memory.
|
|
Exec() has been disabled
|
php.ini allows the server administrator to disable certain functions. Usually this is the case if your server is running in safe_mode. |
If the server administrator has disabled exec() you will not be able to use Image Magick. You may try to replace exec() with passthru() in the entire core code of coppermine (not recommended) if it has not been disabled as well. Otherwise, you can't use ImageMagick and must use GD. Change Method for resizing images in config accordingly. |
|
Not a GD extension
|
The file(s) you tried to upload can not be handled using the GD ImageLibrary | The GD library can only handle jpeg, png and gif files, while the ImageMagick library supports additionally bmp, psd and some other (less common) file types. However, those files are not suitable for use on the internet. Details can be found in the Allowed image types section in the config page of the docs. |
|
The file 'albums/userpics/10001/somepic.jpg' can't be inserted in the album. Error executing ImageMagick - Return value 127
|
You haven't specified the correct path to ImageMagick, or you don't have ImageMagic at all. | If you're sure that you actually have ImageMagick available on your server, review path to ImageMagick. If the path appears to be correct, make sure that the coppermine script has permissions to read and execute the convert executable within the ImageMagick folder. If you're not sure, switch Method for resizing images from "ImageMagick" to "GD2", then try uploading again. |
|
PHP running on your server does not support the GD image library, check with your webhost if ImageMagick is installed.
|
Your webserver doesn't come with support for the GD image library. | Make sure that you fullfill the minimum requirements to run Coppermine. If GD is not available on your server, you could use ImageMagick. Ask your webhost if ImageMagick is available on your webserver. |
|
No file was uploaded ! If you have really selected a file to upload, check that the server allows file uploads...
|
File uploads are disabled in php.ini or there is a permissions issue or there is an issue with your webserver's upload mechansim. |
There may be several reasons for this error message. The file you tried to upload did not "reach" the folder on the webserver where it is supposed to go. Check if there's a problem with HTTP uploads on your server - this feature may have been disabled or improperly configured. In phpinfo(), check that "file_uploads" is ON, "upload_max_filesize" is something like 2M and "upload_tmp_dir" is a valid directory! Make sure to review your file/folder permissions as well. If the server isn't yours to administer, you may have to ask your webhost for support. Here is what you should check:
|
|
Destination directory albums/userpics/XXXXX/ is not writable by the script
|
permissions on file system level are not correct | Make sure to review your file/folder permissions. If that doesn't help, ask your webhost for support. |
All upload methods, but particularly HTTP uploads are limited by the restrictions placed upon them in PHP's configuration.
If you are webhosted, you will need to consult with your webhost regarding the following settings. You can review (although not change) those settings on your phpinfo page.
Some notes about the different types of upload mechanisms available since cpg1.3.x (or better):
Multiple HTTP uploads are designed to handle a small number of files. Therefore, they are not well suited for the uploading of large numbers of files unless you are running your own webserver or have control over the php.ini configuration.
If you are looking to upload more than 15 or 20 files at a time, you should consider the batch add process or the XP Publisher utility. Each has its own drawbacks and advantages.
The batch add process is fast, but it creates quite a load on the server and, as a result, you may experience timeouts causing your uploads to terminate prematurely. XP Publisher, on the other hand, is considerably slower, but it limits the load on the server. It also circumvents many of the pitfalls caused by limitations set in the php.ini configuration by uploading each file in the batch being uploaded as an individual post request.
Other alternative upload mechanisms (like Client-based agents as JUpload or similar) may be provided as third-party contributions - you're encouraged to look at them as well, but please keep in mind that the coppermine developers can only provide limited support for third-party contributions.
Keep in mind though that before trying any alternative upload mechanism, you have to make sure that the initial upload method "http uploads" works as expected - if it doesn't, you have to fix that first; it doesn't make sense to try alternative upload mechanisms if the core upload mechanism doesn't work.
There is (at least in theory) no limit in Coppermine to the file size or dimensions that the script can handle. However, there is at least one limit existing on the webserver: resizing images (to create intermediate images and/or thumbnails) consumes memory and burns CPU cylces.
If the resizing process is eating up too much memory, you usually get the error message Fatal error: Allowed memory size of XXXXXXX bytes exhausted at (null):0 (tried to allocate XXXX bytes) in /var/www/html/include/picmgmt.inc.php or similar.
To prevent the server from crashing, the server admin has to restrict the amount of memory that a PHP script is allowed to consume. This is done using the parameter memory_limit.
You might be tempted to believe that the memory usage equals the file size an image consumes on file system level, but that's not the case: the common file format JPEG is compressed, so if the server loads a JPEG file into memory, it consumes much more RAM than it consumed on file system level.
Here are some common image resolutions and their memory use in GD (assuming RGB):
| Width | Height | Memory usage | |
|---|---|---|---|
| 800 | x | 600 | 1.4 MB |
| 1024 | x | 768 | 2.3 MB |
| 1280 | x | 800 | 2.9 MB |
| 1280 | x | 1024 | 3.8 MB |
| 1400 | x | 1050 | 4.2 MB |
| 1600 | x | 1200 | 5.5 MB |
| 1920 | x | 1400 | 7.7 MB |
| 2048 | x | 1536 | 9.0 MB |
| 2560 | x | 1600 | 11.7 MB |
| 2800 | x | 2100 | 16.8 MB |
| 3200 | x | 2400 | 22.0 MB |
| 4096 | x | 3072 | 36.0 MB |
| 6400 | x | 4800 | 87.9 MB |
Remember when using the above figures that the amount of memory being used by the rest of Coppermine must be taken into account, too.
As you can see, the memory consumption of images produced by modern digital cameras can easily be too much for your webserver to cope with, even when using single file uploads (let alone the consumption when processing several images using batch-add), so it's recommended to resize your images on your client before uploading them: if the server simply isn't capable to process the images uploaded, there's little point in blaming the script (i.e. Coppermine) or asking for support on the Coppermine support board: the Coppermine devs can not find a cure for the technology used on webservers. Use the webserver for what it has been designed to be used for; perform resources-intensive calculations (like resizing images with a high resolution) on your client.
To increase the memory limit allocation in php.ini, you must be the server's administrator. Also, .htaccess files cannot change this configuration setting, and it cannot be changed using ini_set(). This being said, most coppermine users who are on shared webhosting will not be able to change this. If you actually are the server admin, here's how to increase the memory limit:
First, you locate the following block in php.ini (if you actually are the server admin):
;;;;;;;;;;;;;;;;;;; ; Resource Limits ; ;;;;;;;;;;;;;;;;;;; max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60 ; Maximum amount of time each script may spend parsing request data memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
Now you increase the memory limit to fit your needs. 9 to 16 MB should handle most requirements.
If you are unable to change php.ini settings yourself, you can always ask your server administrator to change this for you. However, most administrators (especially on shared webhosting) will be reluctant to do so, as this setting will affect everyone on a shared server. A higher memory limit requires reducing the number of people who can be hosted on the same server in order to maintain server stability. This reduces profitability, etc.