Backing up using root privileges

Before i stumbled upon restic, i used to manage my nextcloud instance backups with rsync, and handling ACL files seperately, for correct permissions backup as rsync somehow didnt do the job. It used to work.

Now since restic has the ACL handling baked in, i was very excited to try this out.

So i did a backup using sudo on my raspberrypi.
sudo restic_0.11.0_linux_arm -r restic_test_backup/ --verbose backup nextcloud/
It worked, tested out a restore, and all the permission attributes were intact! Great.

Now i tried to use the same repo with a different linux m/c to backup my documents:
restic_0.11.0_linux_amd64 -r sftp:pi@ --verbose snapshots

This resulted in following errors:
enter password for repository:
repository 8b3d4cc9 opened successfully, password is correct
Load(<snapshot/ba9ab0bf3b>, 0, 0) returned error, retrying after 552.330144ms: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)
Load(<snapshot/ba9ab0bf3b>, 0, 0) returned error, retrying after 1.080381816s: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)
Load(<snapshot/ba9ab0bf3b>, 0, 0) returned error, retrying after 1.31013006s: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)
Load(<snapshot/ba9ab0bf3b>, 0, 0) returned error, retrying after 1.582392691s: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)
Load(<snapshot/ba9ab0bf3b>, 0, 0) returned error, retrying after 2.340488664s: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)

This could be because, the original repo had some of the index files created with the root user on my source repo.

But to my surprise , even if i issue the sftp command using sudo, i was not able to list the snapshots:
**sudo** restic_0.11.0_linux_amd64 -r sftp:pi@ --verbose snapshots

i get the same SSH_FX_PERMISSION_DENIED errors.

Am i missing something? Cant i use my original repo, that unfortunately had backups done by root privileges from some other remote machine through sftp?



The pi@ in the above command specifies that you will be accessing the remote repository as the user pi. Running this with sudo on the local machine grants superuser privileges on the local machine, but it does not change that you have specified to access the repository as user pi.

Some of your options here include:

  • use sftp:root@ which will access the remote repository as root. This will likely require you to perform several other steps, including configuring sshd to permit root access, creation of an ssh keypair for the root user, and distribution of the public half of that key to the remote machine to enable key authentication for the root user.
  • change the ownership of the repository from root to pi: chown -R pi.pi /home/pi/restic_test_backup

No doubt there are other options too.

this worked. I guess it would not interfere with the permission attributes of the actual backup data, it just changes the ownership of the repo files, right?

And if i use rclone for putting the repo to a cloud of choice, this step of chown should be prior to initiating a rclone sync/copy operation? or it doesent matter, and rclone sync can handle the changed ownership sometime in the future incremental sync?

Also, you pointed out of other options for this, may i know what are those?

Thanks for your help.

Edit: Sorry, i was wrong… i just tried with a restore, and due to chown, all my backup that were earlier restored with proper file permission attributes, are no longer proper. Every restored file is owned by pi:pi
,which is not what i need, and the restored data wont be usable for a working nextcloud restored instance.

Secondly, on pi, there is no root user, so first option doesent work out.
So looking for some other alternatives…


restic is able to directly interact with rclone. There’s no need to manually mess with file permissions/ownership there. Actually the only thing about the file ownership for the backup repository that matters is that restic is able to read the data.

The chown does not modify the repository data itself. If you run restic restore as the pi user then it can only create files owned by pi (normal users are not allowed to create files for other users for security reasons). Only the root user is allowed to change the file owner. sudo -H restic restore should fix that though. Assuming that pi refers to a standard raspberrypi setup, it does have a root user. There’s just no password to directly log in as that user. Just use sudo to switch to the root user.

As MichaelEischer already mentioned, the pi:pi ownership is not because of the chown. Performing a chown on the repository will not alter the data or permissions of files that you restore from that repository.

The pi:pi ownership of your restored files is likely because you performed the restore operation using the pi user instead of the root user. You can correct that by sudoing the restore command.

Secondly, on pi, there is no root user, so first option doesent work out.

As MichaelEischer also mentioned, the pi does have a root user. By default, it is not enabled for login. You can always sudo bash do access the shell as root.

If you want to sftp to the box as root, you will need to create an ssh keypair on the client machine, include the public half of of that keypair in the pi’s /root/.ssh/authorized_keys and modify /etc/ssh/sshd_config on the server to permit key-based root access to your pi.

pi@raspberrypi:~ $ whoami
pi@raspberrypi:~ $ sudo bash
root@raspberrypi:/home/pi# whoami

There is also sudo -s, which besides being shorter also pays attention to the shell you’ve configured.

Yes, you are correct, sudo restoring the backup works with all permissions.

But i am clueless about how would i format this command with sudo bash, so that it gets executed as sudo on raspberrypi from another linux machine.

restic_0.11.0_linux_amd64 -r sftp:pi@ --verbose snapshots


There’s no question of formatting. sudo bash is a full command, which gives you access to a shell that’s running as the superuser. (sudo -s does that, too.) There is (almost) no difference between executing the command from that shell and just prefacing the command with sudo.

The permissions on the repository do not matter for the restore operation. Only the local permissions do.

You didnt get my question i think.
the sftp:pi@ repo was backed up on a raspberry pi using root permission due to files in the backup had to be read using root permissions.
Once that is done the sudo restic_0.11.0_linux_amd64 -r sftp:pi@ --verbose snapshots command[on a different linux m/c] fails with:

[sudo] password for ashish:
pi@’s password:
enter password for repository:
repository 8b3d4cc9 opened successfully, password is correct
Load(<snapshot/6b0fda9d8f>, 0, 0) returned error, retrying after 552.330144ms: sftp: “Permission denied” (SSH_FX_PERMISSION_DENIED)

executing that command using sudo doesent help here.
What i need is to somehow a way so that the above command operates using sudo on the raspberry m/c


You are right; I didn’t read the command out.

This is now identical to the initial problem you asked about, which I thought had already been resolved by changing the permissions on the repository - the chown -R pi:pi business.

The sftp protocol connects to a different computer, and the bit before the @ tells it which user to connect as. sudo is a local command, and is irrelevant to permission issues on the server side. The alternative is to tell sftp to connect as root, which is broadly frowned upon for security reasons.

Ok, so i was browsing the restic docs, and found this link

Following that, i no longer need to backup using sudo on raspberrypi, so, the resitc repo is accessible with normal user, and that solves the problem of accessing the repo from some other machine.
So i guess this is the best way.

But strangely, when i restore on raspberrypi the nextcloud backup, i only get files with pi:pi ownership and not with proper ACL atributes on files with different ownerships like root or www_data etc…
Why doesent the modified restic binary which now has proper rights to backup root accessible files, restore the backup with proper ACL attributes ?

So for restoring the nextcloud backup, i still need to issue the restore command with sudo
Or Is that intended to work this way only?


The user pi does not have the ability to change ownership of the files being restored. That is a completely unrelated matter to the use (or not) of sudo when making the backup. The ability to read a file does not imply the ability to change owners or write to those files - being able to make that distinction is precisely why capabilities are useful. Running the restore would require additional capabilities to be set - presumably at least CAP_CHOWN, but I don’t know the details.

Perhaps even better is sudo -i, which additionally does all the stuff that happens during login, such as running root’s profile and shell rc scripts. (With sudo -s you might be missing stuff in $PATH.)

Put another way:

  • sudo -s is like su.
  • sudo -i is like su -.
1 Like

True. There is a further subtlety, though, which probably won’t impact most people:

  • sudo -s runs the shell defined for the invoking user
  • sudo -i runs the shell defined for the target user

True, though the latter is what I would usually expect anyway. I find that sudo -i has the least number of surprises.