Autorisations de restauration à partir de Time Machine – Copie du Finder par rapport à la copie "cp"

Le problème ici est que Finder implémente une gestion spéciale des fichiers restaurés à partir de Time Machine pour conserver toutes leurs autorisations, qui ont échoué pour les fichiers appartenant au compte de l'utilisateur actuel, mais pas un groupe auquel il est membre.

Habituellement, lors de la copie de fichiers utilisant cp , leurs attributs ne sont pas conservés. Cela peut être modifié à l'aide de l'option -p .

-p Cause cp pour conserver les attributs suivants de chaque fichier source dans la copie: temps de modification, temps d'accès, drapeaux de fichiers, mode de fichier, ID utilisateur et ID de groupe, comme le permettent les autorisations. Les listes de contrôle d'accès (ACL) et les attributs étendus (EA), y compris les fourchettes de ressources, seront également conservés.

Dans les deux cas, vous copiez tout ou rien ou ces métadonnées. cp est assez intelligent pour les restaurer seulement après que tous les fichiers contenus ont été traités ([ source , voir à proximité If -p is in effect, set all the attributes ).

Si vous ne possédez pas d'autorisations root, la propriété n'est pas retenue. La raison en est que seul le root peut créer des fichiers appartenant à des utilisateurs et non pas par des groupes dont il n'est pas membre.

Pour que les sauvegardes de Time Machine soient visibles mais autrement immuables dans Finder, elles sont protégées par des listes de contrôle d'accès refusant à tous les utilisateurs toutes les autorisations de modification.

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

Étant donné que d'autres attributs (autres ACL, attributs étendus, dates de fichier et autorisations) doivent être conservés lors de la restauration de la sauvegarde, une gestion spéciale de ces dossiers est nécessaire dans Finder. Il doit supprimer une entrée ACL spécifique, mais conserver tout le reste.

De plus, Apple veut apparemment que Finder conserve toutes les informations de propriété lors de la copie de fichiers et de répertoires depuis la sauvegarde. Cela inclut l'appartenance au groupe .

Si votre compte n'est pas le propriétaire des répertoires en question, Finder demande un mot de passe d'administrateur et remet la copie à son programme Helmy de privilèges élevés Locum . Cela n'arrive pas lorsque vous êtes le propriétaire d'un fichier dans le jeu de sauvegarde.

Maintenant, l'un des cas suivants se produit:

• Vous n'êtes pas le propriétaire du fichier: Finder demande votre mot de passe, Locum restaure toutes les autorisations tout comme dans la sauvegarde.
• Vous êtes le propriétaire et le membre du groupe du fichier: Finder copie le fichier et rétablit le groupe.
• Vous êtes le propriétaire mais pas membre du groupe du fichier: Finder copie le fichier et ne rétablit pas son groupe.

C'est comme s'il s'agissait d'un chown username:groupname le fichier et imprime une erreur s'il échoue – ce qu'il fait si vous n'êtes ni root ( sudo ) ni username et membre de groupname .

Il se comporte légèrement différemment si vous ne copiez pas de dossiers, mais des fichiers: Bien que la propriété du fichier soit conservée, l'appartenance au groupe est rejetée si vous n'êtes pas membre du groupe. C'est ce que vous avez vu lors de la copie d'un seul fichier.

Les solutions évidentes à ce problème:

• Empêchez les propriétaires de fichiers qui font échouer la restauration (c'est-à-dire appartenant à vous et un groupe dont vous n'êtes pas membre – la plupart du temps, cela n'est pas utile de toute façon)
• Faites-vous membre de ce groupe en particulier au moins temporairement. Malheureusement, je n'ai pas pu le faire en utilisant dscl partir de la ligne de commande d'une manière qui a eu un effet sans se déconnecter ou redémarrer. Un autre effet secondaire est que, avec la wheel , vous pourriez rencontrer des problèmes avec les autorisations en fonction de la configuration de votre système.

Outre les autorisations de fichiers UNIX régulières (utilisateur / groupe / chacun ayant ses propres autorisations de lecture / écriture / d'exécution), Mac OS X utilise également des listes de contrôle d'accès (ACL) qui permettent des paramètres beaucoup plus importants des autorisations de fichiers / dossiers.

Time Machine ajoute (précède) l'ACL suivante à tous les fichiers:

Groupe: tous nient add_file, delete, add_subdirectory, delete_child, writeattr, writeextattr, chown

(L'ACL ci-dessus est spécifique au dossier, mais les cartes vers les fichiers réguliers sont les suivantes: add_file = write, add_subdirectory = append, delete_child = <none>)

Cela signifie que tous les fichiers / dossiers dans une sauvegarde Time Machine sont verrouillés pour tous (même l'utilisateur root).

Si vous restaurez vos fichiers manuellement à partir d'une sauvegarde de Time Machine (c.-à-d. Si vous n'utilisez pas l'assistant de migration), tous vos fichiers contiennent ces ACL ennuyeuses.

Il est assez facile d'enlever les ACL Time Machine. Vous avez trois options:

1) Faites pivoter la hache et retirez les ACL de vos fichiers / dossiers entièrement (rien de mal à cela, mais pas une stratégie très prudente)

2) Supprimez la première entrée des ACL de vos fichiers / dossiers (plus prudente mais pas une solution parfaite)

3) Supprimez les restrictions spécifiques des ACL de vos fichiers / dossiers (probablement votre meilleur pari si vous souhaitez conserver les ACL non imposées par Time Machine)

Pour les trois options, vous avez besoin du Terminal que vous trouverez dans / Applications / Utilitaires

Option 1: Voici comment vous basculez la hache:

Si vous savez que vous n'avez que vos fichiers personnels dans un dossier intitulé «Mes fichiers récupérés» sur votre bureau et que vous savez que ces fichiers n'ont pas besoin d'ACL de fantaisie, vous pouvez taper ce qui suit dans votre fenêtre Terminal:

Chmod -R -N ~ / Desktop / My \ Recovered \ Files

(Si vous ne connaissez pas le terminal de spécifier un fichier / dossier, faites simplement glisser et déposez le fichier / dossier que vous voulez sur la fenêtre Terminal et le terminal taper le nom du fichier / dossier correct pour vous)

Option 2: Voici comment vous supprimez la première entrée ACL

Le même exemple que ci-dessus. Vous avez un dossier intitulé «Mes fichiers récupérés» sur votre bureau. Mais dans ce cas, vous avez quelques fichiers avec ACL personnalisés que vous souhaitez conserver. Tapez ce qui suit dans la fenêtre Terminal:

Chmod -R -a # 0 ~ / Desktop / My \ Recovered \ Files

Ce qui rend la solution ci-dessus «dangereuse», c'est qu'il n'est pas idempotent. Une opération idempotente est une opération qui peut être appliquée à plusieurs reprises sans modifier le résultat après qu'elle ait été appliquée une fois. Comme multiplier un nombre par 1. Vous pouvez continuer à le faire, mais le résultat est toujours le même.

Pourquoi cela importe-t-il? Eh bien, disons que vous avez un fichier qui possédait déjà une ACL avant que Time Machine n'ait ajouté sa propre entrée ACL. Si vous exécutez deux fois la commande ci-dessus, vous avez supprimé l'ACL Time Machine ainsi que la ACL que vous ne vouliez probablement pas perdre.

De plus, la solution ci-dessus n'est pas idéale pour les fichiers Time Machine qui sont mélangés avec d'autres fichiers. Si l'un de ces autres fichiers (non-Time Machine) possède des ACL, la commande ci-dessus supprimera ces ACL.

Option 3: Voici comment supprimer des restrictions spécifiques d'une ACL

En plus de pouvoir spécifier l'entrée de numéro d'une ACL que vous souhaitez supprimer, vous pouvez également spécifier les restrictions spécifiques que vous souhaitez supprimer. Vous pourriez donc faire ceci:

Chmod -R -a "groupe: tout le monde nie le fichier add_french, supprime, add_subdirectory, delete_child, writeattr, writeextattr, chown" ~

("~" Signifie "mon répertoire personnel", c'est-à-dire si votre nom d'utilisateur est bob alors "~" = "/ Users / bob")

La commande ci-dessus est idempotente, ce qui signifie que vous pouvez l'exécuter encore et toujours sans effets secondaires. En fait, n'importe qui peut l'exécuter à tout moment. S'il n'y a pas de fichiers / dossiers verrouillés par Time Machine dans votre répertoire personnel, rien ne se produira.

D'ACCORD. J'espère que cela a été utile pour certaines personnes. J'ai eu le même problème avec les autorisations de Time Machine hier, alors j'ai pensé que je partagerais ce que j'ai découvert.

En fait, vous devez utiliser le tmutil pour restaurer les fichiers à partir de vos sauvegardes Time Machine. De cette façon, vous ne devrez pas supprimer les attributs étendus, etc.

Dans la page de manuel Mac OS X :

tmutil restore [-v] src ... dst

Restaurez l'élément src, qui se trouve dans un instantané, à l'emplacement dst. L'argument dst imite la sémantique du chemin de destination de l'outil cp. Vous pouvez fournir plusieurs chemins sources à restaurer. L'argument du dernier chemin doit être une destination.

Lorsque vous utilisez le verbe de restauration, tmutil se comporte en grande partie comme Finder. Les métadonnées Custom Time Machine (sécurité étendue et autres) seront supprimées des données restaurées et d'autres métadonnées seront préservées.

Les privilèges racines ne sont pas strictement nécessaires pour effectuer des restaurations, mais tmutil ne permet aucune vérification avant de déterminer votre capacité à restaurer src ou ses descendants. Par conséquent, en fonction de ce que vous rétablissez, vous avez peut-être besoin de privilèges root pour effectuer la restauration, et vous devriez le savoir à l'avance. C'est le même comportement que vous rencontrerez avec d'autres outils de copie tels que cp ou ditto. Lors de la restauration avec tmutil en tant que root, la propriété des éléments restaurés correspondra à l'état des éléments dans la sauvegarde.

Donc, fondamentalement, vous pouvez l'utiliser comme la commande cp sans vous soucier du repos interne.

Dans la plupart des cas, vous souhaitez restaurer avec sudo, lorsque vous ne le savez pas, si vous êtes le propriétaire des fichiers ou si vous avez des autorisations d'écriture pour le répertoire cible.