Восстановление разрешений из Time Machine - копия Finder против копии "cp"

Question

Примечание: этот вопрос начал разрастаться, поэтому я переписал его.

У меня есть папка, которую я пытаюсь восстановить из резервной копии Time Machine. Использование cp -R работает нормально, но некоторые папки не могут быть восстановлены ни с помощью Time Machine, ни с помощью Finder.

Другие пользователи сообщили об аналогичных ошибках, и был предложен обходной путь cp -R (например, Восстановление с Time Machine - Ошибка прав доступа). Но я хотел понять:

1. Почему cp -R работает, когда Finder и пользовательский интерфейс Time Machine не работают.
2. Могу ли я предотвратить ошибки, изменив права доступа к файлам перед резервным копированием.

Кажется, действительно есть некоторые разрешения, с которыми работает Finder, а некоторые - нет. Я сузил ошибки до папок с пользователем ben (это я) и групповым wheel .

Вот упрощенное воспроизведение. У меня есть четыре папки с комбинациями владелец / группа, которые я видел до сих пор:

ben ~/Desktop/test $ ls -lea
total 16
drwxr-xr-x   7 ben   staff   238 27 Nov 14:31 .
drwx------+ 17 ben   staff   578 27 Nov 14:29 ..
 0: group:everyone deny delete
-rw-r--r--@  1 ben   staff  6148 27 Nov 14:31 .DS_Store
drwxr-xr-x   3 ben   staff   102 27 Nov 14:30 ben-staff
drwxr-xr-x   3 ben   wheel   102 27 Nov 14:30 ben-wheel
drwxr-xr-x   3 root  admin   102 27 Nov 14:31 root-admin
drwxr-xr-x   3 root  wheel   102 27 Nov 14:31 root-wheel

Каждый содержит один файл с именем file с тем же владельцем / группой:

ben ~/Desktop/test $ cd ben-staff
ben ~/Desktop/test/ben-staff $ ls -lea
total 0
drwxr-xr-x  3 ben  staff  102 27 Nov 14:30 .
drwxr-xr-x  7 ben  staff  238 27 Nov 14:31 ..
-rw-r--r--  1 ben  staff    0 27 Nov 14:30 file

В резервной копии они выглядят так:

ben /Volumes/Deimos/Backups.backupdb/Ben’s MacBook Air/Latest/Macintosh HD/Users/ben/Desktop/test $ ls -leA
total 16
-rw-r--r--@ 1 ben   staff  6148 27 Nov 14:34 .DS_Store
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben   staff   102 27 Nov 14:51 ben-staff
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben   wheel   102 27 Nov 14:51 ben-wheel
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root  admin   102 27 Nov 14:52 root-admin
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root  wheel   102 27 Nov 14:52 root-wheel
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

Из них ben-staff можно восстановить с помощью Finder без ошибок. root-wheel и root-admin запрашивают мой пароль и затем восстанавливают без ошибок. Но ben-wheel не запрашивает мой пароль и выдает ошибку:

The operation can’t be completed because you don’t have permission to access “file”.

Интересно, что я могу восстановить file из этой папки, перетаскивая его непосредственно на мой локальный диск (вместо перетаскивания его родительской папки), но когда я делаю это, его разрешения изменяются на ben/staff .

Вот разрешения после восстановления для трех папок, которые работали правильно, и файл из ben-wheel который был изменен на ben/staff .

ben ~/Desktop/test-restore $ ls -leA
total 16
-rw-r--r--@ 1 ben   staff  6148 27 Nov 14:46 .DS_Store
drwxr-xr-x  3 ben   staff   102 27 Nov 14:30 ben-staff
-rw-r--r--  1 ben   staff     0 27 Nov 14:30 file
drwxr-xr-x  3 root  admin   102 27 Nov 14:31 root-admin
drwxr-xr-x  3 root  wheel   102 27 Nov 14:31 root-wheel

Кто-нибудь может объяснить это поведение? Почему Finder и пользовательский интерфейс Time Machine ломаются с разрешениями ben / wheel ? И почему cp -R работает (даже без sudo)?

Answer 1

Помимо обычных прав доступа к файлам UNIX (пользователь / группа / каждый, у каждого из которых есть свои права на чтение / запись / выполнение), Mac OS X также использует списки контроля доступа (ACL), которые позволяют гораздо более детальные настройки разрешений для файлов / папок.

Time Machine добавляет (добавляет) следующий ACL ко всем файлам:

группа: все отрицают add_file, delete, add_subdirectory, delete_child, writeattr, writeextattr, chown

(Приведенный выше ACL зависит от папки, но сопоставляется с обычными файлами, например: add_file = write, add_subdirectory = append, delete_child = <none>)

Это означает, что все файлы / папки в резервной копии Time Machine заблокированы для всех (даже для пользователя root).

Если вы восстановите свои файлы вручную из резервной копии Time Machine (то есть, если вы не используете Migration Assistant), то все ваши файлы будут содержать эти противные ACL Time Machine, связанные с ними.

Удалить списки управления доступом Time Machine довольно просто. У вас есть три варианта:

1) Размахните топором и полностью удалите ACL из ваших файлов / папок (в этом нет ничего плохого, но не очень осторожная стратегия)

2) Удалите первую запись из ACL ваших файлов / папок (более осторожно, но не идеальное решение)

3) Удалите определенные ограничения из списков ACL ваших файлов / папок (вероятно, это лучший вариант, если вы хотите сохранить списки ACL, не связанные с Time Machine)

Для всех трех вариантов вам нужен Терминал, который вы найдете в /Applications /Utilities

Вариант 1: Вот как вы качаете топор:

Если вы знаете, что у вас есть только ваши личные файлы в папке "Мои восстановленные файлы" на вашем рабочем столе, и вы знаете, что эти файлы не имеют / не нуждаются в каких-либо причудливых списках ACL, вы можете ввести следующее в окне терминала:

chmod -R -N ~/ Рабочий стол / Мои \ Восстановленные \ Файлы

(если вы не знаете способ указания файла / папки с помощью терминала, просто перетащите нужный файл / папку в окно терминала, и терминал наберет для вас правильное имя файла / папки)

Вариант 2. Вот как вы удаляете первую запись ACL

Тот же пример, что и выше. На вашем рабочем столе есть папка "Мои восстановленные файлы". Но в этом случае у вас есть несколько файлов с настраиваемыми ACL, которые вы хотите сохранить. Введите следующее в окне терминала:

chmod -R -a # 0 ~/ Рабочий стол / Мои \ Восстановленные \ Файлы

Что делает вышеуказанное решение "опасным", так это то, что оно не идемпотентно. Идемпотентная операция - это операция, которая может применяться снова и снова без изменения результата после однократного применения. Вроде как умножение числа на 1. Вы можете продолжать делать это, но результат всегда одинаков.

Почему это имеет значение? Что ж, скажем, у вас есть файл, который уже имел ACL до того, как Time Machine добавила собственную запись ACL. Если вы запустите вышеупомянутую команду дважды, вы удалите как ACL Time Machine, так и ACL, который вы, вероятно, не хотели потерять.

Плюс вышеупомянутое решение также не идеально для файлов Time Machine, которые смешиваются с другими файлами. Если какой-либо из этих других файлов (не Time Machine) имеет ACL, то приведенная выше команда удалит эти ACL.

Вариант 3. Вот как вы удалите определенные ограничения из ACL

Помимо возможности указать, какую запись номера ACL вы хотите удалить, вы также можете указать конкретные ограничения, которые вы хотите удалить. Так что вы можете сделать это:

chmod -R -a "группа: все отрицают add_file, delete, add_subdirectory, delete_child, writeattr, writeextattr, chown" ~

(«~» означает "мой домашний каталог", т.е. если ваше имя пользователя - bob, то «~» = «/Users/bob»)

Приведенная выше команда является идемпотентной, что означает, что вы можете запускать ее снова и снова без вреда для здоровья. На самом деле, любой может запустить его в любое время. Если в вашем домашнем каталоге нет файлов / папок, заблокированных Time Machine, ничего не произойдет.

ХОРОШО. Я надеюсь, что это было полезно для некоторых людей. У меня вчера была та же проблема с разрешениями Time Machine, поэтому я решил поделиться тем, что узнал.

Answer 2

Проблема в том, что Finder реализует специальную обработку файлов, восстановленных из Time Machine, чтобы сохранить все их разрешения, что не удалось для файлов, принадлежащих учетной записи текущего пользователя, но не для группы, членом которой он является.

---

Обычно при копировании файлов с использованием cp их атрибуты не сохраняются. Это можно изменить с помощью параметра -p .

-p Заставить cp сохранить следующие атрибуты каждого исходного файла в копии: время изменения, время доступа, флаги файла, режим файла, идентификатор пользователя и идентификатор группы в соответствии с разрешениями. Списки контроля доступа (ACL) и расширенные атрибуты (EAs), включая ветки ресурсов, также будут сохранены.

В обоих случаях вы либо копируете все или ничего, либо эти метаданные. cp достаточно умен, чтобы восстанавливать их только после того, как все содержащиеся в нем файлы были обработаны ([ источник, смотрите рядом, If -p is in effect, set all the attributes).

Если у вас нет прав root, право владения не сохраняется. Причина этого в том, что только root может создавать файлы, принадлежащие пользователям, а не ему, и группам, членами которых он не является.

---

Чтобы сделать резервные копии Time Machine видимыми, но в остальном неизменяемыми в Finder, они защищены списками контроля доступа, в которых всем пользователям запрещены все модификации.

0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

Так как другие атрибуты (другие ACL, расширенные атрибуты, даты файлов и разрешения) должны быть сохранены при восстановлении из резервной копии, в Finder требуется специальная обработка этих папок. Он должен удалить конкретную запись ACL, но сохранить все остальное.

Кроме того, Apple, очевидно, хочет, чтобы Finder сохранил всю информацию о владельце при копировании файлов и каталогов из резервной копии. Это включает в себя членство в группе.

---

Если ваша учетная запись не является владельцем указанных каталогов, Finder запрашивает пароль администратора и передает его своей вспомогательной программе с повышенными привилегиями Locum. Это не происходит, когда вы являетесь владельцем файла в наборе резервных копий.

Теперь происходит один из следующих случаев:

• Вы не являетесь владельцем файла: Finder запрашивает ваш пароль, Locum восстанавливает все разрешения, как в резервной копии.
• Вы являетесь владельцем и членом группы файла: Finder копирует файл и восстанавливает группу.
• Вы являетесь владельцем, но не членом группы файла: Finder копирует файл и не может восстановить его группу.

Это похоже на попытку chown username:groupname файла, и выводит ошибку, если она терпит неудачу - что он делает, если вы не root (sudo), ни username и не член groupname .

Он ведет себя немного иначе, если вы копируете не папки, а файлы: при сохранении права собственности на файл членство в группе отменяется, если вы не являетесь участником группы. Это то, что вы видели, когда копировали только один файл.

---

Очевидные решения этой проблемы:

• Предотвращение владения файлами, приводящего к сбою восстановления (т. Е. Принадлежащего вам и группе, членом которой вы не являетесь - в большинстве случаев это все равно бесполезно)
• Сделайте себя членом этой группы хотя бы временно. К сожалению, я не смог сделать это, используя dscl из командной строки таким образом, чтобы это работало без выхода из системы или перезапуска. Другой побочный эффект заключается в том, что с wheel вас могут возникнуть проблемы с разрешениями в зависимости от конфигурации вашей системы.

Answer 3

На самом деле, вы должны использовать tmutil для восстановления файлов из резервных копий Time Machine. Таким образом, вам не придется удалять расширенные атрибуты и т.д.

Со справочной страницы Mac OS X:

tmutil restore [-v] src ... dst

Восстановите элемент src, который находится внутри моментального снимка, в папку dst. Аргумент dst имитирует семантику пути назначения инструмента cp. Вы можете предоставить несколько исходных путей для восстановления. Последний аргумент пути должен быть пунктом назначения.

При использовании глагола восстановления tmutil ведет себя в основном как Finder. Пользовательские метаданные Time Machine (расширенная безопасность и другие) будут удалены из восстановленных данных, а другие метаданные будут сохранены.

Привилегии root строго не требуются для восстановления, но tmutil не выполняет предварительную проверку разрешений, чтобы определить вашу способность восстановить src или его потомков. Следовательно, в зависимости от того, что вы восстанавливаете, вам могут потребоваться права root для выполнения восстановления, и вы должны знать об этом заранее. Это то же поведение, с которым вы столкнетесь с другими инструментами копирования, такими как cp или ditto. При восстановлении с использованием tmutil в качестве пользователя root владение восстановленными элементами будет соответствовать состоянию элементов в резервной копии.

В общем, вы можете использовать его как команду cp, не беспокоясь о внутреннем отдыхе.

В большинстве случаев вы хотите восстановить с помощью sudo, когда вы не знаете, являетесь ли вы владельцем файлов или у вас есть права на запись в целевой каталог.