Community & Support

file permissions: problems moving to new host

I just got a VPS account.
I zipped/downloaded my original drupal install, and uploaded/unpacked it on the new server.
After transferring the DB, it all seemed to work ok.

However, I'm having a hard time with the 'file system' setting.
On going to admin -> site config -> file system, drupal said 'sites/default/files' is unwritable.
It works ok if I chmod /files to 777, but obviously this isn't desirable.

The first thing I tried was to rename /files to /files_bak
Drupal then recreated a new writable /files directory with an htaccess file inside.
But when I tried to move all the files from files_bak into the new directory, I got permission errors.
Similarly, if I try to edit the /files or files/.htaccess (including chmodding them), I also get permission errors:

FileOp Failure on: /home/USER/public_html/sites/default/files: Operation not permitted

Advice on how to proceed?

I think it is connected with the 'owner' and/or 'group' permissions.
Or the fact that the files were created on another server and then moved.
But I have no idea about any of that stuff - the most I've ever had to do before is simple chmod.

And it's freaking me out that I can't edit the newly-created /files directory; surely I'm the owner of that?

Thanks.

Comments

where u get your VPS? an

where u get your VPS?

an experienced hosting company should not give you such trouble.

if u have the root account (linux super user), u may change the owner / group of all the files under /sites/all/defaults/files. Otherwise, call the hosting support.

could u tell us the name of your hosting company?

We go the drupal way. How about you?
http://www.drupalway.com

The apache user (usually

The apache user (usually 'apache' or 'nobody' or 'www-data') needs to be able to write in the files and tmp directories.

If you have installed php as an Apache module, the files and tmp directories need to be:
- either owned by your user account and have permissions 777.
- or owned by the apache user and have permissions 755. You could chown the directories and all the files they contain, if you want.

If you have installed php as cgi, you could install suphp to let php write files using your own user account, in which case you could own everything and set all permissions to 755 (for directories) or 644 (for files).

1) > It works ok if I chmod

1)
> It works ok if I chmod /files to 777, but obviously this isn't desirable.

OK, the first issue is that I just assumed that they'd configured the server with phpsuexec enabled.
This is not the case; but they'll do it for me if I ask, or I could have a go at doing myself in WHM (easy apache).
I need to determine whether or not I really need phpsuexec enabled on a VPS. At the moment I think I do.
Any opinions welcome.

2)
> And it's freaking me out that I can't edit the newly-created /files directory; surely I'm the owner of that?

The second issue pertains to what cog.rusty was saying about permissions.
After uploading/unzipping drupal, using the SSH command: LS -L I can see that the 'user' and 'group' permission for all files and directories are the user name for the account eg. USER USER. However, if I coerce drupal to create an .htaccess in the /files directory, the permission for it is: nobody nobody. As I am logged in as USER, I cannot edit/delete/chmod this file. If this is going to happen every time drupal creates a file on the server, either from a user upload, or imgcache thumbnail, attachment, etc, then this is a serious problem.

What needs to be changed so that Drupal creates directories and files with permission USER USER?
Perhaps phpsuexec will solve this problem as well as the 777 security problem?

EDIT Ah... in WHM the Apache suEXEC handler was set to 'DSO' rather than 'CGI'.
I think changing that should make any directories or files created by drupal have the USER USER permission?

> could u tell us the name of your hosting company?

eukhost.com

I don't think this is their fault. They're very cheap, but their support has been absolutely excellent so far.
Asking for phpsuexec was probably something I should have specifically requested when ordering the account.

Thanks for any further input.

Everything I say is opinion, even if interpreted as fact.
Sometimes I may be inaccurate or *GASP* wrong!
Sometimes I attack Drupal due to frustration. Get over it.

Yeah, sorry... I forgot to

Yeah, sorry... I forgot to post back.
Earlier today a tech support from eukhost installed SuPHP for me.
It seems to have solved both the problems.

From what I've read, WHM/cpanel used to support a heavily customised version of phpSuExec,
but more recently have moved toward supporting SuPHP. I think SuPHP was included as an
option with my WHM apache installation, whereas if I specifically wanted phpSuExec, I think
the tech would have had to download it.

> EDIT Ah... in WHM the Apache suEXEC handler was set to 'DSO' rather than 'CGI'.
> I think changing that should make any directories or files created by drupal have the USER USER permission?

For for information sake, my above suggestion was wrong. That setting only affects cgi scripts.
However, after SuPHP is installed, then 'suphp' should be selected here instead of DSO.

Cheers.

Everything I say is opinion, even if interpreted as fact.
Sometimes I may be inaccurate or *GASP* wrong!
Sometimes I attack Drupal due to frustration. Get over it.