2

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

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

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

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

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

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

1 ответ1

2

Похоже, это то, что происходит:

  • rsnapshot копирует числовые uid и gid с вашего Mac на ваш сервер
  • UID для вашей учетной записи Mac и учетной записи сервера разные
  • разрешения на скопированные файлы не позволяют вашему серверу uid получать к ним доступ

Есть несколько возможных решений этого.

Решение 1. Используйте rsync --usermap и --groupmap

rsnapshot использует rsync для выполнения большей части работы, а в последних версиях rsync есть опция отображения uids и gids. Я не знаю, можно ли настроить rsnapshot для передачи этих параметров rsync, но если это так, это решит вашу проблему.

Решение 2. Синхронизируйте ваши идентификаторы пользователей и групп.

Если ваша рабочая станция и сервер работают под управлением одной и той же ОС, это, вероятно, возможно, но, возможно, не стоит переходить на них, если они уже настроены по-разному. Если они работают в разных ОС, они, вероятно, имеют несовместимые схемы распределения uid, хотя возможно, что вы сможете синхронизировать только uid для своего пользователя. (Если только один из них не Windows, тогда это вообще невозможно). Изменение идентификаторов учетных записей не приведет к изменению идентификатора владельца для каких-либо файлов, поэтому вам придется сделать это как отдельный шаг. Изменение пользовательского идентификатора не должно быть большой проблемой, но изменение пользовательского идентификатора сервиса может привести к путанице.

Решение 3: Разделите шаг копирования

Если вы скопируете все на сервер как отдельный шаг перед запуском rsnapshot, вы можете сделать копию с помощью программы, которая будет использовать имена строк, а не числовые идентификаторы. Это переведет UID для любых подходящих имен пользователей. Unison, единственный двунаправленный инструмент синхронизации файлов, о котором я знаю, сделает это; он включен (но не установлен по умолчанию) в большинство дистрибутивов Linux и доступен для Macos через MacPorts или в комплекте приложений. Если вы копируете файлы, используя scp (включенный и установленный по умолчанию почти во всем, кроме Windows), владельцем будет пользователь, вошедший в систему-получатель.

Решение 3. Добавьте шаг перевода uid/gid

Вы можете изменить uid/gid после завершения rsnapshot. Если вы заботитесь только об одном или двух идентификаторах, вы можете адаптировать решение из этого ответа:

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

Это исправит ваш uid/gid, но нарушит жесткую ссылку rsnapshots на неизмененные файлы - rsnapshot не будет жестко связывать файлы, которые отличаются каким-либо образом, включая изменения в метаданных. Он не будет жестко связывать файлы с разными владельцами или даже файлы с разными временными метками. (Это rsync-поведение, которое rsnapshot использует, но не изменяет.)

Конечно, вы можете добавить еще один шаг, чтобы восстановить жесткую ссылку.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .