file download path not writable

detail · 2017-12-11 10:49:04

gaekwad wrote #308232:

Wild guess – OP is using Transmit or other similar FTP program and that’s the result when you copy+paste the directory location.

That is correct. I’m using Coda 2 to check that the “missing” files are there on the server. They all are.

Last edited by detail (2017-12-11 10:49:42)

Bloke · 2017-12-11 10:51:59

So what is the value of your ‘File directory path’ pref, and does it correspond to the actual directory where the files are now stored on the new server?

jakob · 2017-12-11 10:56:42

gaekwad wrote #308232:

Wild guess – OP is using Transmit or other similar FTP program and that’s the result when you copy+paste the directory location.

Yes, agree. I think you get something like that when you choose “copy path” from Transmit.

@detail: Well, to conclusively check the permission thing, try 777 for the directory and if that doesn’t work, it must be something other than a permissions thing. Even if a file owner changes (look up CHOWN) e.g. as a result of the server upgrade, it should be accessible with 777 (as far as I know).

You might also want to check the permissions for an individual file in the folder. They should, I think, be 644.

Presumably, the files don’t download anymore from the public-facing site? And if you try manually entering the path www.mysite.com/files/myfile.pdf (or whatever path you are using) can you reach the files?

detail · 2017-12-11 11:00:44

Bloke wrote #308235:

So what is the value of your ‘File directory path’ pref, and does it correspond to the actual directory where the files are now stored on the new server?

Everything on the website is working as expected except for the file downloads. It has about 1000 pages, all with images on them. The only thing not working are the 20 pdf downloads that are stored in /files/.

File directory path is not writable: /home/content/d/e/t/detail/html/files

Textpattern path: /home/content/39/6300239/html/cycletrails/textpattern

jakob · 2017-12-11 11:06:25

And with the file path as?

/home/content/39/6300239/html/cycletrails/files

(like I suggested above ?).

Bloke · 2017-12-11 11:08:03

jakob wrote #308242:

And with the file path as? /home/content/39/6300239/html/cycletrails/files...

‘zackly! This happens because files are treated as a full path, whereas images are just a subdir. So if the host path changes, the file links all break but the images continue to work.

detail · 2017-12-11 11:22:55

jakob wrote #308238:

Yes, agree. I think you get something like that when you choose “copy path” from Transmit.

@detail: Well, to conclusively check the permission thing, try 777 for the directory and if that doesn’t work, it must be something other than a permissions thing. Even if a file owner changes (look up CHOWN) e.g. as a result of the server upgrade, it should be accessible with 777 (as far as I know).

You might also want to check the permissions for an individual file in the folder. They should, I think, be 644.

Presumably, the files don’t download anymore from the public-facing site? And if you try manually entering the path www.mysite.com/files/myfile.pdf (or whatever path you are using) can you reach the files?

All still with Condition: missing. Even though I uploaded a new copy of the file.

Changed all permissions to 777, but have changed them back to 775 to avoid hacking.

Can’t access via the path as suggested.

After midnight here in NZ and I’ve been up since 5 am. Will have to look in the morning. This situation has been around for most of the year since I changed server so 99% of the site is working.

Will have a think in the next couple of days. Will upgrade to 4.6.2. About time huh?

Thanks everyone for your help.

Bloke · 2017-12-11 11:27:11

No worries.

I can virtually guarantee it’s not permissions related. Just change your ‘File Directory Path’ pref (it’s probably on the Advanced Prefs in 4.5.x: we got rid of that separation 4.6+) to /home/content/39/6300239/html/cycletrails/files and everything should come back.

detail · 2017-12-11 11:37:39

Bloke wrote #308244:

‘zackly! This happens because files are treated as a full path, whereas images are just a subdir. So if the host path changes, the file links all break but the images continue to work.

Changed the file path as suggested. Finally. (it’s late.)

A couple of files have Condition: OK next to them in green which is a start.

Thanks for that explanation. I’ll finish this tomorrow.

Oh, it is tomorrow.

detail · 2017-12-11 20:13:45

Bloke wrote #308247:

I can virtually guarantee it’s not permissions related. Just change your ‘File Directory Path’ pref (it’s probably on the Advanced Prefs in 4.5.x: we got rid of that separation 4.6+) to /home/content/39/6300239/html/cycletrails/files and everything should come back.

Yahoo!! This has now been resolved.

It was the file path as the diagnostics, and Bloke stated.

In summary

My multi website TXP installation was changed to a different server when I changed my websites from http to https.

The file path for the TXP installation was automatically changed in the admin/preferences panel. (It’s a while ago, is that possible or was I informed about what I needed to do by my host?)

The websites all worked as expected on the new server, except for anything in /files/. That is where some documents available for download are kept. Attempts to download were given the 404 error page, and TXP diagnostics stated File directory path is not writable: /home/content/d/e/t/detail/html/files

I changed the file path and it all worked once again. (There was a complication in that I have a number of websites on the installation and a few different /files/ folders. I copied the files to the right one.)

So, the message is that when changing your server checking that pages with images are working correctly is not enough. As Bloke said, images are treated differently from files in this instance. You need to check that the path for any files is correct as well.

This is probably TXP 101 but I’m a fairly intermittent user.

Thanks everyone who contributed here. Amazing the clarity I found at the start of a new day.

Last edited by detail (2017-12-11 20:16:45)

Bloke · 2017-12-11 22:26:23

detail wrote #308263:

Yahoo!! This has now been resolved. It was the file path as the diagnostics, and Bloke stated.

Awesome.

You need to check that the path for any files is correct as well.

Yeah. If the host changes, we can guess the txpath and change the path to site, but we don’t want to assume that your files follow the same prefix.

I believe the reason files use an absolute path is so you can move them wherever you like – even to a non-web-accessible area so you can serve them in special ways, like smd_remote_file does. Since images, by their very webby nature, must be web accessible, we adopt a convention for convenience and swing them off the txpath using a relative path. Hence, images don’t break but files might.

What’s confusing is the error message that the directory is not writable. It’s correct insofar as it can’t write to the directory, but the reason it can’t write to it is that it might not exist in the first place! We don’t test for existence separately from the test for being able to write to it. Perhaps we should, for clarity, only perform the write test if the directory exists?

detail · 2017-12-11 22:41:43

Bloke wrote #308264:

What’s confusing is the error message that the directory is not writable. It’s correct insofar as it can’t write to the directory, but the reason it can’t write to it is that it might not exist in the first place! We don’t test for existence separately from the test for being able to write to it. Perhaps we should, for clarity, only perform the write test if the directory exists?

In retrospect this error message was actually correct.

My problem was that I was looking at two separate /files/ due to the multi-website installation.

It’s also, I guess, correct to have any sensitive files potentially elsewhere for security reasons.

The main thing is for users to be somehow aware of the difference in the way images and files are treated when servers are changed.

I guess this is only really an issue for those with stuff in /files/. Only one of my websites has that. Maybe this thread is sufficient to alert people to the issue.

Textpattern CMS

Textpattern CMS support forum

#13 2017-12-11 10:49:04

Re: file download path not writable

gaekwad wrote #308232:

#14 2017-12-11 10:51:59

Re: file download path not writable

#15 2017-12-11 10:56:42

Re: file download path not writable

gaekwad wrote #308232:

#16 2017-12-11 11:00:44

Re: file download path not writable

Bloke wrote #308235:

#17 2017-12-11 11:06:25

Re: file download path not writable

#18 2017-12-11 11:08:03

Re: file download path not writable

jakob wrote #308242:

#19 2017-12-11 11:22:55

Re: file download path not writable

jakob wrote #308238:

#20 2017-12-11 11:27:11

Re: file download path not writable

#21 2017-12-11 11:37:39

Re: file download path not writable

Bloke wrote #308244:

#22 2017-12-11 20:13:45

Re: file download path not writable

Bloke wrote #308247:

#23 2017-12-11 22:26:23

Re: file download path not writable

detail wrote #308263:

#24 2017-12-11 22:41:43

Re: file download path not writable

Bloke wrote #308264:

Board footer