Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This is a simple question, I'm sure, but I can't seem to find any reason why I can't get this to work.

I'm trying to set up group folders within the web root for a PHP server. Each department should have a group like this:

/srv/www/htdocs/dev/dept1
/srv/www/htdocs/dev/dept2

All users in group dept1 should have read/write access to the dept1 folder, all users in dept2 should have read/write access to the dept2 folder, etc. In trying to implement this, I created a group like so:

sudo groupadd dept1
sudo useradd -G dept1 -m user1
cd /srv/www/htdocs/dev
mkdir dept1
sudo chown -R wwwrun:dept1 dept1
sudo chmod -R g+rwxs dept1

wwwrun is the user that Apache is running as. The idea is for users to be able to create/read/update/delete whatever they want within their department folder. However, upon trying it out, the user account can view the contents of the folder and read files, but not create or write files.

What am I doing wrong?

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

With the permissions you give, users in the dept1 group can create and delete files in /srv/www/htdocs/dev/dept1. However, under typical configurations, the files and subdirectories they will create will not be group-writable.

You can arrange for most files to be group-writable by changing everyone's umask setting. The umask setting determines what permission are not given to new files. It is usually set to 022, meaning that files will not be group-writable or other-writable unless explicitly made so. You can change this to 002 so that files are group-writable by default. However, this is only reasonable if every user has its own private group (otherwise, people's files would be writable by everyone in their primary group).

A better solution is to make sure access control lists are enabled on the filesystem where /srv/www/htdocs/dev resides (make sure that the fstab entry contains acl in the fourth column). Then create an ACL on srv/www/htdocs/dev/dept1 giving the dept1 group write permission on the directory, and making that permission grant inherited by newly created entries in the directory. This is similar to a umask change, but it's tied to this particular location in the filesystem. After you run the following two commands, permissions will be correct in all typical use cases.

setfacl -R -m group:dept1:rwx /srv/www/htdocs/dev/dept1
setfacl -R -d -m group:dept1:rwx /srv/www/htdocs/dev/dept1
share|improve this answer
    
Nice explanation. I'm quit curious about ACL now! –  invert Nov 3 '10 at 9:25
    
The users in "dept1" couldn't write to the directory. However, the ACL did the trick. Thanks! –  Brad Nov 3 '10 at 14:06
add comment

How are your users accessing the files? How are they trying to update/create them? I'm assuming that they are logging into the server, have them run the 'groups' command to ensure that they are actually in the correct group and it should be listed first.

share|improve this answer
    
The users are going to access the system via SFTP. It wasn't the first group, but I tried deleting the user and re-adding with the command sudo useradd -g dept1 -m user1 and got the same result (the user cannot create or write files). –  Brad Nov 2 '10 at 19:45
    
With respect to the other answer, you can chmod o+x on the directories. The people will be able to cd to the directories but not be able to read the contents unless they know the filenames. I'm confused as to why they should be able to read the files already though if they can't cd to the directory. –  dmah Nov 2 '10 at 21:05
    
Also check your syslog or /var/log/messages for any debugging information. –  dmah Nov 2 '10 at 21:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.