The specified file temporary://fileh4Oxvi could not be copied, because the destination directory is not properly configured. Thi

By Anuprita Sapate on 24 Jan 2014 at 05:51 UTC

The specified file temporary://fileh4Oxvi 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.

//fileh4Oxvi, fileo7zFPQ,filesK4yO7
whenever i click on any menu or any content type, i get different file like fileh4Oxvi,fileo7zFPQ,filesK4yO7
where could be the problem??
Do help a need.
Thankyou for your response in advance.

Comments

This implies the target

John_B commented 24 January 2014 at 17:21

This implies the target directory is not writable by the web server.

See https://drupal.org/node/244924

The short answer is to find out which user owns the web server (e.g. apache) process, then set the directory (usually every file and directory in your Drupal installation) to be owned by that user. This applies when PHP is executed by the server. On shared hosting often PHP is executed by the owner of the hosting account, so that the user name which should own the folders.

On shared hosting it is a problem for your web host to resolve (if they are any good, many are not) so you only need to know this stuff if you are running your own server, or battling with a poor quality web host.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Thx a lot John for your

Anuprita Sapate commented 27 January 2014 at 05:05

Thx a lot John for your information.
It is really helpful.

Yes, John_B has probably the

Yuri commented 21 September 2017 at 21:46

Yes, John_B has probably the answer that is most common for this issue. In most cases it is the ownership of the folders/files mentioned in
/admin/config/media/file-system
Ownership needs to be set to the user account / owner of the web server.
In most cases the permissions are not the issue.

Thank you .

sami-an commented 26 April 2019 at 07:49


I found the solution from you

1- cd /sites/default

2- $ chmod 777 -R files

No, you haven't !

mmjvb commented 26 April 2019 at 10:21

Look again, that is not the solution provided!

hint chown instead of chmod

Thank you : mmjvb

sami-an commented 27 April 2019 at 12:18

Thank you : mmjvb

One more thing to try

zonesny commented 7 July 2015 at 18:13

John B's comments are on the money. Permissions need to be changed for the MAMP folder and subdirectories. However, I've experienced these errors even after changing permissions!

Switching the server user back and forth seems to fix it.

Go to the MAMP console (I'm using version 3.3 at the moment) under "General" tab, go to the setting for "Run Apache/MySQL server as user".

In my case this is currently set to www (Apache) / mysql (MySQL).
So I change it to username (Apache) / username (MySQL).

Save and restart the servers

Refresh the browser, then change it back to www (Apache) / mysql (MySQL), save and restart, and all is well.

One more tip, if you wish to run the servers as "www", you can go to the finder, click on the MAMP folder and press "command" and "i", under "Sharing & Permissions" click on the lock to open it, then press "command" and "+" to open "Users & Groups" directory. Scroll to the bottom and select the "World Wide Web Server"--make sure it's the one with the single silhouette. This will add "_www" to the permissions list. You'll want to click on the the cog icon at the botton of the info window and "Apply to enclosed items..." That's it.

Solution

albertguedes commented 22 October 2015 at 19:16

To me, its fix all my problems :

sudo chmod -R 777 sites/default/files/tmp

777 is unnecessary and a security risk.

eauxnguyen commented 25 October 2015 at 14:57

Hey Albert just thought I'd help out where I can. After copying back my sites directory it showed as owned by apache:apache yet I got this error as well. sudo chown -R apache:apache seems to reset ownership of the sites folder and fixed the issue.

Solved

Robin Rosh commented 22 February 2022 at 12:05

yes this is also the solution for my issue.

Not a solution, creates more problems

mmjvb commented 22 February 2022 at 12:40

At least when referring to chmod 777.

NEVER, EVER A SOLUTION !!!

In relation to backup_migrate

lancewig commented 21 June 2016 at 03:31

You may get this warning with the Backup Migrate module. In that case make sure to visit the Settings page for Backup Migrate and add a Destination on the server for staging backup files for import.

Even if this is already a bit

treehacker commented 13 March 2017 at 17:17

Even if this is already a bit old.... I had the same issue now with a Drupal 7 Install working with the translation update. After setting all permissions correctly it still didn't work until I realized that the translation update module has its own file path for translations which is set by default to /sites/all/translations.

Only permission problem

karthik Raja V commented 7 July 2017 at 13:47

I had this problem often when I changed the some other configurations. Finally I got the solution change the file permission or please check the admin/config/media/file-system. No need to to spemt times what we have configured recently.I hope help for this.

Thanks
Karthik

I have some problem

sadam 001 commented 30 August 2017 at 06:28

How to solve this problem?

Follow the config

karthik Raja V commented 11 May 2018 at 15:35

In media file system

Public file system path --->sites/default/files

Private file system path --->sites/default/files If needed.

Temporary directory --->/tmp

Please do the settings and check

Karthik

Identical Issue once google_tag was enabled

SpiesInOrbit commented 9 October 2017 at 05:29

As soon as I enable the google_tag module, the error appears and none of the suggestions work. I've tried changing the user's permission and change the owner, but more files appear in my "Temporary destination"

with an error like: The specified file temporary://file1GEFXF could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions...

[update] A google_tag directory appeared in my sites/default/files directory and it had the wrong user. A simple:

chown www-data:www-data * -R

on the google_tag folder found in the file-system. The error does not point to the correct path of the issue.

Identical Issue once google_tag was enabled - language part

c-tools commented 6 January 2018 at 14:00

As mentioned by SpiesInOrbit, I have just experienced the same once google_tag has been enabled.

I have been able to fix error like "The specified file temporary://file1Gxxx 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 specificaly with the following permissions

in my site directory

chmod 1775 -R sites/default/files/google_tag/language/

Hope it helps

i have a fresh install of

MartinSWE commented 19 February 2018 at 09:38

i have a fresh install of "commerce profile" with core on a fresh LAMP server in google cloud and get this error when i try to change the "Mobile first or Desktop first" in "global setting" (Home » Administration » Appearance » Settings).

but right now, finally i got it worked when i chowned everything under /var/www/ to www-data.

thanks for a great site.

Update path to temporary directory

xeiro commented 13 March 2018 at 02:55

I received this message when working on a site that was copied over to another server, and located within a subfolder.

To correct, you need to make sure the tmp folder path is listed correctly under /admin/config/media/file-system. In my case, the copy of the site was relocated to a subfolder rather than the root directory, so I needed to change the path from “/tmp” to “../tmp”. This worked without having to change any file permissions.

also check selinux

sergiomb commented 18 July 2018 at 19:11

On Centos 7 we need set permissions on selinux like this:

semanage fcontext -a -t httpd_sys_rw_content_t '/usr/share/drupal7/.*' restorecon -Rv '/usr/share/drupal7/'

Grant "Apache2 HTTP server" right on files folder

OCTOGONE.dev commented 12 November 2018 at 17:08

Grant "Apache2 HTTP server" right on "files" folder resolved the issue for me: open a command line in "sites/default" folder if you use a GUI, or go there if you are in console mode and run:

chgrp -R www-data files

The solution : Yuri

sami-an commented 26 April 2019 at 07:46

1- cd /sites/default

2- $ chmod 777 -R files

Thanks !

gourav.yadav commented 20 November 2019 at 06:05

it's worked, Thanks !

Unable to use Backup-Migrate in Drupal 8.8.1

spatialcase commented 6 January 2020 at 13:32

	Backup-Migrate is failing (even though it cheerfully declares 'Backup Complete!'), the following message appears in the log: "The specified file 'temporary://bamNHeV18' could not be copied because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions." The web server (www-data) owns the tmp directory and the private-files directory. It has group ownership of the sites/default/files directory. The settings.php file settings look good and are reflected correctly in the configuration/media/file system page. I have also ran find ${x} -type d -exec chmod ug=rwx,o= '{}' \; find ${x} -type f -exec chmod ug=rw,o= '{}' \; against all files and directories in the files directory. I have not seen any files appear in the temporary directory. Running Ubuntu 18.04, drupal 8.8.1 and Apache - all fully patched. Apache and system logs don't seem to record any useful information relating to this. Could anyone suggest other logs that might be helpful - or any potential solutions? Thanks, Graham

Backup-Migrate is failing (even though it cheerfully declares 'Backup Complete!'), the following message appears in the log:

"The specified file 'temporary://bamNHeV18' could not be copied because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions."

The web server (www-data) owns the tmp directory and the private-files directory. It has group ownership of the sites/default/files directory. The settings.php file settings look good and are reflected correctly in the configuration/media/file system page. I have also ran find ${x} -type d -exec chmod ug=rwx,o= '{}' \; find ${x} -type f -exec chmod ug=rw,o= '{}' \; against all files and directories in the files directory.

I have not seen any files appear in the temporary directory.

Running Ubuntu 18.04, drupal 8.8.1 and Apache - all fully patched.

Apache and system logs don't seem to record any useful information relating to this. Could anyone suggest other logs that might be helpful - or any potential solutions?

Thanks, Graham