apache permissions: fileOp error

[-Anti-]

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

However, I'm having a hard time with the drupal 'file system' setting.
On going to admin -> site config -> file system, drupal said 'sites/default/files' is unwritable.
It works ok if I chmod the /files directory 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 fileOp permission errors.
Similarly, if I try to edit the new /files or files/.htaccess (including chmodding them), I also get permission errors like this:

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

I think it is connected with the apache 'owner' and/or 'group' permissions. Perhaps related 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 that was made by Drupal; surely I'm the owner of *that*?

According to someone on the drupal forum this shouldn't be happening, and is caused by the VPS set-up.
Any information about what's going on or advice on how to proceed?

Thanks.

[eukSam]

Hello,

It may be a ownership problem with the files. Please open a support ticket on our helpdesk with the drupal site details so we can assist you in a better way.



Regards,
Sam

[-Anti-]

I tried the: chown -R user.user file/folder with the help of chat-support.
However, it didn't work as desired because.....

I saw 'suexec' mentioned in WHM and assumed that meant phpSueExec was enabled.
Actually I thought all accounts these days ran phpSuexec as a default safety measure.
But after some reading, it isn't as widely used as I thought; apparently it takes up a
lot of memory and some scripts don't work properly with it.

So I *think* all that was wrong was that Drupal was trying to write to a folder chmoded to 755.
Quite rightly I got the 'not writable' error.

Ronan suggested in chat support that as long as the php scripts are written properly,
chmod 777 should be safe enough. Tempting advice, since I won't have the disadvantages
of using phpSueExec. But are Drupal and Moodle written safely enough?

Any contrasting or supporting advice, before I simply use chmod 777 for my file uploads folder?

Thanks.

[jennifer]

I will recommend you to submit a ticket to the VPS Department. Since they are aware of the complete configuration of the VPS Server they'll be able to rectify this for you.

[Rock]

I saw 'suexec' mentioned in WHM and assumed that meant phpSueExec was enabled. Actually I thought all accounts these days ran phpSuexec as a default safety measure.

phpSuexec isnt enabled/enforced by default, it needs to be done manually.

But after some reading, it isn't as widely used as I thought; apparently it takes up a lot of memory and some scripts don't work properly with it.

We've this security measure/setting enabled on almost 95% of our Linux shared hosting servers & we've never come across any such memory issues arising from phpSuexec..

But are Drupal and Moodle written safely enough?

The stable versions of Drupal and Moodle both, are rigorously tested prior to release, hence using them would be recommended.. as they are less keen to have security loopholes within them..

Any contrasting or supporting advice, before I simply use chmod 777 for my file uploads folder?

I'd suggest going phpSuexec, if you're to host such applications which require world-writable permissions on certain directories..

[-Anti-]

Thanks for your replies. Before I approach tech support with a ticket, I'd like some more info about the following issue if possible:

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

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?

Thanks.

[Scott]

Hi,

Yep. Php-suexec will solve this problem. By default apache uses nobody user for creating files and folder. After enabling php-suexec on your vps, apache will use respective user of hosting account for creating files. So new files created by drupal will have ownership USER:USER.

[-Anti-]

Thanks for that confirmation.

OK, I'll submit a ticket.
Thanks very much.