restic: lchown operation not permitted
Output of restic version
restic 0.8.1 (v0.8.1-134-g2debb5c0)
compiled with go1.9.3 on linux/amd64
How did you run restic exactly?
rm -rf /foo/bar
mkdir -p /foo/bar
chown restic /foo/bar
sudo -u restic /usr/local/bin/restic restore latest \
-r "sftp:backup:bar" \
-p /home/restic/.restic-password \
--target="/foo/bar/../" \
--cache-dir=/home/restic/.cache/restic
What backend/server/service did you use to store the repository?
sftp
Expected behavior
Run without errors and return 0.
Actual behavior
All permissions seem to be accurate after the restore, but restic tries to lchown the directories and files and somehow fails with that:
ignoring error for /bar/a: Lchown: lchown /foo/bar/a: operation not permitted
ignoring error for /bar/b: Lchown: lchown /foo/bar/b: operation not permitted
ignoring error for /bar/c: Lchown: lchown /foo/bar/c: operation not permitted
ignoring error for /bar/d: Lchown: lchown /foo/bar/d: operation not permitted
Steps to reproduce the behavior
Restore a backup that contains files that are owned by a different user than the one used to restore the files.
Do you have any idea what may have caused this?
Do you have an idea how to solve the issue?
I’m not sure if I am missing something here, but maybe don’t call lchown on all files and directories? Isn’t lchown only for symlinks?
Did restic help you or made you happy in any way?
Very 😃
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 18 (10 by maintainers)
Commits related to this issue
- restore: suppress lchown errors when not running as root Like "cp -a" and "rsync -a" do, only report lchown errors if we run as root. Like cp from GNU coreutils does, we check Geteuid() to determine... — committed to rfjakob/restic by rfjakob 6 years ago
- restore: suppress lchown errors when not running as root Like "cp -a" and "rsync -a" do, only report lchown errors if we run as root. Like cp from GNU coreutils does, we check Geteuid() to determine... — committed to rfjakob/restic by rfjakob 6 years ago
- restore: suppress lchown errors when not running as root Like "cp -a" and "rsync -a" do, only report lchown errors if we run as root. Like cp from GNU coreutils does, we check Geteuid() to determine... — committed to rfjakob/restic by rfjakob 6 years ago
- restore: suppress lchown errors when not running as root Like "cp -a" and "rsync -a" do, only report lchown errors if we run as root. Like cp from GNU coreutils does, we check Geteuid() to determine... — committed to rfjakob/restic by rfjakob 6 years ago
These messages should be suppressed automatically when not running as root. I will implement this in september.
As “rsync -a” and “cp -a” does exactly the same thing, I think it is actually expected for restic to do the same.
As for the unneccessary syscalls, my guess is that it has neglegible performance impact, but if you have a test that proves otherwise, I’d gladly be wrong.
When you are restoring files, it will often not be to the original environment, which is quite possibly now dead and gone. The file permissions (especially groups and users) in the back-up may make no sense in the new environment. As such it is a pretty common restore option in backup software to restore file without trying to apply the original permissions. If you are restoring as root there is no easy way to avoid this sometimes unwanted behavior, and option to disable it would be welcome.
I misunderstood that you want restic to call “sudo chown”.