3

I am using rsnapshot on my home server to take backups of my macbook over SSH. Everything is configured and working correctly but I have an issue with the permissions.

Because I have different users on my macbook and home server, the backed-up files on my home server are being saved like so:

-rw-------  16  501 dialout  1650 Jun 24 21:09 .bash_history
...

I imagine that 501 is the id associated with the user on my macbook pro and as that user doesn't exist on my home server I am simply seeing the user id. I'm not sure about the dialout group.

These permissions mean that when I go to browse my backed up files over my network share, I get permission issues.

Is it possible to save the backed up files under my home servers user and group instead of persisting my macbooks user and group? If so, are there any repercussions to this?

1 Answer 1

2
+50

It sounds like this is what's happening:

  • rsnapshot is copying numeric uid and gid from your mac to your server
  • the uids for your mac account and server account are different
  • the permissions on the copied files don't allow your server uid to access them

There are a few possible solutions to this.

Solution 1: Use rsync's --usermap and --groupmap

rsnapshot uses rsync to do most of the work, and recent versions of rsync have the option of mapping uids and gids. I don't know if rsnapshot can be configured to pass those options to rsync, but if it can that would solve your problem.

Solution 2: Synchronize your user and group ids.

If your workstation and server run the same OS this is probably possible, but might not be worth changing to if they're already configured differently. If they're running different OSs they likely have incompatible uid allocation schemes, although it's possible you could synchronize only the uids for your user. (Unless one of them is Windows, then it's not possible at all.) Changing the account uids will not change the owner ids on any files, so you'll have to do that as a separate step. Changing the uid of a user shouldn't be a big deal, but changing the uid of a service can be a mess.

Solution 3: Separate the copy step

If you copy everything to the server as a separate step before running rsnapshot, you can make the copy with a program that will use string names rather than numeric uids. This will translate uids for any matching usernames. Unison, the only bidirectional file synchronization tool I know of, will do this; it's included (but not installed by default) in most linux distributions, and available for macos via MacPorts or as an App bundle. If you copy files using scp (included and installed by default in almost everything but Windows), the owner will be the user logged in to the receiving system.

Solution 3: Add a uid/gid translation step

You can change the uid/gid after rsnapshot has finished. If you only care about one or two uids, you can adapt the solution from this answer:

find /your/rsynced/path -user 1000 -exec chown 505 {} \;
find /your/rsynced/path -user 1001 -exec chown 700 {} \;

This will fix your uid/gid, but will break rsnapshots hardlinking of unchanged files - rsnapshot will not hardlink files that differ in any way, including changes to metadata. It won't hardlink files with different owners, or even files with different timestamps. (This is an rsync behavior that rsnapshot makes use of but does not modify.)

Of course, you could add another step to redo the hardlinking.

1
  • It looks like rsnapshot can be configured to pass --usermap and --groupmap to rsync, using the rsync_long_args option in rsnapshot.conf; see rsnapshot.org/rsnapshot.html Nov 17, 2014 at 16:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .