web-dev-qa-db-fra.com

Pourquoi la permission est-elle refusée lors de l'utilisation de mv alors que les droits de répertoire sont corrects?

Je reçois une autorisation refusée lorsque j'essaie de déplacer le dossier Music via mv bien que le propriétaire du répertoire soit défini sur mon utilisateur et que les autorisations utilisateur soient définies sur 7. Que se passe-t-il?

(Je sais que je pourrais utiliser Sudo mais je veux savoir ce qui ne va pas. Quelque chose sent le poisson ici). Ps: je suis sur Mac OS X El Capitan.

Terminal screenshot

filespermissionsosxdirectorymv
12
Timo

Notez que lorsque vous êtes dans le dossier a, en déplaçant b vers c, les autorisations de dossier de a déterminent ce que vous pouvez faire.

Dans ce cas, les autorisations sur . sera le plus important.

Notez que les autorisations sont plus complexes que simplement rwx. Votre dossier music a un @ à la fin, le . le dossier a un + à la fin.

  • Utilisation xattr -h pour déterminer les autorisations complexes pour le symbole @.
  • Utilisez getfacl pour déterminer l'ACL pour le symbole +.
20
Konerak

J'utilisais le sous-système Windows pour Linux. J'ai eu le répertoire ouvert dans une autre instance bash. La fermeture m'a permis de déplacer le répertoire.

15
Chris Anderson

On dirait qu'il y avait au moins 1 fichier quelque part au fond de ce répertoire qui n'avait pas les bonnes autorisations.

Donc, ce que j'ai fait, c'est:

Sudo chown -R valmar ./Music
Sudo chmod -R 755 ./Music

Maintenant ça marche.

9
Timo

Le problème ici a probablement à voir avec la liste de contrôle d'accès (ACL) du dossier Musique. L'ACL est un système d'autorisation distinct de ceux POSIX réguliers qui sont normalement répertoriés par ls -l. Certains autres répertoires dans le dossier Accueil et ailleurs ont également des listes de contrôle d'accès.

Pour voir les ACL dans le répertoire personnel, utilisez:

/bin/ls -le ~

Vous verrez probablement une règle comme 0: group:everyone deny delete pour le répertoire Musique. Comme vous l'avez noté, vous pouvez ignorer le problème avec Sudo. Si vous ne voulez pas faire cela (ou ne pouvez pas), vous avez d'autres options, étant donné que vous êtes le propriétaire du fichier. Vous pouvez supprimer l'entrée incriminée de l'ACL du répertoire Music, en fonction de son index (0 dans l'exemple que j'ai donné ci-dessus):

/bin/chmod -a# 0 Music

Ou vous pouvez supprimer toutes les entrées de l'ACL:

/bin/chmod -N Music

Vous pouvez maintenant déplacer le répertoire (sous réserve des autorisations POSIX normales). Si vous souhaitez remettre l'ACL après le déplacement, vous pouvez utiliser:

/bin/chmod +a "group:everyone deny delete" Music_tmp

Et utilise /bin/ls -le pour confirmer que l'ACL est comme vous le souhaitez. Consultez les exemples d'ACL dans man chmod pour plus d'informations. En particulier, cette introduction est utile:

Chaque fichier a une ACL, contenant une liste ordonnée d'entrées. Chaque entrée fait référence à un utilisateur ou à un groupe et accorde ou refuse un ensemble d'autorisations. Dans les cas où un utilisateur et un groupe existent avec le même nom, le nom de l'utilisateur/groupe peut être préfixé avec "utilisateur:" ou "groupe:" afin de spécifier le type de nom.

Commande ACL

Je ne pense pas que la page de manuel explique les règles de commande, mais cette page explique clairement les règles de commande des ACL. En particulier, une règle deny explicite sera appliquée avant une règle allow explicite. Donc, tant que le group:everyone deny delete l'entrée est en place, il n'est pas possible d'accorder à votre utilisateur la permission de supprimer avec une règle allow. En effet, l'autorisation est refusée au groupe everyone, qui vous inclut, et cette règle sera appliquée en premier.

4
spinup

J'ai eu ce problème lorsqu'un ensemble de programmes s'exécutait dans un répertoire que j'essayais de supprimer. Afin de déplacer le répertoire, j'ai dû d'abord tuer tous les programmes en cours d'exécution à partir de ce répertoire.

Dans les commandes suivantes, soyez très prudent sur la façon dont vous sélectionnez le nom de votre programme. J'ai utilisé les commandes suivantes, pour référence:

ps aux | grep -i [NAME_OF_ANNOYING_PROGRAM] | grep -v grep
# make sure that you are only about to kill the programs you want to kill

ps aux | grep -i [NAME_OF_ANNOYING_PROGRAM] | grep -v grep | awk '{print $2}' | Sudo xargs kill -9
Sudo mv /usr/local/[DIR_FOR_ANNOYING_PROGRAM] /usr/local/[DIR_FOR_ANNOYING_PROGRAM]2

La procédure générale est la suivante:

  1. tuer tous les programmes en cours d'exécution à partir du répertoire en question
  2. tenter de renommer le répertoire
  3. si cela échoue, forcez kill (kill -9 avec beaucoup de prudence ) tous les programmes du répertoire
  4. tenter de renommer le répertoire
  5. si cela échoue, voyez si le programme est à nouveau en cours d'exécution, c'est-à-dire qu'il a été redémarré par un programme démon exécuté à partir d'un répertoire différent
  6. forcer à tuer le programme démon qui redémarre le programme ennuyeux
  7. forcer à tuer le programme ennuyeux
  8. renommer le répertoire
  9. profit
3
WattsInABox

Cela peut également se produire lorsque l'un des fichiers à l'intérieur est protégé en écriture. J'ai eu l'affaire Edge aujourd'hui quand access.log était protégé en écriture pour Apache, qui était déjà arrêté. Je viens de supprimer ce fichier, donc j'ai pu déplacer le répertoire parent.

0
vintproykt