-
-
Notifications
You must be signed in to change notification settings - Fork 747
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
repo ownership/permissions #4082
Comments
i use rsync as root often, works for me. also, guess you can use |
Or just run |
Note those are both workarounds for functionality borg doesn't have... doing a full system backup and keeping a copy offsite requires a workaround. Doesn't that make the case that borg could really use a repo ownership feature? |
You should always use the same user when accessing a borg repo. Then you have zero permission issues. For non-ssh repos and running borg as root, but not having the repo owned by root, you can use the ssh://user@localhost/myrepo trick. rsyncing a repo works the same way, just use the same user always. or even better, don't rsync, but make 2 independent backups to different repos. |
I did it by passing See https://borgbackup.readthedocs.io/en/stable/usage/notes.html?highlight=umask From
To know more about umask modes, see this. |
Global options are only documented once, not for every command. |
When backing up a set of files that have different ownership/permissions, you naturally run borg as root. No problem with that, except the repo files are all created with 0600 permissions (and 0700 for /data). This makes it impossible to copy the repo as any other use but root.
The problem is this repo cannot be rsync'ed either: rsync sensibly) does not run as root. capabilities(7) won't help either: you'd have to apply them to either the Python interpreter for borg, or to the rsync binary -- compromising system security even more.
Am I missing something here? I don't see any options to force file/group ownership or permissions when running as root, and that's what is needed here.
To summarize: AFAICS there is no way to do a remote copy of a repo that backs up files with restricted permissions.
The text was updated successfully, but these errors were encountered: