Has anyone got a nice solution for handling files in /var/www? We're running Name Based Virtual Hosts and the Apache 2 user is www-data.

We've got two regular users & root. So when messing with files in /var/www, rather than having to...

chown -R www-data:www-data

...all the time, what's a good way of handling this?

Supplementary question: How hardcore do you then go on permissions?

This one has always been a problem in collaborative development environments.


4 Answers 4


Attempting to expand on @Zoredache's answer, as I give this a go myself:

  • Create a new group (www-pub) and add the users to that group

    groupadd www-pub

    usermod -a -G www-pub usera ## must use -a to append to existing groups

    usermod -a -G www-pub userb

    groups usera ## display groups for user

  • Change the ownership of everything under /var/www to root:www-pub

    chown -R root:www-pub /var/www ## -R for recursive

  • Change the permissions of all the folders to 2775

    chmod 2775 /var/www ## 2=set group id, 7=rwx for owner (root), 7=rwx for group (www-pub), 5=rx for world (including apache www-data user)

    Set group ID (SETGID) bit (2) causes the group (www-pub) to be copied to all new files/folders created in that folder. Other options are SETUID (4) to copy the user id, and STICKY (1) which I think lets only the owner delete files.

    There's a -R recursive option, but that won't discriminate between files and folders, so you have to use find, like so:

    find /var/www -type d -exec chmod 2775 {} +

  • Change all the files to 0664

    find /var/www -type f -exec chmod 0664 {} +

  • Change the umask for your users to 0002

    The umask controls the default file creation permissions, 0002 means files will have 664 and directories 775. Setting this (by editing the umask line at the bottom of /etc/profile in my case) means files created by one user will be writable by other users in the www-group without needing to chmod them.

Test all this by creating a file and directory and verifying the owner, group and permissions with ls -l.

Note: You'll need to logout/in for changes to your groups to take effect!

  • 10
    @Tom Great to see that you recommend using the findcommand for this. One small performance tip I would give if you have lots of files/directories and you are using GNU find is to use + instead of \; so that the command will operate on multiple files because "it is faster to run a command on as many files as possible at a time, rather than once per file. Doing this saves on the time it takes to start up the command each time." Also, it is easier to type since it doesn't need backslash.
    – aculich
    Feb 18, 2012 at 7:46
  • 2
    Updated with @aculich's suggestion to use + not \;
    – Tom
    Jun 4, 2012 at 23:43
  • 1
    @SunnyJ. try this (without the outer quotes): "find /var/www -type f -exec chmod 0664 '{}' \+" Try that. There is a space between the '{}' and the \+. Jun 28, 2012 at 6:00
  • 1
    why we need to give permission for others to see and execute. Nov 8, 2012 at 13:45
  • 1
    @Tom- way to break it down, thanks. Just a note- I think "SETUID (4) to copy the user id" as included in your answer is wrong- SETUID is ignored when applied to directories in Linux/Unix - Ref
    – Yarin
    Dec 3, 2012 at 22:00

I am not entirely sure how you want to configure the permissions, but this may give you a starting point. There probably are better ways. I am assuming you want both users to be able to change anything under /var/www/

  • Create a new group (www-pub) and add the users to that group.
  • Change the ownership of everything under /var/www to root:www-pub.
  • Change the permissions of all the folders to 2775
  • Change all the files to 0664.
  • Change the umask for your users to 0002

This means any new file created by either of your users should be username:www-pub 0664 and any directory that gets created will be username:www-pub 2775. Apache will get read access to everything via the 'other users' component. The SETGID bit on the directories will force all files being created to be owned by the group that owns the folder. Adjusting the umask is needed to make sure that write bit is set so that anyone in the group will be able to edit the files.

As for how hardcore I go on permissions. It completely depends on the site/server. If there is only 1-2 editors and I just need to keep them from breaking things too badly then I will go easy. If the business required something more complex then I would set up something more complex.

  • 1
    Possible addition - set cache/upload dirs that need to be written to by the webserver to www-data:www-data and 775.
    – gacrux
    May 11, 2009 at 12:45
  • Would it work as well to add the users to the apache group instead of relying on 'other' permissions? If all you are doing is uploading files and those files need to be readable by apache a 3rd group only seems to be useful if you need to edit those files.
    – Simurr
    May 11, 2009 at 18:49
  • 1
    Any chance you can expand this a little @Zoredache? I grok the basic use of rwx bits, chmod, chown, adduser, usermod, but you've lost me with the extra first digit on the octal permissions, umasks and all that. Some sample commands illustrating your outlined approache would be greatly appreciated.
    – Tom
    Sep 15, 2009 at 3:24
  • 1
    This way every user can access every other user files ! This means userA can read config.php of userB ... stoling its mysql credential, for example
    – drAlberT
    May 9, 2011 at 12:02
  • 1
    Using acl you can handle both security and collaborative-ness :)
    – drAlberT
    May 10, 2011 at 14:19

I think you may find POSIX ACL (access control lists) to be helpful. They allow a finer-grained permission model compared to the user:group:other model. I have found them to be easier to keep straight in my head since I can be more explicit and can also set the "default" behavior for a branch of the file system.

For example, you can specify each user's permissions explicitly:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Or you can do it based on some shared group:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

And perhaps you want to keep your Apache user as read-only

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Man pages:


  • 2
    That's the way ! +1
    – drAlberT
    May 9, 2011 at 16:53
  • ACL for the win +1... For more see serverfault.com/a/360120/41823
    – Yarin
    Dec 17, 2012 at 0:14
  • 1
    I wonder if there's any performance downside for ACL vs basic permissions. Jan 9, 2013 at 9:15
  • 2
    Unfortunately, ACL is too often missing on standard installations/distributions. It's a pain to compile kernel on every servers i manage, or worse, change filesystem sometimes. Plus you must be very careful when backuping files up, especially if you are switching servers. ACL is great but its current support is so low that i would recommend against it for anyone who doesn't have full control on everything on the server and surroundings. But +1 for pointing ACL out where it really makes sense!
    – Ninj
    Feb 13, 2015 at 8:48
  • Good answer +1 ; A note about changing the apache process read/write permissions (www-data for instance) to read-only for whole site (via setfacl or chmod - or both) -> This will obviously block all writes (plugin/module uploading/updating from browser side on most CMS for example). I believe many popular ones also only test for write access on user perm level not the group level. You can still update, but updates must be applied manually and any custom permissions for write folders (logs/temp/uploads/etc). Read-only is great security if your site works with it.. by and large most don't.
    – B. Shea
    Aug 28, 2016 at 15:28

This question was asked again, and as discussed on meta, current best practices provides better approaches than there was available in 2009, when this was asked. This answer tries to give some current solutions for handling collaborative web development environments securely.

For a secure web server & collaborative development there's more than just the file permissions:

  • Have separate user for every site i.e. don't serve all sites using www-data. This is important, as nowadays Apache is seldom serving solely static content files, but running dynamic web sites. This answer concentrates on PHP as it's the most common server-site language, but the same principles applies to the others, too.

    If you have a security problem on a single site, it can spread to every site that is running as the same user. An attacker can see everything the user sees, including database login information, and modify every site the user has write permissions to.

  • Use SSH File Transfer Protocol (SFTP). While using FTP should be abandoned for security (as it sends both the passwords and the content in plain text), it's secure substitute SFTP also has a feature that is a perfect solution for collaborative web development.

    Once you have isolated the sites and one user per site, you need to give access to your web developers, what this question is all about. Rather than giving them the passwords for these site users – or access to the site files using their personal user accounts as originally suggested – you can use SSH keys for login.

    Every developer can generate keypair and keep the private key secret. Then, the public key is added to the ~/.ssh/authorized_keys file for every website user account the developer is working on. This has many advantages for managing the passwords and logins:

    • Every developer can have access to any number of web sites without the burden to remember or store all the passwords involved with the user-per-site arrangement.

    • No need to change & share the passwords every time someone leaves the company.

    • You can use very strong passwords or disable password based login altogether.

  • Use PHP-FPM. It's the current approach for running PHP as the user. Create a new pool for every user i.e. one pool per every site. This is the best for both security and performance, as you can also specify how much resources a single site can consume.

    See e.g. NeverEndingSecurity's Run php-fpm with separate user/uid and group on linux. There are tutorials like HowtoForge's Using PHP-FPM with Apache on Ubuntu 16.04 that doesn't use PHP-FPM for increasing security through user separation, guiding to use a single FPM socket across the server.

  • Would it be possible to expand on what the steps are to "Have separate user for every site" I am just learning basic server admin stuff I am not experienced. So going from say a default install of apache / nginx with php-fpm where the /var/www/ folder is created what steps should be followed to properly add the user, change file ownership (to the user?), and make sure apache / nginx / php-fpm can still read/execute those files? I am unclear on what group the new user should be a part of and what adjustments need to be made to the apache / nginx / php-fpm user/group settings. May 8, 2021 at 4:35
  • That would be a tutorial; that would be too lengthy for a Q/A site, and also not answering to the original question. The "Use PHP-FPM" section already has links to such tutorials. May 8, 2021 at 5:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .