Posted by manorius on September 9, 2011 at 3:58am
Hi guys,
I migrated a drupal website to the production server and since then I'm getting a lot of permissions errors.
The files and tmp folder are not writable and only when I set the permissions to 777, drupal can write the folder.
Judging from the above problem I guess the owner/group of the above folder is wrong, unfortunately I don't have
permissions to run chown on the production server. So my question is what do I have to ask the server
administrator to set the owners of the folder to? Apache user? And what abou the group?
Any help is highly appreciated,
Manolis
Comments
Basically it should be just
Basically it should be just /sites/default/files chmod to 755 I think? Someone please correct me if I'm wrong.
In addition you may have to ask your svr admin what the real path of the tmp directory. Alternatively you may try to use "/tmp" instead of "tmp" for your temp directory (admin/config/media/file-system), it worked and solved my problem in my case :)
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
That's what I usually do, but
That's what I usually do, but in this case, whenever I set permissions lower than 777 it complains that it doesn't have write permissions for the tmp and file folder
Not only. The permission 755
Not only. The permission 755 have to include your www user (I mean your apache user) because it's your apache user who needs the permission to write and read. Add your apache user to the proper user's group or ask to your administrator to do "chown -R apache-user:apache-group *" on your www folder.
Julien Didelet
Founder
Weblaa.com
Julien you really got some
Julien you really got some wicked skills up your sleeves LOL! Good man! :D
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
lol :). Always learning :)
lol :). Always learning :)
Julien Didelet
Founder
Weblaa.com
I remember I ran into exact
I remember I ran into exact same problem before as well. If I'm not mistaken, it was because Mac only have read/write permissions instead of read/write/execute permissions, which creates problem if you try to chmod in a Mac then upload the files instead of chmod directly in FTP. You may try to chmod on FTP (and recursive to all sub folders) if this seems similar to your case.
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
I have run into the same
I have run into the same problem. Strictly speaking, the problem is not ownership, the problem is that Apache is not allowed to write to those places. You do not have authority to 'chown', but you do have authority to 'chmod', granting others write access. Here is my Linux/OSX shell script:
chmod a+w \ sites/default/files \ sites/default/files/* \ ../private \ ../private/backup_migrate \ ../private/backup_migrate/manual \ ../private/backup_migrate/manual/* \ `find . -name '.htaccess'`The script must be run when your base site directory is the current directory. "../private" is, presumably, the private directory in your configuration, the directory which PHP can read and write but HTTP can not. If you hit any similar errors you can just add those locations to the list.
Note that sites and sites/default do not have to be writable but sites/default/files must be. Apparently the entire Private Directory tree must be writable. And I do not know what the function of those .htaccess files are, but they were created by Apache so they are initially writable by Apache.
Transport error - there must
Transport error - there must be back quotes around the last line of the script. The find locates all the files named ".htaccess" and ten the chmod makes them writable by Apache (and everyone else).
I guess this presumes that you have SSH login on the server.
Thanks Andy, chmoding fixed
Thanks Andy,
chmoding fixed the issue, although I got the following warning for some of the files:
"chmod: changing permissions of
sites/default/files/tmp/file1Y7qkS': Operation not permitted"sites/default/files/js/js_0d968414f8c2960ad47c5ddc10f08a91.js': Operatio t permitted"chmod: changing permissions of
"
Which are also the files I had problems with...
By the way isn't a+w equal to
By the way isn't a+w equal to 777, I though that this is a bad practice because anyone on the server has access to the files...
My code does indeed "chmod
My code does indeed "chmod a+w" giving write access to everyone. I figured someone would bring that up.
He doesn't have permission to chown. So presumably he doesn't have permission to change his group, to join whatever group the Apache/PHP user is in, so "chmod g+w" probably won't do the job.
Yes, anyone with a login account on the server, assuming that they can get down the directory tree that far, can trash the files. That's what backups are for. I suppose an ACL entry for Apache could do it. I don't know much about ACL, but he probably doesn't have authority to create ACL's either.
And remember that these are data and backup files, not PHP code files. So code injection is unlikely. Maybe in files he has a picture and somebody could plant a trojan in the image? IMHO if someone has a login on the server they won't go to these bends to get action; they'll hack known holes in the system software and get root priveleges, in which case everyone on the server is shafted. But that's just my guess.
And yes, I guess you'll get error messages about not being allowed to do "chmod" to files that were written by Apache/PHP. But since those are writable by PHP already you can ignore the error messages.
Darned "._" files
Since I helped on this one I'll pass on something else that just bit me.
If you zip in Linux and unzip in OS X you get extended attributes called "com.apple.quarantine". No big deal; we can ignore them, right? Well not quite.
It appears athat 'tar', on it's own, creates an extra file whenever it sees a file with an extended attribute. Given a file named pix/broccolli.jpg which was unzipped when I transported it up to OS X, when I tar the directory tree in OS X and un-tar in Linux, I get the file pix/broccoli.jpg bit I also get a file named "pix/._broccoli.jpg. The Linux 'file' command says that this is a "AppleDouble encoded Macintosh file".
The mess is that the file name ends in ".jpg" but it is not a JPEG, it something else entirely.
My fix was to run 'xattr -d' in my archive script to get rid of all quarantine extended attributes. I don't know how to get rid of all extended attributes of any kind, but com.apple.quarentine is the only extended attribute I've run into.
Linux <==> OS X is always an adventure.
When you untar can you not do
When you untar can you not do something like rm -r -f ._* to delete all attended attributes?
A simple test on two
A simple test on two directories, two files, v/w and w/w, shows that 'rm -r -f w' will get rid of directory w and file w/w but not touch directory v. It's recurdive only within the items selected. What we would need would be something like
rm -f
find . -name '._*'Yeah, that should do it. Perhaps better because it gets rid of ALL extended attributes, not just the com.apple.quarantine ones. IMHO it's a WTF of tar to store attribute information as files.
Warning: the Drupal Groups
Warning: the Drupal Groups posting tool is removing back quotes. The code read
rm -f {backquote}find . -name '._*'{backquote}
but those critical backquotes were deleted when I posted it.
Impressive conversations..
Impressive conversations.. lol. Thanks for the info. Keep it up guys :)
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
AndyCanfield thanks for
AndyCanfield thanks for posting your script!! stopped me tearing my hair out :) awesome thank you!
www.anahassel.com
www.smartsites4u.co.uk