Por que obtenho permissão negada ao usar mv, embora os direitos de diretório estejam corretos?


13

Eu me permissão negada ao tentar mover a pasta Musicvia mvembora proprietário do diretório está definido para meus usuários e usuários permissões são definidas a 7. O que está acontecendo?

(Eu sei que eu poderia usar o sudo, mas quero descobrir o que há de errado. Algo cheira a peixe aqui). Ps: Estou no Mac OS X El Capitan.

Captura de tela do terminal


1
Qualquer pessoa que se depare com o mesmo erro, pode ser porque você está tentando criar um arquivo aberto. Não é o caso do OP, apenas dizer isso pode ajudar.
Aderchox

Respostas:


20

Observe que, quando estiver na pasta a, movendo b- se para c, as permissões da pasta adeterminam o que você pode fazer.

Nesse caso, as permissões .ativadas serão mais importantes.

Observe que as permissões são mais complexas do que simples rwx. Sua musicpasta tem um @no final, a .pasta tem um +no final.

  • Use xattr -hpara determinar as permissões complexas para o símbolo @.
  • Use getfaclpara determinar a ACL para o símbolo +.

Você tem um recurso que cobre "permissões complexas", como você as chama?
user1717828

man xattrpode ser um bom ponto de partida.
21978 Konerak #

1
não, nenhuma entrada manual. Pude procurar no Google outro nome para ele: atributos estendidos , se alguém quiser saber mais.
user1717828

4
Ou use ls -la@e. Provavelmente aqui, houve deny deleteACLs que também impedem a renomeação.
Stéphane Chazelas

1
@Timo, essas ACLs evitam excluir ou renomear esses diretórios. Presumivelmente, eles foram colocados lá por um motivo, como alguns aplicativos contam com a presença deles e falhariam de outra maneira.
Stéphane Chazelas

18

Eu estava usando o Windows Subsystem para Linux. Eu tive o diretório aberto em uma instância diferente do bash. Fechando, deixe-me mover o diretório.


3
No VS Code com controle remoto no WSL, tive que fechar o editor e abrir um terminal para o WSL fora desse projeto do VS Code.
Bjorn

9

Parece que havia pelo menos 1 arquivo em algum lugar profundo naquele diretório que não tinha as permissões corretas.

Então, o que eu fiz foi:

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

Agora funciona.


17
Qualquer que seja o problema, conceder permissões de execução a arquivos de música não deve ser a solução.
Stéphane Chazelas

3
E parece improvável que um objeto em um diretório possa interferir na sua capacidade de renomear esse diretório.
6165 Scott

Eu sei que é estranho, mas esse foi o truque. O uso de chmod e chown no próprio diretório não teve efeito.
Timo

é possível que você tenha chmod 755removido as permissões especiais '@' na pasta Música?
HorusKol 07/10/2015

@HorusKol, ou o chown. Os sintomas do OP corresponderiam aos diretórios com ACLs de exclusão negada , mas pelo menos no Yosemite, executar um chown ou chmod 755 não exclui essa ACL. Você precisaria chmod -a 'everyone deny delete' Musicdisso. Pode ser diferente em El Capitan.
Stéphane Chazelas

4

O problema aqui provavelmente está relacionado à lista de controle de acesso (ACL) da pasta Música. A ACL é um sistema de permissão separado dos POSIX regulares, normalmente listados por ls -l. Alguns outros diretórios na pasta Home e em outros lugares também têm ACLs.

Para ver as ACLs no diretório inicial, use:

/bin/ls -le ~

Você provavelmente verá uma regra como 0: group:everyone deny deletepara o diretório Música. Como você observou, você pode substituir o problema com sudo. Se você não quiser fazer isso (ou não puder), terá outras opções, pois é o proprietário do arquivo. Você pode retirar a entrada incorreta da ACL do diretório Música, com base em seu índice (0 no exemplo que forneci acima):

/bin/chmod -a# 0 Music

Ou você pode remover todas as entradas na ACL:

/bin/chmod -N Music

Agora você pode mover o diretório (sujeito às permissões POSIX regulares). Se você deseja devolver a ACL após a mudança, use:

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

E use /bin/ls -lenovamente para confirmar que a ACL está como você deseja. Confira os exemplos da ACL man chmodpara mais informações. Em particular, esta introdução é útil:

Cada arquivo possui uma ACL, contendo uma lista ordenada de entradas. Cada entrada se refere a um usuário ou grupo e concede ou nega um conjunto de permissões. Nos casos em que um usuário e um grupo existem com o mesmo nome, o nome do usuário / grupo pode ser prefixado com "usuário:" ou "grupo:" para especificar o tipo de nome.

Pedido ACL

Não acho que a página de manual explique as regras sobre pedidos, mas esta página explica claramente as regras de pedidos para ACLs. Em particular, uma denyregra explícita será aplicada antes de uma allowregra explícita . Portanto, enquanto a group:everyone deny deleteentrada estiver em vigor, não é possível conceder ao usuário permissão para excluir com uma allowregra. Isso ocorre porque a permissão é negada ao everyonegrupo, que inclui você, e essa regra será aplicada primeiro.


2
Não sei por que isso foi rebaixado. A everyone deny deleteentrada ACL nos diretórios pessoais padrão do macOS é a verdadeira razão pela qual os diretórios não podem ser movidos nem excluídos. (Além disso, observe que o sistema operacional pode recriá-los a qualquer momento).
Diti

1
esta resposta BALANÇOU !!! caramba, essas novas ACLs são uma ENORME PITA.
21719 Dean

3

Eu tive esse problema quando um conjunto de programas estava sendo executado em um diretório que estava tentando remover. Para mover o diretório, primeiro tive que matar todos os programas em execução nesse diretório.

Nos comandos a seguir, tenha muito cuidado com a maneira como você seleciona o nome do seu programa. Eu usei os seguintes comandos, para referência:

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

O procedimento geral é:

  1. mate todos os programas em execução no diretório em questão
  2. tentativa de renomear diretório
  3. se isso falhar, force a eliminação ( kill -9com muita cautela ) de todos os programas do diretório
  4. tentativa de renomear diretório
  5. se isso falhar, veja se o programa está sendo executado novamente, ou seja, foi reiniciado por algum programa daemon em execução em um diretório diferente
  6. forçar a matar o programa daemon que reinicia o programa irritante
  7. forçar a matar o programa irritante
  8. renomear diretório
  9. lucro

1
Eu não acho que o OP provavelmente tenha programas em execução no diretório ~ / Music. De qualquer forma, ele disse que não quer usar o sudo, o que esta resposta faz.
spinup 27/02/19

Tudo o que estou dizendo é que tive essa situação. Pode ser útil para alguém, mesmo que não tenha sido útil para o OP.
WattsInABox 01/01/19

É possivelmente útil para alguém, certamente - é por isso que não diminuí o voto. Mas acho que a intenção do StackExchange é que as respostas postadas realmente respondam à pergunta que foi feita.
spinup 01/03/19

1
Outro problema em potencial, se você deseja que esta resposta seja de uso geral a um iniciante: você não fornece nenhum aviso sobre como escolher os termos de pesquisa com muito cuidado no primeiro momento grepe verificá-los. Tudo o que você está colocando-se para que o primeiro grepvai escolher entre a piscina de todos os programas em execução e killcom privilégios de root ...
spinup

1
Bom, @ Watts, acho que é uma grande melhoria #
spinup

0

Isso também pode acontecer quando um dos arquivos internos está protegido contra gravação. Hoje tive o caso de ponta quando access.logestava protegido contra gravação no Apache, que já estava parado. Acabei de remover este arquivo, para poder mover o diretório pai.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.