Apache taking ownership of file and folder

Question

I have django site running on Ubuntu with apache2 configured with mod_wsgi. The media (folder where user uploaded files go) is owned by ubuntu user (with sudo access) and the group of media folder is www-data. When new folder or files are created by apache in media folder some external Python process (e.g. subprocess.popen) is not able to write in that folder as that particular folder is owned by www-data. What is the solution of this problem?

What I have done so far (django is the system user):

sudo chown django:django -R mysite/media/
sudo chgrp -R www-data mysite/media/
sudo chmod -R g+w mysite/media/

ls -la result of media folder (media folder contains some other folders named with integers):

drwxr-sr-x  2 www-data www-data 4096 Jun  8 02:20 11
drwxrwsr-x  6 django   www-data 4096 Jun  7 18:15 10
drwxrwsr-x  5 django   www-data 4096 Jun  7 18:13 9
drwxrwsr-x  5 django   www-data 4096 Jun  7 18:11 8

As you can see the newly created folder 11 is owned by www-data not by django user.

What else i have tried:

• i have tried to add user django to www-data group but nothing helps

Please help!

Update

Unfortunately Daniel solution also does not work for me (still getting IOError: [Errno 13] Permission denied). Here are result of command getfacl mysite/site_media/:

Before

# file: mysite/site_media/
# owner: django
# group: www-data
user::rwx
group::rwx
other::r-x

After (sudo setfacl -d -R -m g:www-data:rwx mysite/site_media/)

# file: mysite/site_media/
# owner: django
# group: www-data
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:www-data:rwx
default:mask::rwx
default:other::r-x

Answer 1

You can use file access control lists, in this case setfacl to set default file permission to allow write operation for the group. If you have added django to the www-data group, then with the following command, the django user will have write permission on any files owned by www-data user.

    setfacl -d -R -m g:www-data:rwx mysite/media/

Note: you will need to install the acl package using apt-get install acl if it is not installed. Make sure also ACL is enabled for your partition - this link might help.

Answer 2

The problem was of shared memory. This answer helped it to fix it.

Adding none /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 in /etc/fstab fixed it.

Answer 3

By looking at your directory output, at permissions of the directory 11 to be precise, I've found that apache created it with group readable but not group writable permissions. Since you might want all users in group www-data to have write permissions for these files/directories, you need to tell apache to create files/dirs with group write permissions that can be acomplished by setting umask option to WSGIDaemonProcess. Since documentation says:

Typically the inherited umask would be 0022

you'll always get no group writable permissions set. All you need in this case is just set umask value to 0002 and restart apache. You may solve this problem by just running WSGIDaemon as user django by specifying relevant user name.

Answer 4

I don;t fully understand your description of the problem, but think the problem is he setgid bit i.e. the 's' in:

drwxr-sr-x 

Have a look at: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories for a description written better than I can give it. The chmod man page too. Basically look for info in setgud. It behaves differently on directories than it does on files.

Try chmod g-s on the media dir and then create a sub dir in media and see if that has stopped it from inheriting the wrong perms. If it has you just need to remvoe the setgid bit from all the other sub dirs.

For that find is your friend (it can search on owners groups and perms)