54

I have recently moved a site from a localhost to a VPS. I have managed to make the public and private files writable; however, I am not sure where to find the temporary folder and how to change the permissions. I keep getting this message:

The specified file temporary://file3Hl91E could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

I am using Virtualmin, Drupal 7, and a Debian server. My current temporary directory is /tmp.

Improve this question

19 Answers 19

Reset to default
47

Check Administrator -> Configuration -> Media -> File System to personalize your tmp path. Make sure to use relative paths and have the right privileges for the Apache user.

I personally like this article fix file upload. He has good observations. It worked for me.

Recently, I downloaded my site to my Mac computer. It happens that in my Mac I was using mod_userdir for Apache and I forgot that in /etc/apache2/users/nameofuser.conf I need to set AllowOverride All, otherwise I will have the following message:

The specified file temporary could not be copied because the destination directory is not properly configured.

Improve this answer
6
23

In your settings.php for older versions of Drupal add:

$conf['file_temporary_path'] = '/tmp';

Or for newer versions of Drupal add:

$settings['file_temp_path'] = '/tmp';

This will work on unix systems 99% of the time.

Usually the /tmp directory exists on UNIX systems with open permissions, and it exists specifically for temporary files and is often set up to improve performance.

You can check permissions by running ls -al /tmp on the command line.

If you're interested in further reading on this, see https://en.wikipedia.org/wiki/Temporary_folder

Improve this answer
2
  • 3
    This is not really a good answer in my opinion. There's no explanation and it's likely to not work if /tmp doesn't have the right permissions. It even contradicts with the accepted answer (which is not great on its own either).
    – the
    Oct 13, 2014 at 20:57
  • I don't think the answer requires much explanation, I'd say that how the $conf variable works in settings.php is general knowledge for Drupal developers. One of the nice things about this answer is that it's concise. I'm not sure that it contradicts the accepted answer, the accepted answer will work and this is an alternative. The difference between this method and doing it through the UI is that this will work across multiple environments, but you would have to set it individually in the UI for each environment.
    – chim
    Oct 16, 2014 at 11:53
18

It's important to understand that a permissions problem can exist in BOTH your specified temporary directory (which is defined at admin/config/media/file-system) AND at the folder where that temporary file is going to be copied. I've seen this error a few times and it's usually not an issue with the temporary folder, but the final folder where that file is copied after living in the temp folder.

Also ensure that the public file system path is set correctly.

Improve this answer
3
  • 2
    This was the case for me. In my case, I needed to set the ownership of the newly-created /sites/default/files directory to USERNAME:apache (on some systems that group would be called nobody).
    – Evan Donovan
    Dec 8, 2016 at 17:52
  • 1
    This is the answer I have been looking for during the past few days! My problem was that compressing CSS and JS didn't work (all files were ignored). The cause: sites/default/files/css and sites/default/files/js were not writable...
    – Jeroen
    Dec 12, 2019 at 17:47
  • This is a very relevant comment. This was exactly my issue, I was looking like crazy at the temp folder, and neglecting the destination folder (in my case, it was the subfolders inside the files folder), which had the wrong permissions. Thank you for sharing this.
    – Marcos Buarque
    Jul 14, 2022 at 13:14
7

I had this exact problem and made sure to use relative path (sites/default/files/tmp) for my tmp folder location as suggested and i also changed the permissions on the tmp folder to ensure it was writable by apache but my problem still existed. so i decided to check the log messages(Reports>>Recent log messages) to see if i could get a better understanding of what the problem was. By doing this i got a more specific message:

The file permissions could not be set on public://js.

This prompted me to check the permissions on the js folder in sites/default/files and as it turns out apache could not write to it so by changing the permissions to 775 on that folder i got rid of my error message. So i would suggest that you check the permissions for all the sub-folders in sites/default/files and not only the tmp folder if you have not solved your problem as yet. Just thought i would share this info.

Improve this answer
4
  • My issue was the same as this but I use the following to correct it: sudo chgrp -R www-data /var/www/mysite
    – Wavesailor
    Jun 5, 2014 at 14:25
  • Assuming you're combining sudo chgrp -R www-data /var/www/mysite with "changing the permissions to 775". This is NOT needed. Drupal does not need to write to every folder. Only your public, private and tmp files folders.
    – rovr138
    Dec 1, 2016 at 19:55
  • Yes - the crucial thing here, that no other answer is mentioned, is finding the destination directory (typically somewhere under sites/default/files - /css and /js are prime candidates if you have JS/CSS concatenation turned on) and you can only get that by viewing the log.
    – William Turrell
    Mar 27, 2018 at 21:41
  • …*however* - the label on the admin form says "This directory should not be accessible over the web.", so unless you've taken steps to protect /sites/default/files/tmp in Apache or Nginx, then putting it there is a bad idea.
    – William Turrell
    Apr 3, 2018 at 16:41
5

you can find file system settings in admin/config/media/file-system change it to /tmp

also you can check admin/reports/status for any settings problem

about /tmp permission you can give it 755 and you will find it in /public_html

Improve this answer
2

The error message can somteimes be misleading

If it says the problem is to do with the destination directory, the apache probably doesn't have the permissions to write to the sites/default/files subfolder that Drupal wants tot put the file in.

A good solution is to make the apache user the owner of all files and directories under sites/default/files

cd /path/to/sites/default
sudo chown -R _www:_www files

Or something similar should reslove destination directory issues. Double check that the owner has write and execute permissions on all subdirectories.

Improve this answer
1
  • 1
    This solution saved my day, I'm working on Ubuntu 14.014 and done this chown -R www-data:www-data /var/www/html/sites/default/files/
    – Rishi Kulshreshtha
    Sep 30, 2015 at 9:15
2

The files directory: Troubleshooting Apache-based Web Servers

If the directory files is not "owned" by the Web server there are two ways to proceed. These instructions assume you have shell access to the Web server. If you do not have shell access, please contact your hosting provider for additional support.

Ideally you will be able to change the "owner" of the directory files to match the name of the Web server. On a Unix or Linux-based server you may verify "who" the Web server is running as by issuing the following commands:

$ ps aux  |grep apache # for Apache 2.x
$ ps aux  |grep httpd # for Apache 1.x

Depending on your Web server one of these commands will return a series of lines like this:

www-data 13612  0.1  0.9  50640 20340 ? S 12:29   0:08 /usr/sbin/apache2 -k start

The first column in the returned text is the "user" that your Web server is operating as. In this case the user is www-data. To make your files directory writeable by the Web server you need to reassign its ownership using the following command:

$ chown -R www-data sites/default/files
$ chmod -R 0700 sites/default/files

If you do not have sufficient permissions on your server to change the ownership of the folder, the next best option is to provide group-write access to the folder with the following command:

$ chmod -R 0770 sites/default/files

You should also be able to adjust the directory's permissions using an FTP program as outlined above.

Once you've completed these steps confirm the appropriate permissions have been assigned by navigating to Administer -> Reports -> Status report. Scroll to the section labelled, "File system" and confirm your settings are now correct.

Source: The files directory

Improve this answer
2

In some situations this can be easily fixed by deleting the 'ctools' and 'js' folders within default/files. These folders are recreated by the system if needed. Sometimes when making a new install of an existing site these folders existing already cause problems. Also if your CSS isn't working after making a new install of an existing site this can also be fixed by deleting these files and letting drupal recreate them.

Improve this answer
1

Another source of error is that it cannot write to the files folder. In my case I solved it using:

$chmod 777 sites/default/files/pictures/
Improve this answer
11
  • 19
    woah, really? 777 on what's clearly a production site? That's just irresponsible advice.
    – David Meister
    Aug 13, 2013 at 1:39
  • 2
    Yeah, give it 755 at least.
    – user1359
    Nov 19, 2013 at 15:34
  • 1
    @DavidMeister I upvoted you but unfortunately on shared hosting (vomit) sometimes 777 is the only way Apache can write to a folder
    – user11312
    Feb 13, 2014 at 23:27
  • 1
    @andrewtweber are you sure about this? Even in a shared hosting environment, 775 should be about as loose as you need to get. Could you please give an example of a shared hosting provider that requires 777? If you use 777 on a shared server and you do not have a VPS, everyone else on the server can access your files.
    – David Meister
    Feb 14, 2014 at 10:37
  • 4
    @andrewtweber also yes, the lesson is not that "shared hosting" requires 777 but that "appalling hosting" requires 777.
    – David Meister
    Feb 17, 2014 at 11:59
1

My old and problematic configuration

chmod 664 -R /var/drupal-bc/sites/default/files
chmod 664 -R /var/drupal-bc/sites/default/private

drw-rw-r-- 2 www-data www-data  4096 Jul 31 12:35 files
drw-rw-r-- 3 www-data www-data  4096 Jul  5 15:08 private

My new and work fine configuration

chmod 774 -R /var/drupal-bc/sites/default/files
chmod 774 -R /var/drupal-bc/sites/default/private

drwxrwxr-- 2 www-data www-data  4096 Jul 31 12:35 files
drwxrwxr-- 3 www-data www-data  4096 Jul  5 15:08 private
Improve this answer
1
  • Yes, execute is required on folders to be able to use them. 775 would likely be more appropriate than 774. In your case with the way your ownership is set 755 would also be a good option.
    – rooby
    Oct 4, 2013 at 12:59
1

Correct permissions for temporary folder depends on your web server configuration.

If running Drupal with PHP as module of web server, for example Apache, when user which is defined in main web server configuration file using User directive should have write acccess to it.

% grep -i "user" /etc/httpd/conf/httpd.conf

User apache

Improve this answer
1

I had this same problem after moving from one server to another.

I tried everything suggested here, setting folders to 755 and so on.

My temporary folder was set to ""tmp7zXhVVCO" and it actually copied the installation files nicely, after every retry i saw the temp file being copied there, but installation kept failing.

The problem however is the owner not the rights, wich is why 777 removes this error, but we all know that this is not a way to go on production sites.

What you should do, is change your temporary folder to anything else, such as "temp" or whatever suits you, as long as it does not exist yet, drupal will create this new folder with apache rights, not user rights, and your problem will be solved.

Improve this answer
1
  • When I do this I get the error The directory ../temp2 does not exist and could not be created.
    – Paul Trotter
    Feb 11, 2015 at 15:18
1

I don't really like any of the existing answers so I'm just going to start one myself that I'll probably update over time. Mainly with shell commands.

For now, run this from sites/example.com:

MYSITE=example.com
FILES=sites/$MYSITE/files  
# CSS and JS might also cause trouble and advagg has its own dirs
TMPDIRS=$FILES/tmp $FILES/js $FILES/css $FILES/advagg_*
drush vset file_temporary_path $FILES/tmp # seems better than using /tmp
drush vset file_directory_temp $FILES/tmp
cd $(drush drupal-directory)   
chown www-data -R $TMPDIRS
chmod 755 -R $TMPDIRS
Improve this answer
1

From Configuration -> Media -> File System I removed the / temp-catalogue. After that I didn't have any problems.

Improve this answer
1

I had the same issue on a migration . I have chmod 777 all the sites/default/files but the error still happens. I change permission 775 on sites/default/files and message disappeared . I was not a private path problem , mine is /var/tmp but the 775 permission .

Improve this answer
1

If you run across this problem using Pantheon and continue to get the error after setting the (temp) files directory path(s), you may also need to switch the Connection mode on your dev instance dashboard from Git to SFTP.

Your Drupal site may be attempting to save files to a directory managed by Git (e.g. if you are changing layout settings and the like in an Adaptive Themes theme). In order to do so, switch to SFTP. Once the files have been saved, you can switch back to Git, and the dashboard will prompt you to commit the changes that have been made on the server.

Improve this answer
1

I had the same problem.

I was using IIS in Windows. Finally the problem was for the permissions in folder sites/default/files and, obviously, in sites/default/files/tmp.

Finally I gave again "Full permissions" to the folders, and it worked.

Regards

Improve this answer
1

I am using Drupal 9, in my case the folder where the translations are saved was missing. When I went to "Home -> Administration -> Configuration -> Multimedia", the path of the translations was in "sites / default / files / translations" and I was missing the "translations" folder.

Improve this answer
0

If you getting something like:

 Drupal\Core\File\Exception\DirectoryNotReadyException: The specified file 'temporary://somefile' could not be copied because the destination directory () is not properly configured. This may be caused by a problem with file or directory permissions....

And you're on Linux (Redhat or Centos) and none of the above solutions work, then check on the "SELinux". Start by looking at logs (which vary). In mine, i found the issue at: /var/log/warn .... says SELinux is preventing the given process.... from write access on the directory....

Then you would have to search how to give the given process SELinux read or write access to the path under questions (usually /var/www/html/xxx).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.