Restic: Restoring with --include creates directories with wrong permissions on the way down.
Output of restic version
restic 0.7.3
compiled with go1.9 on linux/amd64
How did you run restic exactly?
See details below
What backend/server/service did you use?
Client: Debian Stable (9.2)
Server: FreeBSD 11.1 server in the LAN using OpenSSH (OpenSSH_7.2p2, OpenSSL 1.0.2k-freebsd 26 Jan 2017)
Expected behavior
The all directories should be created with the original permissions and ownership, even if you only restore files being deep in the hierarchy.
Actual behavior
When restoring files lying deep in the hierarchy the directories on the way down are restored with a different user and permission as they had on the original.
Steps to reproduce the behavior
mkdir testdir # create directory
touch testdir/testfile # create a file in it
chmod 755 testdir testdir/testfile # make shure the permissions are 755
su # switch to root
restic -r sftp:rakor@SERVER:/usr/home/rakor/resticbackuptest backup testdir # making the backup
restic -r sftp:rakor@SERVER:/usr/home/rakor/resticbackuptest restore latest -t testrestore -i testfile # restore the file (not the whole directory)
ls -lR testrestore # the file is restored with the correct owner and permissions. But the directories on the way down to the file are restored with the user 'root' and permissions 700.
testrestore/:
insgesamt 4
drwx------ 2 root root 4096 Okt 31 21:30 testdirtestrestore/testdir:
insgesamt 0
-rwxr-xr-x 1 rakor rakor 0 Okt 31 21:25 testfile
Do you have any idea what may have caused this?
I would think that directories on the way down are not "restored" but just "created" with "secure defaults".
Do you have an idea how to solve the issue?
restore the empty directories instead of just creating them.
rakor
All 5 comments
Thanks for raising this issue. I'm not sure that setting the previous access rights on intermediate directories in the right way forward, let me think about this for a bit.
Any other thoughts on the matter?
fd0
on 1 Nov 2017
To me, this definitely looks like a bug/problem in the restoration functionality. If I'm restoring data that originally belonged to some user into a directory that's accessible by this user, I expect this user to be able to access the restored data, even if only a part was restored. Restoring directory attributes (owner/access/etc) looks like a natural way to achieve this.
Also, the current behaviour is perceived as restic "half-restoring" these intermediate directories (their existence is restored, but their attributes aren't), which seems inconsistent/illogical.
pvgoran
on 2 Nov 2017
I think this is a bug. If I want to restore part of a backup, the restored copy should be usable. Currently it is unusable without performing restic ls operations to discover the proper permissions, owner and group of each path element that was autocreated. It really makes restores of files/directories difficult.
rouilj
on 20 Mar 2018
I agree that what is restored by restic should be restored in a consistent manner (that is, either with "default" permissions of the user running the restore, or with the permissions etc from the original files and folders that were backed up, not a combination of the two).
I can however see a use case in both types of permissions:
- Some users need/want to restore the data into a new context, and with that they want the ownerships and permissions to be "default", just as if they had created the same directories and files themselves anew.
- Some users need/want to restore the data into the same or equal context they were backed up in, and with that want the result to have the same ownership and/or permissions as the original files that were backed up.
- Some users want to keep just the permissions but not the ownerships (they can easily correct the ownerships themselves though).
I think the reasonable way forward is that one can control what ownership and/or permissions restic restores by some option(s) to the restore command.
rawtaz
on 20 Mar 2018
Can someone please confirm that it's still an issue? Since 0.7.3 was released, we've made a few changes to the permission (and timestamp) handling for intermediate directories...
fd0
on 20 Mar 2018
Related issues
dionorgua
·
5Comments
fd0
·
3Comments
stevesbrain
·
3Comments
McKael
·
4Comments
axllent
·
4Comments
Most helpful comment
To me, this definitely looks like a bug/problem in the restoration functionality. If I'm restoring data that originally belonged to some user into a directory that's accessible by this user, I expect this user to be able to access the restored data, even if only a part was restored. Restoring directory attributes (owner/access/etc) looks like a natural way to achieve this.
Also, the current behaviour is perceived as restic "half-restoring" these intermediate directories (their existence is restored, but their attributes aren't), which seems inconsistent/illogical.