By depp on

I get the errors:

The directory files is not writable
The settings have not been saved because of the errors.

When trying to change any setting on the admin/themes/settings. This BREAKS Drupal for me, because the webserver is running from a read-only filesystem! I'm not trying to upload files, I'm just trying to change various other settings on that particular page. Right now I'm thinking Drupal isn't the right CMS for this page (and it's my third Drupal installation). Is there a workaround?

⋅ Categories: Drupal 4.7.x

Comments

Toe’s picture

Toe commented

I don't mean to be pedantic here, but how/why on earth are you running a webserver on a read-only filesystem? I can only assume that the database is on an external server, because if you can't write to the database, you'd never actually be able to create any content with Drupal. I mean, I could maybe understand it if you were just going to be serving a few static pages that will be updated seldomly if ever. But if that's the case, I would say Drupal is most definately the the wrong choice here, just upload some plain HTML files and be done with it.

dublin drupaller’s picture

dublin drupaller commented

Hi Toe,

there's no need to take that sort of tone...there is a problem with some webservers when Drupal creates the folders automatically.

have a look at this issue or the handbook pages addressing Webhosting issues for new Drupal users

I noticed it with Drupal 4.6.3 and now just remember to create the folders myself before installing Drupal.

Dub

Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate

Toe’s picture

Toe commented

Well I can certainly understand the problem with the files folder being created under the httpd's user, having experienced that myself numerous times. But the OP said that "the webserver is running from a read-only filesystem." If we're not talking about a server being run from a read-only media, then I'd say the terminology has been misued. (And yes, such servers do exist, they just aren't normally serving things like Drupal.)

Even if that's the case, no harm done. As I said at the begining of my post, I didn't mean to come across as taking 'that sort of tone'.

tmcw’s picture

tmcw commented

I have the same thing - because my university's (stupid) IT dept. mounts the web server's stuff as read-only - because they are paranoid about security. I know that it's stupid but I don't have any other options.

dublin drupaller’s picture

dublin drupaller commented

there is a problem with some servers where Drupal creates the folders for you. It's not Drupals fault...but there is a workaround if you can't change the FOLDER PERMISSIONS using your FTP programme/control panel or plesk desk.

You simply upload a PHP file (call it something like change.php) into your root folder and then go to that file in your browse...e.g. www.example.com/change.php or if it's in a sub folder, www.example.com/drupalstuff/change.php

here's an example: 

<?php
chmod("/files", 0777);
chmod("/files/images", 0777);
?>

Remember to remove that file when you're finished.

As a tip: in future, it might be better to create the /files/ folder yourself and set the permissions in your FTP programme, before going to ADMIN -> SETTINGS. ditto for the image module (which creates a /files/images and /files/temp/ folder) and the user.module (which creates a /files/pictures/ folder)..and probably others.

Hope that makes sense..

more detailed information is here

Dub

Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate

Ken Watts’s picture

Ken Watts commented

I had the same problem, came to this thread, saw your post, and followed your advice (though my server let me do this directly).

My question is that I have read elsewhere that it is a security problem to have a 777 setting on a folder.

So now Drupal works, but I'm worried about a security breach. Am I wrong about this? Or, if it is a breach, is there something I can do to fix that?

Thanks

kdebaas’s picture

kdebaas commented

How do you set or change folder permissions on the server if it is not UNIX based?

That is to say, I am working in the following environment: Microsoft-IIS/5.0, PHP Version 5.1.6. But I have no direct access to the server, nor any webadmin type of interface. In fact I only have ftp-access. Unfortunately, windows doesn't listen to the UNIX-style permissions settings instructions I pass on to it through the ftp client (filezilla).

I have also tried setting the permissions on files or folders themselves locally, on my windows xp machine, before uploading. All to no avail.

Is the only possible recourse to ask the webhost to change those settings for me? That would be very unpractical for me.

Thanks....
Klaas

depp’s picture

depp commented

All of these comments are unhelpful. The filesystem is read-only to the webserver! It doesn't matter what permissions the 'files' directory has, the webserver will never be able to write to it. Obviously the database server is external, otherwise I never would have been able to create a user account and get to an administration page.

The thing that bugs me is: why does Drupal need write access to the files directory? Drupal isn't actually going to write anything to that directory, yet somehow the fact that that directory isn't writeable is preventing me from unchecking the 'use default favicon' checkbox. That setting is stored in the database anyway. I checked my other Drupal installations, and the 'files' directories never got touched by Drupal.

At this point I'm probably just going to see if PostNuke isn't as broken.

heine’s picture

heine commented

Open modules/system.module, locate line 1045 in function system_theme_settings and add // in front of the check so you'll get:

//  file_check_directory($directory_path, FILE_CREATE_DIRECTORY, 'file_directory_path');

Alternatively open includes/file.inc, locate line 158, function file_check_directory and add as first line return true; so you get:

function file_check_directory(&$directory, $mode = 0, $form_item = NULL) {
  return true;

Untested, so your mileage may vary.

(<?php tags just for pretty colors).
--
When your problem is solved, please post a follow-up to the thread you started.

depp’s picture

depp commented

Thanks, that worked pretty well. I filed a bug because I'd like to see Drupal support read-only configurations out of the box.

I don't think I was really serious about going to nuke, I tried it a couple weeks ago and it gives me the ickies.

Mike Sances’s picture

Mike Sances commented

I've found that XO.com (cnchost.com or concentric (?) in case anyone is searching for threads relating to them and Drupal) doesn't allow CHMOD since they don't use real Unix but something they call "VDE". So no matter what you get the "files directory is not writable" error. Although it's a little dated, the method above for editing the "files.inc" file worked for me--just add 'return true;' to the first line of the function. It gets rid of the status page error AND lets you upload files.

This seems very hacky though and I would also like to see a patch for hosts such as this.

--
http://sances.info

dublin drupaller’s picture

dublin drupaller commented

sorry depp...

how did the /files/ folder get created in the first place if you didn't do it and as you say the "filesystem is read-only"?

Dub

Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate

depp’s picture

depp commented

The webserver is running from a read-only filesystem. The shell server has write access to that filesystem. I created the 'files' directory manually from the shell server.

bullakio@drupal.org’s picture

bullakio@drupal.org commented

In my case I've needed to create a directory with my ftp user with 0777 permissions, upload a php file like that mkdir("files", 0755); mkdir("files/images", 0755) ,this creates 2 directories than belongs to nobody, and after that I've changed my directory to 0755.
With the settings.php I've used a similar procedure. Make the default directory 0777, rename the original settings.php to settings-bak.php, make a file with touch("settings.php"); change its permissions to 0777, copy the content of settings-bak.php into it, change again the settings.php to 0750, delete the settings-bak.php and return the default directory to 0755.

I hope it helps someone with problems with their ftp-web users that can't set a file or a directory to nobody.