0

I backed up my entire home directory using rsync and moved the backup to a new installation of Linux. Somehow my file permissions got completely screwed up (all files were owned by user "999" and file permissions were set to 777).

I ran a quick sudo chown -R username:username ~/ which fixed some issues I was having with my audio, but now all my plain-text files (and even movies and music) are marked as executable, other users can view my files, etc.

How can I restore my file permissions to a "normal" state? Restoring from a backup isn't exactly possible, since the backup has screwed up permissions as well. I can always reinstall my OS and purge the config files from the backup, leaving me only with personal documents that I can then recursively set the permissions for, but what should I set the permissions to? A sudo chmod -R 660 ~/Music for example leaves me unable to listen to my music, even though I am the owner.

Improve this question
2
  • Do you still have the old files?
    – Satō Katsura
    Aug 31, 2017 at 10:14
  • You want directories to be readable, writable and executable by you
    – Basile Starynkevitch
    Aug 31, 2017 at 10:27

2 Answers 2

Reset to default
9

The following might help to clean up file and folder permissions quickly but will not fix anything that had different settings.

sudo chown -R <login>:<login> /home/<login>
find /home/<login> -type f -print0 | xargs -0 chmod 664
find /home/<login> -type d -print0 | xargs -0 chmod 775

<login> is of course your login. Change to 660 and 770 if you like.

There are a few special cases that require tighter permissions. This list is not complete by anyway but may help you get back up quickly.

Correction for Mail and ssh:

find /home/<login>/Mail -type d -print0 | xargs -0 chmod 700
find /home/<login>/.ssh -type d -print0 | xargs -0 chmod 700
find /home/<login>/Mail -type f -print0 | xargs -0 chmod 600
find /home/<login>/.ssh -type f -print0 | xargs -0 chmod 600

Note: Some files within ~/Mail may need 640 or 644. This will depend on your mail client.

Some other common files that would need the same permission as above are:

.gnome, .gnome2_private, .bash_history, .lesshst, .viminfo

Edit: Included .ssh info from Ulrich Schwarz's comment and expanded to include some more common directories and permissions. Also included the chown -R command that was already run by the OP for completeness.

Edit 2: As pointed out by saurabheights in the comments, you may need to run find /home/<login> -type d -print0 | xargs -0 chmod 775 a number of times until all the subdirectories are accessible.

Improve this answer
3
  • Note in particular that ssh will refuse to run if the private keys in ~/.ssh/ are group- or world-readable.
    – Ulrich Schwarz
    Aug 31, 2017 at 11:20
  • For large amounts of files or directories, xargs will not work and the -exec flag of the find command may have to be used instead: find /home/<login> -type d -exec chmod 775 {} \; find /home/<login> -type f -exec chmod 664 {} \; Also, note that the order there is to fix directory permissions first so the files within those directories can have their permissions fixed.
    – aoeu
    Mar 28, 2019 at 2:58
  • Minor thing: If directory is inaccessible, run find /home/<login> -type d -print0 | xargs -0 chmod 775 first and run it again and again till all subdirectories are fixed. Then run for files.
    – saurabheights
    Oct 16, 2019 at 22:17
1

In directory /etc/skel there is template of home directory. You can try to restore permissions to basic folders according to folders in /etc/skel.

In the future use rsync/cp/scp with -p switch to preserve permissions.

Improve this answer
1
  • To be more specific, I used grsync, and I always ticked the boxes for preserving owner, permissions, etc. I don't know how they got all screwed up.
    – ArdentCertes
    Aug 31, 2017 at 15:55

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.