Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

restore: folder permission are always 755, folder owner is the restore user #1108

Closed
AlphaJack opened this issue Mar 15, 2024 · 3 comments
Closed
Labels
C-question Category: Further information is requested

Comments

@AlphaJack
Copy link

AlphaJack commented Mar 15, 2024

Assume a source with one file, created by an unprivileged user. By running

mkdir ~/Desktop/Source
truncate --size 1M ~/Desktop/Source/file
rustic -P Profile init
rustic -P Profile backup
rustic -P Profile extract latest ~/Desktop/Restore
ls -la ~/Desktop/Restore

I noticed the following:

  • "~/Desktop/Restore/home/jack" has permission 0755, while the real "/home/jack" has 0700

If I launch init, backup and restore as root (on the same source created by the unprivileged user):

  • same as before
  • only "/Desktop/Restore/home/jack/Source" is owned by root (not "/Desktop/Restore/home" or "~/Desktop/Restore/home/jack"), while the real "Source" and is owned by the unprivileged user

If I run init and backup as unprivileged user, but restore as root:

  • everything except "file" is owned by root

If I run init and backup as root, but restore as unprivileged user, everything is fine (except the first 0755 issue)

If I delete "/home/jack/Desktop/Source" and restore the snapshot to "/" to have the original source back:

  • the permission of "/home/jack" changes from 0700 to 0755
  • the operation takes too much because every file not in the snapshot is logged:
19:33:16 [DEBUG] (1) rustic_core::commands::restore: additional "/home/jack/.local/share/Trash/file"

For the last issue, are we supposed to restore to a temporary directory, and then move the extracted files to their original location?

@AlphaJack AlphaJack changed the title restore: ofolder permission differ restore: folder permission are always 755, folder owner is the backup creator Mar 15, 2024
@AlphaJack AlphaJack changed the title restore: folder permission are always 755, folder owner is the backup creator restore: folder permission are always 755, folder owner is the restore user Mar 15, 2024
@aawsome
Copy link
Member

aawsome commented Mar 23, 2024

@AlphaJack Thanks for opening this issue!

About permissions and owners of dirs: Can you tell which backup sources you did use? (e.g. post that part of your config file). Note that rustic only saves the correct permissions and ownership for files within that path. For example, if you backup /home/user the trees home and user won't be saved within the snapshot with correct permissions. You can run rustic ls --long to see which permissions/ownership are saved within a snapshot.

In general, if you like to restore it is mostly advisable to select a suitable subtree of your snapshot which you like to restore. In the example above, using rustic restore latest:/home/user /home/user does prevent rustic from scanning dirs except subdirs of /home/user. Also, this could be a remedy for your permission issues...

@aawsome aawsome added the C-question Category: Further information is requested label Mar 23, 2024
@aawsome
Copy link
Member

aawsome commented Apr 18, 2024

@AlphaJack about permissions, I hope I explained that that this is intended behavior.

Is there anything open which prevent closing this issue?

@AlphaJack
Copy link
Author

Thank you, you were really clear! I updated my restore script to reflect this behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-question Category: Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants