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.

Peter Mortensen
  • 2,318
  • 5
  • 23
  • 24
  • 8,573
  • 13
  • 44
  • 44
  • Also see: [What are the best linux permissions to use for my website?](http://serverfault.com/questions/357108/what-are-the-best-linux-permissions-to-use-for-my-website) – Zoredache Sep 01 '13 at 20:38

4 Answers4


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!

  • 2,652
  • 1
  • 20
  • 12
  • In your first find command you have 27*55* and not 27*75*. I got stuck, heh. – The Pixel Developer Sep 17 '10 at 01:46
  • 9
    @Tom Great to see that you recommend using the `find`command 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](http://www.gnu.org/software/findutils/manual/html_node/find_html/Multiple-Files.html#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 '12 at 07:46
  • Current as of 2012-05-25 This is still the best way to do it. Marking as correct answer even though @Zoredache had the original solution but this is more verbose. – Gareth May 25 '12 at 13:25
  • 2
    Updated with @aculich's suggestion to use + not \; – Tom Jun 04 '12 at 23:43
  • Tom, when I type find /var/www -type d -exec chmod 2775 {} + I get the error: find: missing argument to `-exec' – sunnyrjuneja Jun 06 '12 at 17:47
  • @SunnyJ. What OS? I've tested that in bash on Ubuntu and cygwin... Maybe try going back to \; instead of + and see if that helps you. – Tom Jun 07 '12 at 23:16
  • Actually, when I type: find /var/www -type f -exec chmod 0664 {} \; I get: chmod: cannot access `': No such file or directory repeated over and over again. My OS is Ubuntu 12.04. – sunnyrjuneja Jun 08 '12 at 01:22
  • 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 \+. – Buttle Butkus Jun 28 '12 at 06:00
  • 1
    why we need to give permission for others to see and execute. – Kevin Parker Nov 08 '12 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](http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories) – Yarin Dec 03 '12 at 22:00
  • Also, for permissions, think you can use ACL instead of umask: `setfacl -R -d -m g:www-pub:rw /var/www`- See http://serverfault.com/a/65416/41823 – Yarin Dec 18 '12 at 19:56
  • the accepted anwer works great when dealing with local text-editors (nano running on localhost), but remote editors working via sshfs mounts (ubuntu, mac) seem to do stuff like change the permissions of files upon save -- or, on mac, saving/creating is not "permitted" at all – lnostdal Jun 11 '11 at 00:37
  • On debian lenny, in addition to Tom's post, i had to modify /root/.bashrc umask also to 0002, or www-data won't have a proper umask by just editing umask in /etc/profile . – Trif Jun 02 '10 at 13:08
  • 1
    Instead of "2775" you may want to use "g+ws" so you just add "write" and "sticky" to the group permission and leave the rest. Likewise, replace "0664" with "g+w". Otherwise, if you have files that should be executable, you'll lose that setting on them. Or if you have files that shouldn't be "other" readable they'll become readable, etc... – Tim Tisdall Jan 20 '15 at 15:44
  • Why not have this agnostic group called `www` instead of `www-pub`? The `-pub` is confusing to me, because it makes it seem like it is only for the `public/` dir in a project. Also, `www` is more concise, and shorter is cooler. – Gavin Dec 17 '15 at 21:22
  • 1
    Ok, so by `usera` and `userb` do you mean `www-data` and `ftpuser` ? I found this very confusing with any mention of `www-data`, which was in the original question. Also, what is the point/benefit of setting the owner to `root`? Should we set it to `ftpuser`? – gskema Jan 31 '16 at 10:08
  • 1
    So I followed these instructions, but newly created files are showed to be owned by the user I'm signed in with, and now WordPress can't modify plugs\files – dangel Apr 05 '16 at 01:32
  • the purpose of this was to have any new files be owned by your user, but automatically be part of the group so other users can view/edit them. – Tom Apr 06 '16 at 02:50
  • Setting the owner to www-data:www-data works but isn't ideal. However, by setting the owner to root:www-pub, Wordpress is unable to update. Both my local user and www-data are part of the www-pub group. What part am I missing? – Etienne Charland Apr 13 '17 at 17:50

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.

  • 453
  • 6
  • 15
  • 130,897
  • 41
  • 276
  • 420
  • 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 '09 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 '09 at 18:49
  • @Ursid, to keep things secure I generally I try to avoid giving the web server process the ability to write files in places it doesn't need to. I grant users the ability to write via the group permissions, if the same group was used by the web server, then any misbehaving script/cgi could trash anything under /var/www. – Zoredache May 11 '09 at 19:54
  • 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 '09 at 03:24
  • @Zoredache: please feel free to incorporate my answer into yours to expand it if you want. – Tom Sep 15 '09 at 05:12
  • 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 09 '11 at 12:02
  • @AlberT, Yes, that is true, I am assuming that isn't really much of an issue. It would take more then tweaking permissions to 2770/0660 to fix that. If you just modified permissions, and the server ran PHP or something, then one user could easily write a program to read the files of another user. You will not the question mentions **collaborative development environments**, which led me to assume he wants users to be able to see each others content. – Zoredache May 09 '11 at 15:48
  • 1
    Using acl you can handle both security and collaborative-ness :) – drAlberT May 10 '11 at 14:19
  • How would handlers like PHP-FPM fit into this model? You'd have to run PHP-FPM as a user in the group `www-pub`? (Because it would need executable permissions, no?) – Andrew Cheong Apr 28 '14 at 03:14
  • @Zoredache if we weren't in a collaborative development env. we wouldn't want grant "the world" read right on web application source files: We would set file/dir owner to www-data, grant read+execute rights and block others/world? (`chmod -R ug=rx,o= /var/www`)? – CDuv May 21 '14 at 10:09

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:


Joe Holloway
  • 1,909
  • 3
  • 19
  • 17
  • 2
    That's **the way** ! +1 – drAlberT May 09 '11 at 16:53
  • ACL for the win +1... For more see http://serverfault.com/a/360120/41823 – Yarin Dec 17 '12 at 00:14
  • 1
    I wonder if there's any performance downside for ACL vs basic permissions. – Buttle Butkus Jan 09 '13 at 09: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 '15 at 08: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 '16 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.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • 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. – Kevin Chavez May 08 '21 at 04: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. – Esa Jokinen May 08 '21 at 05:31