Have you ever messed up the system’s ownership and/or permissions accidentally? Or maybe you used an application who did that for you? Whichever it was, if that ever happened to you, you’ll be very familiar with what do unstable and unusable system mean. As well as, it could cause in a serious security’s issues.

My Story:

Well,.. I did. ..Ops!!
I was doing just fine with rsync (wiki) for a semi-live mirroring, and CrashPlan (wiki) for the incremental snapshots. Until I thought it wasn’t enough and I should not really rely on one backup tool. And from there the nightmare began, I mean the story. Although I do have a point there, but my mistake was experimenting on a live production system. Which is really really a bad idea.!

Three days ago, I was experimenting a bunch of backup’s tools and applications. Unfortunately, one of those applications was Back In Time (wiki) it messed up my life for a whole two days. Anyway, when I installed it, I found there were two versions of it. The Back In Time and Back In Time (root). And since I wanted to backup the /boot, /etc, /home, /lost+found, /opt, /root, /srv, /usr and /var. I needed to be root in order to read those directories contents to back them up. That’s why I used Back In Time (root).

Then, I prepared the remote location on my backup server. And decided to enable the EncFS (wiki) encryption feature that was available in Back In Time application with SSH since the destination is a remote location. And everything was just okay.. At least that’s how I felt back then, specially when the snapshot was being taken successfully.

The next day:

I was able to see the /root contents. I mean my normal daily used user was able to read and write to /root, /boot, /usr …etc. WTH! I said! When I checked their permissions I found that they were really a mess. Some of them were even being owned by my user instead of the right owner.!

I ran to the older snapshots I have, that were taken by CrashPlan, and compared the permissions. Guess what? Yeah you’re right they were indeed different. Then I realized that, there must be a real nasty bug in the Back In Time. Fortunately, I was lucky enough to discover this issue before it was kinda too late.

My first attempt:

I tried to restore the permissions and ownership via msec tool which is a nice feature of Mageia Control Center (aka: Drakconf) in Mageia Linux. But that didn’t solve all the problem. So I’ve tried the terminal way: $ msecperms -e. That didn’t work either.

Why? Well, the msec is meant to watch some pre-defined particular directories and files permissions and ownership, then restore them if it needs to. Not all of the system’s directories and files.

My second successful attempt:

Okay, because I couldn’t find any already made tool for this job. I thought I should give it a try first. Besides, it should be really easy specially if I have a backup that holds the correct ownership and permissions of each file and directory.

Enough chit-chat, let’s do Linux:

There two things that should be restored. First is the owner of that file or directory. And to which group does it belong to. Second is the Octal permissions it has.

Restoring the ownership:

First, go inside the backup directory you would like to restore the contents ownership from. Let’s assume it’s /mnt/backups/etc.

$ cd /mnt/backups/etc

Then use find to list everything inside it:

$ find . ! -type l -exec chown -v --reference='{}' /etc/'{}' \; | grep -v retained

What we did up there, is listing everything except symbolic-links, then we copied the ownership of it to the same file lives in our used system in the directory /etc.

  • The ! -type l is to list everything that is not sym-link.
  • The -exec is to execute the passed command.
  • The chown is the command we need to call. Which is the one that let us to change the ownership of a file or directory.
  • The -v is to make chown verbose.
  • The --reference= is to tell chown that we need to use the same ownership of the passed file.
  • The '{}' is the result of the find command. We put it in quotation marks to protect it if it has any spaces or special-characters.
  • The /etc/'{}' is the location of the file we want to apply the ownership to.
  • The \; is to separate each result with a newline. So, instead of calling chown once for all the results, we call it for each result. This is a good practice if you exceed the maximum allowed passed arguments.
  • The | is to redirect the output to another command.
  • The grep -v retained is to list only the affected files, instead of printing everything. By excluding any output has the word “retained“.

Then just repeat the process to all directories you need to restore their content’s ownership. Like: /boot, /usr, /var …etc.

Restoring the Octal permissions:

We can use the previous script to restore the permissions by replacing the chown with chmod. But that won’t be enough. Since it won’t restore the special-permission. Instead it will only restore the permissions of User, Group and Other. So, we need to find another way.

Again, Let’s assume our backup directory is /mnt/backups/etc. But first we need to prepare and generate a bash script. So, let us create the script in the directory we need to restore the octal-permissions to NOT from. Since we are in /mnt/backups/etc, it means we should create the file inside /etc:

$ echo -e '#!/bin/bash\n\n' > '/etc/restoreOctal.sh'

Now, that we created that file, let’s go inside the /mnt/backups/etc:

$ cd /mnt/backups/etc

Now, let’s generate the rest of the script by listing all the files and directories octal-permissions and store them to /etc/restoreOctal.sh:

$ find . ! -type l -exec stat -c "chmod %a -v \"%n\" | grep -v retained" "{}" \; >> '/etc/restoreOctal.sh'

What we did up there was: Search all the contents inside the current directory we’re in. And list everything that is not a symbolic-link. Then pass each result to the command stat then store the output of that command into /etc/restoreOctal.sh.

  • The stat is the command we want to apply on every output of the find results.
  • The -c is the argument to specify the FORMAT that we want to print instead of the default behavior.
  • The chmod is the command we want to use later when we call the restoreOctal.sh.
  • The %a is the shortcut of the octal-notation (Octal permission) of the processed file by stat.
  • The %n is the shortcut of the processed file by stat.
  • The >> is to redirect the output to a file appending the redirected output at the end.
  • The /etc/restoreOctal.sh is the file we want to store the outputs in.

Then, go to /etc:

$ cd /etc

Now, let’s make it executable:

$ chmod u+x restoreOctal.sh

Before executing it, let’s take a quick look into its contents just in case there is something wrong with it:

$ vim restoreOctal.sh

If everything looks ok, it’s time to restore those Octal-permissions:

$ ./restoreOctal.sh

Congratulations! You’ve just successfully restored the ownership and octal-permissions to the all contents of your /etc. Don’t forget to remove the restoreOctal.sh.

$ rm -f restoreOctal.sh

Then just repeat this process to any directory you’d like to restore its contents octal-permissions.

Finally, Happy Linux-ing 😉

By DeaDSouL

A big fan of UNIX & Linux.. Who adores programming..

2 thoughts on “Restore ownership and octal permissions from a backup”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.