I have a "backup" user on my server that needs to have read permissions everywhere. Doing chown 444 -R / backup doesn't seem like the right thing to do, so what should I do?


You're mixing two commands:

  • chown that is used to change the owner of a file. Exemple: chown root:adm /etc/passwd

  • chmod that is used to change the permission of a file. Exemple: chmod g+r myfile

Whatever your goal is, you really don't want to have your backup user to own every file and you certainly don't want to have every users on your system the right to read every files of your system.

What is your goal?

  • 1
    Exactly! I don't want the backup user to own every file, nor do I want every user to have read access everywhere. For some reason the others couldn't understand that. I understand the difference between chown and chmod. I just want the backup user to somehow be able to read every file so it can do its job. – Jason Swett Oct 7 '10 at 13:12
  • 1
    Some files must not be readable by any other users than their owner (ssh private key for exemple). If you want to backup your system, you can either read the raw disk (but may have to restore the whole disk to get only 1 file) or do your backup as root. – Benoit Oct 7 '10 at 13:23
  • 3
    If some files must not be readable by anyone other than their owners, how is backing up as root better than creating a user who has read permissions everywhere? Backing up as root seems to be a violation of the principle of least privilege, since the backup user doesn't need to write or execute anything, just read. – Jason Swett Oct 7 '10 at 13:33
  • SSH for exemple doesn't work if you change the permission on the key files. That's why you must backup the keys as root (or their owner). – Benoit Oct 7 '10 at 14:04

Under Linux, if you use an ACL capable filesystem (ext3, ReiserFS, ZFS will do I think), then you can set read and directory traversal right to your backup operator user.

Let's say you want to backup /home

  1. Your partition should be mounted with the "acl" option (you can do that with mount -o remount,acl /home )
  2. Install acl tools (setfacl and getfacl)
  3. setfacl -R -m u:"Backup User":rx /home

If you want to ensure that new files and directories will have proper rights too, the set the default ACL :

  1. setfacl -R -m d:u:"Backup User":rx /home

You can obviously do that with a finer grain (for instance if you don't want to backup gnupg or ssh keys, - which should be protected by a password anyway)

Performing a backup as root is not wise, IMHO. First if you inadvertently run out of disk space, you can consume up to the last available block, and render your system unstable. Second, if you are not completely sure of the script or command you use for backup, a malicious user could make your backup go recursive, or do nasty things as root.

I personally use a rsync mechanism for syncing a server on a replica. I use simple group rights on most of the sync points, except for the home where I use ACLs

  • 3
    It's probably best to use rX permissions instead of rx in the setfacl command line as the latter will set x on all files, even those that aren't executable. – bgamari Sep 10 '14 at 21:20

The right way to do this is not by changing your file permissions. You should use sudo and/or setuid executables.

  • All the operations performed by my backup user are pre-canned, so I don't have the option of using sudo. – Jason Swett Oct 7 '10 at 13:30
  • What is your backup software? – Coops Sep 8 '11 at 10:11
  • @Coops: You need to use "@" to address the user you're trying to communicate with if they're not the owner of the answer (or question) your comment is attached to. For example: "@Jason" – Dennis Williamson Sep 8 '11 at 17:44

chmod g+r myfile

g represents the group of the file (administrators).

r represents the read permission.

  • represents the fact that the permission is added.

chmod 0444 /file. for simplicity, use this: http://permissions-calculator.org/


The simple answer is to run the backup as root. In fact, short of doing very onerous and/or dangerous things, that is the only answer as far as I can tell.

If you were to you can't set backup as the owner of everthing, nor can you set it as the group for everthing, so the only other way to give it access is to give everyone access. Simply put, you run backups are root or make a mess of your system.

It is totally normal to back up as root.



One somewhat non-intrusive way to do this is to add your backup user to every group on the system.

This user belonging to every group would inherit the rights of those groups, so any file that is group readable you can back up. This would include the root group if you want to back up files owned by root.

That would not necessarily enable you to back up every file, but it will allow you to back up every file that users do not set as private. Files that are X00 will not be backed up.

One of the downsides to this approach is that you must keep pace with new groups as they are created. Also it requires, if you want to backup home directories, that you set at least execute permissions on /home (for group).

As someone else mentioned this might break ssh with keys depending on your implementation.


--privs will be short for permissions (or privileges)--

who cares what "they" say "should" / "shouldn't" not all of us are running NSA level PC sanctuaries, and some of us (like dude in OP) might benefit from a little come-all-read-all policy:

One of my colleagues has a linux box that has everything read (Besides root folder and lost+found folder) so that any user (such as myself can find neat stuff in his /home/notme folder or in /etc/ folder)

sudo chmod -R +r /
sudo chmod -R 700 /root
sudo chmod -R 700 /lost+found

NOTE: the /root folder is probably owned by root:root (root user and root group) yet we told root group no privs... Well thats okay because root user still has priv so thats what matters most if your root right? Basically if your root user, and you try to get in to a folder/file that says root user you have full privs, but root group you have no privs... who wins? Well root user privs say you can get in so thats what matters (the root group privs don't even get looked at).. Also since your root user you can change all that up

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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