I did a dumb thing. When I first installed my site on my hosting service, I unpacked the tarball in the wrong place. Instead of unpacking it in ~/sitename, I unpacked it in ~/sitename/drupal-5.3/. I ran like that for a while then decided to move the whole drupal directory tree one level up.
Now, I get complaints that "The directory files is not writable". Only now have I noticed the warning, "Changing this location after the site has been in use will cause problems so only change this setting on an existing site if you know what you are doing." Ooops. What do I need to do to fix the problem?
-- roy@panix.com
Now, I get complaints that "The directory /files/ is not writable". Only now have I noticed the warning, "Changing this location after the site has been in use will cause problems so only change this setting on an existing site if you know what you are doing." Ooops. What do I need to do to fix the problem?
Did you try putting files back into ~/sitename/drupal-5.3/ ? Meaning:
~/sitename/drupal-5.3/files/
Leave all else in ~/sitename/ and just move files.
:)
Fred
It turns out, the problem was not that the path changed, but that the permissions were wrong. Setting the permission on ~/sitename/files/ to 0777 (i.e. world-writable) made the warning go away. On the other hand, it doesn't seem right that a directory should have to be left wide open like that. Is that really how it's supposed to be?
On Nov 18, 2007, at 10:36 AM, Fred Jones wrote:
Now, I get complaints that "The directory /files/ is not writable". Only now have I noticed the warning, "Changing this location after the site has been in use will cause problems so only change this setting on an existing site if you know what you are doing." Ooops. What do I need to do to fix the problem?
Did you try putting files back into ~/sitename/drupal-5.3/ ? Meaning:
~/sitename/drupal-5.3/files/
Leave all else in ~/sitename/ and just move files.
:)
Fred
[ Drupal support list | http://lists.drupal.org/ ]
-- roy@panix.com
It needs to be read/write/executable to whatever user apache runs as. Ideally that would mean putting apache and the owner of the files in the same group and then setting permissions to 0775 instead, but on most shared hosts you can't actually do that so you have to use 777.
On Sunday 18 November 2007, Roy Smith wrote:
It turns out, the problem was not that the path changed, but that the permissions were wrong. Setting the permission on ~/sitename/files/ to 0777 (i.e. world-writable) made the warning go away. On the other hand, it doesn't seem right that a directory should have to be left wide open like that. Is that really how it's supposed to be?
On Nov 18, 2007, at 10:36 AM, Fred Jones wrote:
Now, I get complaints that "The directory /files/ is not writable". Only now have I noticed the warning, "Changing this location after the site has been in use will cause problems so only change this setting on an existing site if you know what you are doing." Ooops. What do I need to do to fix the problem?
Did you try putting files back into ~/sitename/drupal-5.3/ ? Meaning:
~/sitename/drupal-5.3/files/
Leave all else in ~/sitename/ and just move files.
:)
Fred
[ Drupal support list | http://lists.drupal.org/ ]
-- roy@panix.com
Larry Garfield wrote:
It needs to be read/write/executable to whatever user apache runs as. Ideally that would mean putting apache and the owner of the files in the same group and then setting permissions to 0775 instead, but on most shared hosts you can't actually do that so you have to use 777.
755 works for me one two different shared hosts actually. I have no info about groups--just the ability to set permissions on the dir.
Freddie
Fred Jones / 07.11.18 / 0:48 PM wrote:
755 works for me
This doesn't work for me, and was wanted to ask a question. Whenever you let Drupal upload files or create directory, they are owned by Apachie. I loose my own control. So many times I had to ask my ISP to chown. Now I am afraid to use CCK for images because of this. I have been doing HTML for images in the body. How is this should be dealt with?
A-NO-NE Music wrote:
Fred Jones / 07.11.18 / 0:48 PM wrote:
755 works for me
This doesn't work for me, and was wanted to ask a question. Whenever you let Drupal upload files or create directory, they are owned by Apachie. I loose my own control. So many times I had to ask my ISP to chown. Now I am afraid to use CCK for images because of this. I have been doing HTML for images in the body. How is this should be dealt with?
One thing you should be able to do is write some PHP that can change the user/permissions of the file, then run that through your web browser. Obviously, this is *not* something you want wide open, but if you write the code carefully, it will execute as the the 'apache' user and do what you want it to.
Pete
On Nov 18, 2007, at 1:43 PM, Larry Garfield wrote:
It needs to be read/write/executable to whatever user apache runs as. Ideally that would mean putting apache and the owner of the files in the same group and then setting permissions to 0775 instead, but on most shared hosts you can't actually do that so you have to use 777.
Hmmm. This seems really ugly. I want to have a members-only section, where I can upload private files as attachments to stories. The nodeaccess module lets me restrict access to the story itself, but it looks like the file attachments would be wide open to any other customer of my web hosting service who can find the directory via the file manager (or shell access). Surely this is not good.
-- roy@panix.com
Hmmm. This seems really ugly. I want to have a members-only section, where I can upload private files as attachments to stories. The nodeaccess module lets me restrict access to the story itself, but it looks like the file attachments would be wide open to any other customer of my web hosting service who can find the directory via the file manager (or shell access). Surely this is not good.
This is where .htaccess comes into its own perhaps.
You should be able to block access to the files directory and others you don't wish people to browse to.
Kelly
-
A-NO-NE Music -
Fred Jones -
Kelly Harding -
Larry Garfield -
Pete Prodoehl -
Roy Smith