I was having some issues with my Drupal Installation and restored from a backup from windows to my Linux Server. The issues had something to do with images in Ubercart disappearing and to fix it I Changed the File System on the Live site (Stupid but I didn't have a test server at the time) and managed to fix it by re-uploading all the images after. The backup I used worked but due to incompatible modules Cron would not run and entering Finals at school I had no time to fix it..

Which brings me to the problem at hand. When Cron runs or i go to the status page ( /admin/reports/status) my default folder changes from 755 to 555 and Drupal is no longer able to write to the directory. I am able to change the permissions back to 755 and it will run again but people at work are entering products into Ubercart regularly and I need Cron to run to update the search cache twice a day. Any Help would be greatly appreciated as well as a recommendation for a Drupal 6 core book.

Thanks,
Nathen

Comments

john_b’s picture

I am sceptical that this can be a Drupal problem.

Presumably you are referring to permissions on the public file folder set for Drupal? Where is that folder?

Some servers have cron jobs which reset permissions for security. I would be suspecting something strange about the server, and wondering about re-installing the OS (!!!)

However, if you are convinced it is Drupal doing it, you must have a hacked version of Drupal core, as far as I can see. You can grep your Drupal code for chmod. You should find the string in file.inc but not so as set file folder to 555.

Interesting problem though.... I have encountered file systems apparently changing unasked /automatically on Linux, though it seems an unlikely idea.

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

stone1652’s picture

I have the folder at /public_html/sites/default. The odd part about this is that Cron doesn't need to run to have the permission change to 555 although running Cron will trigger it. The other thing that will trigger it is visiting the page.

The server I'm hosting on isn't one i have access to the OS so that's sort of out of the question, however I do have a windows based test site that is not giving me this same issue. I am also using a stock version of the core. I have had it work in the past and I also have a separate site with the same host presumably on the same server that is not giving me this error. (It is not a multiple Drupal install)

I am confused about the pathway for the files folder because as i was trouble shooting an issue before this happened I believe the path for the File System was /public_html/sites/default/files. Could this be the cause? There is a warning on the File System page that warns about lost data if the path is changed that's been holding me back from testing.

john_b’s picture

I think you can put your public file system anywhere you like. If you move it for any reason, you will copy the contents across to the new location. I see no reason to move it, it makes no real difference.

If you can set up a Drupal cron job on the server (as you do with Drupal 6 but not 7 to run cron), maybe also set up a cron job to set your folder permissions back to the way you want them, every hour or something....

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

stone1652’s picture

Could it have something to do with having the directory in the same place where the settings.php file resides?

john_b’s picture

I don't see how. Anyway 99% of Drupal sites have settings.php in sites/default/ and also the files/ folder there and this problem is not something anyone else seems to have had. You lose nothing by moving the whole folder and resetting the path in Drupal though.

Settings of course should not be writable. But it should be no problem to have a non-writable file in a writable directory. I did once think that changing a directory permission on Linux seemed to automatically change parent directory, and I never found out why. But Linux is not supposed to do that!

Unless you have hacked code this seems almost impossible to be a Drupal issue. It is puzzling but I feel sure it is a server problem.

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

stone1652’s picture

After backing up the site yesterday I finally got myself to change the File System. Moving the File System back to sites/default/files the Not Writable issue but my my image cache issue came back to a lesser extent than when it broke the first time. Luckily no more than maybe 50 broke and I only had to move some directory's around until it worked.

I appreciate the help John and I hope this helps someone else in the future. :)

Nathen