I'm getting "destinationPath is not writable"

[landitus]

Hi, all! I've encountered the following error message when trying to upload images in the server: "destinationPath is not writable". I've tried modifying permissions on the assets/files folder to "777" but no luck. I'll appreciate any help!!

[Soma]

Hello landitus,

not sure, are you using latest PW2.1? There used to be such an issue which was fixed. Any more infos you might can give can be helpful.

[landitus]

Thanks for the reply! I am indeed using ProcessWire 2.1.0. and the server uses PHP Version 5.2.17. Anything else you need to know?

[12345j]

hey,

try opening up wire/modules/inputfield/inputfield.module and change this line

if(!is_writable($this->destinationPath)) return $this->error("destinationPath is not writable"); 

to

if(!is_writable($this->destinationPath)) return $this->error($this->destinationPath." is not writable"); 

and see what the error is.

[landitus]

When I change that line, I don't get any errors and get a green session saved flash notice. The problem still remains and no image is saved.  :-\ Is this a permissions problems? What can I do?

[Soma]

Do you have debug mode on? In your site/config.php ... There might be more errors showing.

Not sure what the problem could be. Safe Mode on/off? in php? Have you manually uploaded the pw folders over ftp , so ftp user/group permission doesn't allow php to write in even if 0777... there can be many reasons.

[ryan]

When I change that line, I don't get any errors and get a green session saved flash notice.

That's unexpected. I have no idea what that would be. Doesn't sound like something coming from ProcessWire.

I agree with everything Soma and 12345J said.

When you get a "destinationPath is not writable" message, that only comes as a result of a permission issue. 12345J's suggestion was just to rule out the possibility that destinationPath isn't what we think it is for one reason or another, as well as to point out what the directory is so that we know what we're troubleshooting. But if you aren't even getting an error message when changing to his suggested code, that's a bit unusual. Why don't you just try changing it to this temporarily:

if(!is_writable($this->destinationPath)) die($this->destinationPath . " is not writable"); 

That will halt execution and give you the message indicating exactly what directory isn't writable.

Most likely there is a permission issue affecting the directory due to some change at the server or a site migration that didn't retain permissions. If you have shell access, a simple way to resolve it would be this:

cd /your/web/root/ 
chmod -R og+rw ./site/assets

If that doesn't do it, or you don't have shell access to do that, then I'd suggest creating a simple test script that you can use to help resolve it without having to upload an image every time. Place this in your web root in a file called test.php:

/test.php:

<?php
if(is_writable('./site/assets/files/1/')) echo "Writable!";
    else echo "NOT writable!";

If you know the ID of your page, replace the "1" in the path above with the ID of your page. For instance, ID 123 would be: ./site/assets/files/123/

[landitus]

Thanks for all the answers.

I have debug mode ON, and right know, I do not get any errors and all images upload but are not saved/not displayed. The is writable test was successful, and it displays: Writable!

I am really lost... 

[landitus]

I've noticed that a folder for the ID (1420) was created under site/assets/files, but it's empty. Maybe it helps. I did transfer all files with an FTP and then manually changed permissions on the assets folder. That's when the error message disappeared. The result now is no errors but no image is saved on the server.

It really looks like a server issue, isn't it?

[ryan]

It's hard to tell because the conditions seem to be changing. It also sounds like session messages were appearing that aren't part of ProcessWire. It may be good to replace your /wire/ directory with one from a fresh download of ProcessWire 2.1. Though lets look at your phpinfo() first.

That's good that the directory appears to be writable, but if your uploads aren't going there, then not good. If you want, PM me a link to your phpinfo() and I can have a look to see if there's anything about the server's configuration that might be causing a problem. To get the PHP info, just paste the following into your /test.php, and then send me the URL:

<?php phpinfo(); 

[ryan]

Thanks I got your PM. The only thing I see as a possible issue in your phpinfo is that safe_mode is ON. I can't say as though I've come across a hosting environment with this turned on before. But my understanding of it is that if a server has safe_mode on, then the PHP script can't move/copy files unless it is the owner of those files. PHP appears to be running as an apache module rather than as a CGI on your server. So there is going to be some variation in permissions between your account and that of Apache. Usually not a problem at all, except when combined with safe_mode, that creates some headaches and could definitely interfere with file uploads.

The first thing I want you to try is to create this directory and make it writable to all. Later on, once you know it's working, it'd be better to make it just writable to PHP (if you know what user it's running as). But if this is a dedicated server or the accounts are well jailed, then not a big deal. But for now create this directory and make it 777 (rwxrwxrwx):

/site/assets/cache/uploads/

Then add this to your /site/config.php at the bottom:

ini_set('upload_tmp_dir', $config->paths->cache . 'uploads/'); 

See if that resolves it. If not, the next thing to try is to see if your web host lets you create your own php.ini, or modify the php settings for your account. Many web hosts let you do this, but you might have to search around in their support docs. You will want to disable safe_mode, which can't be done at runtime with ini_set(). Let me know if you get to this point and I can help you figure it out.

If none of those are an option, then I'd be willing to experiment on the server to find a solution if you don't mind giving me access temporarily.

Btw, the site you have running on that server is gorgeous–beautiful design.

[Soma]

Ryan that's exactly the combination I'm facing with a website hosting I need to do a relaunch. I installed PW and got the same error, so I figured out that save_mode is on. That's why I was asking this.

Having only faced 2-3 such configuration yet in all the years from friends... I for myself decided to simply tell the owner to change hosting provider.  Everytime it got chaotic and it took them ages and 1000000 emails to get them the configuration only nearly right. Often they are shared hostings with php running as a module to save money and have no clue.

[ryan]

Yeah I'm not sure why any web hosts would be using safe_mode when running PHP as an apache module, but it does point to possible issues at the host. However, I would like to find a way to make PW recognize and adapt to the situation if at all possible. Thankfully in PHP6 things like safe_mode and magic_quotes will be permanently gone.

[martind]

just want to note here, I had the same issue on an installation reachable with 3 subdomains on the same webspace. Everything worked fine while the url was the same than on installation. Problems as described above came up after the first call with the new subdomain. no login possible (resolved by delete all session files), errors about the unwritable img path on saving entries. the solution for me was to chmod 777 /assets, /session, /cache, /files and all it`s subdirectories. safe_mode is off. maybe this has something to do with sessionFingerprint and sessionChallenge, but haven`t looked further in this because everything works fine now.

[ryan]

ProcessWire assumes that the entire /site/assets/ structure is writable. As long as PW can write to any directories in there it should be happy. What you have to do to make that writable depends on the server environment. If Apache is running as your user account (like PHP as a cgi) then it only needs to be writable to you. If PHP is running as a module on Apache (as is most common) then that directory needs to be writable to whatever user PHP is running as. In a dedicated environment or a reasonably secure server environment where accounts are well jailed from each other (as are many major hosting providers) 777 (drwxrwxrwx) on those dirs ensures PHP can write to it without you having to determine what user PHP running as. This is the default that ProcessWire uses for the directories it creates in /assets/ (according to the predefined setting in /site/config.php). In a less secure hosting environment where accounts aren't well jailed from each other, it's preferable to use PHP as a CGI and use permissions where only your account can write to the /assets/ directories (and likewise update the permissions in /site/config.php). But that's for long term. When you are running into write errors in /assets/, do what you need to do to get it working, then determine if you need to lock it down further.

[landitus]

Finally, the server provider turned off safe_mode and now everything is working properly. Unfortunately, I couldn't get any feedback to getting it to work with safe_mode on, but at least they changed the setting for me.

I wan't to thank everyone for all the help and patience!! I'm very happy everything is working ok!!  :)

[ejdamd]

My provider doesn't want to turn safe_mode off, he thinks it's too unsecure. Unfortunately it's a bit complicated as my client doesn't want to change provider. Provider told me if folder is made by PHP script, it will be writable for PHP. I'm just thinking why you don't include creating assets folder into installation process.That should resolve similar problems with safe_mode as I have, shouldn't it?

[Soma]

As far as I know PW does write all the assets from the install folder already.

[ejdamd]

As far as I know PW does write all the assets from the install folder already.

But it's not creating assets folder itself.

[ryan]

ProcessWire will give you a warning at install time if the /site/assets/ dir isn't writable. This part really shouldn't matter with regard to safe_mode.

Ejdamd, is some part of PW not working in your case? Let me know, as PW should be safe_mode compatible. But if you are finding it's not we can find out why not and tweak as needed.

Also, I would suggest sending your provider this link. The PHP team strongly recommends not using safe_mode. Servers relying on it tend to be less secure, not more secure. They have deprecated it and it won't be around much longer:

http://php.net/manua...s.safe-mode.php

[ejdamd]

He agreed yesterday to turn off safe mode on my FTP. I just installed PW again and it works without problems.

Problem before provider turn safe_mode off was that each change of any article or section in PW admin leads to error messages like: "/assets/cache/page/ doesn't exists". Some changes were done though, but system probably couldn't write to assets folder and it was causing problems.

I was looking for some solution through this forum and internet and there was tip that PHP script can create and change files even with safe_mode turned on if folder is created by script itself. Not by user over FTP.

That's why I made an proposal to let install script create assets folder.

[ryan]

Glad they were able to turn off safe_mode for you there, and that all is working now.

However, I think there is something more than just safe_mode at play here, because it really shouldn't be preventing PW from creating its assets folders. Having the install script create the assets folder doesn't help us here because then that would just throw the question back to the previous directory. If we can't create /site/assets/files/ then it's reasonable to assume we also can't create /site/assets/ ... all the way back to the web root. And ProcessWire can't create the web root. I'm guessing Apache was running under something other than your account, and the fix under safe mode would have been to change the /assets/ directory ownership to whatever user Apache was running as. But I can't say for certain. Just glad you convenced them to turn off safe_mode, as I think they are a lot better off now.

[alan]

I go this too.

I read Ryans comment

ProcessWire assumes that the entire /site/assets/ structure is writable

and used my FTP client to recursively set all contents of assets to 777 and it solved the problem. Thanks

Edit: Uh oh, spoke too soon, that cured the error seen in Admin but gave me Bad Gateway 502 on the public side...

Edit: OK, my fix was:

1. turn on debug

2. use FTP to NOT recursively set all to 777 but from errors shown in the login screen, set folders to 777, I had to set (from memory, I think):

assets

cache

files

sessions

LazyCron.cache

assets/files/-all-folders-here

assets/cache/form-builder (404 if not)

BUT also set

assets/cache/form-builder/form-1 to 777 and that produced 502 bad gateway, set it back to how it was and all OK.

This is the SINGLE thing that I feel fragile about with PW, publishing and permissions. While there were a great many things that 'hurt' with other CMSs I did find uploading to be 'easy' - export the DB, import it, upload all files. Done. I would LOVE to know what should be the perms for the folders in PW, probably all I need to know is /assets/* since it seems I have found some (all?) of the right settings but I would like to be sure for next time. Does such a thing exist (i.e. that tells me making .../form-1 777 will kill the for and put it back to 755 etc)?

Edited March 27, 2014 by alanfluff

[teppo]

You'll want to make sure that your Apache user has read, write and execute permissions to assets and it's subfolders. Other directories you rarely need to worry about. Setting permission 777 to whole assets directory recursively (chmod -R 777 site/assets/) is more than enough.

You could be more specific and only allow it to only write into assets/files/, assets/cache/, assets/logs/ and assets/sessions/, but then there are modules that write directly to assets folder and would fail after this.

Bad Gateway 502 as a result of this sounds like some strange server setting -- I've seen shared hosts throw errors if a file is executable/writable by all users (security feature attempting to mitigate risks usually caused by shared hosting itself, kind of ridiculous really), so this could possibly be something like that. In those cases you'll need to configure permissions properly: only give write and execute permissions to the user Apache is running as (often that would be your own user account). The host most likely explains this stuff somewhere.

Apart from that I've no idea what could be causing that.

[alan]

Thanks Teppo.

I'd always assumed that

Setting permission 777 to whole assets directory recursively (chmod -R 777 site/assets/) is more than enough.

was OK, but twice I've done that and it breaks stuff :/ This latest time I found at least one place where that happened: I set each folder

.../assets/cache/form-builder/form-1

(not recursive) to 777 and when I did form-1 it broke (the form went 404) so I returned it to 755 and OK.

So I still feel a little like I'm treading on egg shells when I FTP up a PW site in a way I didn't with say Perch or Textpattern. Since this is the single fragility/criticism I* have (*I am sure others must not have this problem so I wish I knew what it was with me!) I have almost nothing to complain about and a massive amount to be thankful for -- give me this FTP oddity of mine with PW any day and I'll take the PW route *every* time; I just hope one day to understand what I am doing wrong or how my MAMP Pro setup is wrong or how my use of Transmit is wrong.

The site is AOK now after the hand 777s so all good. If that's what it takes next time then I am totally happy -- ideally I would just like a list of the perms for ea directory in say /assets/ that could cause a problem or a guide to them, so I know what to do next time and have no need to trial/error.