Проблема с разрешениями Rsnapshot при удаленном резервном копировании Macbook

1416
Timmy O'Mahony

Я использую rsnapshot на своем домашнем сервере для создания резервных копий моего macbook через SSH. Все настроено и работает правильно, но у меня проблема с разрешениями.

Поскольку у меня есть разные пользователи на моем macbook и домашнем сервере, резервные копии файлов на моем домашнем сервере сохраняются следующим образом:

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

Я предполагаю, что 501 - это идентификатор, связанный с пользователем на моем MacBook Pro, и, поскольку этого пользователя нет на моем домашнем сервере, я просто вижу идентификатор пользователя. Я не уверен насчет группы дозвона.

Эти разрешения означают, что, когда я просматриваю свои резервные копии файлов по сетевой папке, у меня возникают проблемы с разрешениями.

Можно ли сохранить заархивированные файлы под моим пользователем и группой на моих домашних серверах вместо того, чтобы сохранять пользователя и группу в macbooks? Если так, есть ли какие-либо последствия для этого?

2

1 ответ на вопрос

2
ShadSterling

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.

Похоже, что rsnapshot можно настроить для передачи --usermap и --groupmap в rsync, используя опцию rsync_long_args в rsnapshot.conf; см. http://www.rsnapshot.org/rsnapshot.html ShadSterling 9 лет назад 0

Похожие вопросы