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 Musicvia mvbien 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 découvrir ce qui ne va pas. Quelque chose sent le poisson ici). Ps: je suis sur Mac OS X El Capitan.

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

Dans ce cas, les autorisations sur .seront les plus importantes.

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

• Utilisez xattr -hpour déterminer les autorisations complexes pour le symbole @.
• Utilisez getfaclpour déterminer l'ACL pour le symbole +.

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.

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.

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 ACL.

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

/bin/ls -le ~

Vous verrez probablement une règle comme 0: group:everyone deny deletepour le répertoire Musique. Comme vous l'avez noté, vous pouvez contourner 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 utilisez à /bin/ls -lenouveau pour confirmer que l'ACL est comme vous le souhaitez. Consultez les exemples ACL man chmodpour 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 denyrègle explicite sera appliquée avant une allowrègle explicite . Ainsi, tant que l' group:everyone deny deleteentrée est en place, il n'est pas possible d'accorder à votre utilisateur la permission de supprimer avec une allowrègle. En effet, l'autorisation est refusée au everyonegroupe, qui vous inclut, et cette règle sera appliquée en premier.

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 à tuer ( kill -9avec 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 en cours d'exécution à nouveau, 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

Cela peut également se produire lorsque l'un des fichiers à l'intérieur est protégé en écriture. J'ai eu le cas de bord 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.