SetUID permissions are not restored

Support
1

Fellow Duplicati users, I´m trying to restore a backup of a machine running a Ubuntu 20.04 Server OS and I´m using Duplicati version 2.0.5.1. I executed the restore command with the following options:

  • –restore-permissions=true
  • –restore-symlink-metadata=true
  • –overwrite=true

The operation finishes with a bunch of errors related to simlinks with non-existing targets, but none of the erros im getting are related to my actual problem! (I checked the file paths).

After booting the system and trying to execute any sudo command i get the following error message:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Upon checking the restored files i discovered that all of the files which had the “s” permission (before the restore) have a “x” permission instead. (after the restore)

Examples:
Before: -rwsr-xr-x 1 root root 67816 Apr 2 2020 su
After: -rwxr-xr-x 1 root root 67816 Jul 21 07:49 su

Before: -rwsr-xr-x 1 root root 68208 May 28 06:37 passwd
After: -rwxr-xr-x 1 root root 68208 May 28 06:37 passwd

Is Duplicati not able to restore said “s” permissions, or am I missing something ?

1 Like
2

@Dot I’ve got the very same issue. SetUID permissions are not set upon data restore.

This is what I found in log.

[Warning-Duplicati.Library.Main.Operation.RestoreHandler-MetadataWriteFailed]: Failed to apply metadata to file: “/bin/su”, message: Win32 IO returned 50. Path: /bin/su

Once this is fixed - so called bare metal backups may be possible without further steps (except fixing grub/disk UUID in fstab).

Thanks guys!

3

Welcome to the forum @martineliascz

Would one of you file an Issue, please? This forum is not an issue tracker, and I didn’t spot an open issue.

Regardless, I can’t reproduce the Win32 IO returned 50. A 50 looks like ERROR_NOT_SUPPORTED.
I wasn’t testing on my original /bin/su but on cp -p copy. I could restore back to 755, but not back to 4755.
I’m not sure if the restore side has an issue too, but the backup side make a metadata block that was like

{“unix:uid-gid-perm”:“0-0-493”,“unix:owner-name”:“root”,“unix:group-name”:“root”,“CoreAttributes”:“Normal”,“CoreLastWritetime”:“637364699750000000”,“CoreCreatetime”:“637364699750000000”}

and decimal 493 is octal 755.

That’s not what Duplicati is designed for. It’s aimed at ordinary files and folders, and maybe symbolic links. File systems can have exotic things that may not restore, such as devices, pipes, sockets, and hard links.

1 Like
4

@ts678 Thanks for the reply.

Would one of you file an Issue, please? This forum is not an issue tracker, and I didn’t spot an open issue.

Sure, once we confirm it should really work like this. OK?

Regardless, I can’t reproduce the Win32 IO returned 50. A 50 looks like ERROR_NOT_SUPPORTED.
I wasn’t testing on my original /bin/su but on cp -p copy. I could restore back to 755, but not back to 4755.
I’m not sure if the restore side has an issue too, but the backup side make a metadata block that was like

{“unix:uid-gid-perm”:“0-0-493”,“unix:owner-name”:“root”,“unix:group-name”:“root”,“CoreAttributes”:“Normal”,“CoreLastWritetime”:“637364699750000000”,“CoreCreatetime”:“637364699750000000”}

and decimal 493 is octal 755.

I guess the stored metadata should contain 2541 decimal (4755 octal), right?

That’s not what Duplicati is designed for. It’s aimed at ordinary files and folders, and maybe symbolic links. File systems can have exotic things that may not restore, such as devices, pipes, sockets, and hard links.

I have excluded the following virtual directories from Duplicati backup for such reason:

  • /dev
  • /lost+found
  • /media
  • /mnt
  • /proc
  • /run
  • /sys
  • /tmp

The above folders are recreated every time you reboot the system (thanks to tmpfiles.d and others) - please correct me if I am wrong.

Due to the fact that Duplicati does not restore setuid, setgid and sticky bit I had to recover my system using the following steps:

  1. Boot into Grml
  2. Restore everything except the above virtual directories
  3. Fix GRUB using boot-repair-disk (could also use chroot)

Now the additional part - which wouldn’t be required at all if Duplicati had restored all perms properly:

  • Install the very same OS on desktop (vm)

Desktop

  1. sudo find / -printf “chmod %m %p \n” > perms.txt
  2. (cat perms.txt | awk ‘$2>777’) > perms.sh

Server

  • sh perms.sh # from recovery mode

So this effectively helped me to recover the system and everything is working flawlessly once again…

…but it took me about an hour net time to get everything up and running.

Please let me know if you know about any solution which I could utilize to create remote bare metal backups more efficiently - possibly without having to turn off the servers and installing the OS somewhere else in order to get all those permissions.

I guess that system restore shouldn’t take more than 5-10 mins of human net time…

Thank you.

5

Of course you can file an issue later (or never), but a filed issue potentially gets developers involved.
If you were planning code-level research, I can suggest files and docs that you might start looking at.
If you are developers, pull requests are also most welcome, if you can track down the source of this.

That would be my guess. The way to see such lines is to flip through files in a dblock.zip of a backup.

At least some of these exotic files can be anywhere. It depends on where system and users put them.
Conventions exist, so you can probably get an approximate restore, but a for-sure-exact may be hard.

You can test this yourself. I have a suspicion that at least /lost+found (being persistent-file-oriented) is persistent. Others are persistent places to do things like mount things (by convention). A mount point persists even if what is mounted on it might come and go. You can try findmnt or df or mount to study.

Is turning off the servers OK at all? Backing up running applications is tricky, as they are likely holding memory-resident data. On Windows, some applications let VSS arrange flush, but Linux lacks VSS…

If you’re willing to be crash-consistent, your options broaden and can be helped with low-level abilities.
Some backup software (including Duplicati, if Linux is set up right to allow it) can use LVM snapshots. Snapshot capabilities are also available through through filesystems such as ZFS, if any are available.

How far is duplicati away from doing a “full” system drive image backup? is one of the few discussions relevant to your question that I could find. There are more on the Internet, and maybe you could search.

Questions for you to decide are your consistency needs (e.g. application-consistent, crash-consistent), and restore needs (lost system, lost individual files). There are some image backups, such as Macrium Reflect on Windows that combine an image backup with file-level abilities. I assume it reads its images.

If your applications cooperate, a crash-consistent image might suit your restore if your whole drive dies.
Individual data file restores could be Duplicati even currently, but still be careful of the consistency need.

1 Like