Porque é que Chown reporta "Operação não permitida" no OS X?

Sim, Mac tem muitos melhoramentos a Unix na área dos ficheiros. Ignorando toda a coisa garfo de recurso que já não é muito utilizada, existem:

• as permissões padrão Unix ugo rwx e assim por diante. Aplicam-se as ferramentas Unix normais.
• ACL‘s, visualizáveis com ls -le e modificáveis com chmod [-a | +a | =a].
• ** bandeiras de ficheiros*** visualizáveis com ls -lO& (Capital oh, não zero) e mutáveis com chflags.
• ** atributos ampliados** , visualizável com ls -l@ (apenas chaves de atributos) e visualizável e mutável com xattr. (Use xattr -h& para ajuda se man xattr não lhe der nada.)
• A partir do OS X 10.11 “El Capitan”, * System Integrity Protection ** (SIP) protege ainda mais alguns ficheiros de alterações de processos ordinários, mesmo quando usa sudo para correr como root. Os ficheiros protegidos pelo SIP serão listados por ls -lO como tendo a bandeira restricted e/ou ser listados por ls -l@ como tendo o atributo com.apple.rootless.

& podem ser-lhe negadas operações num ficheiro devido a permissões Unix, ACLs, bandeiras de ficheiro, ou SIP. Para desbloquear completamente um ficheiro:

sudo chmod -N file # Remove ACLs from file
sudo chmod ugo+rw file # Give everyone read-write permission to file
sudo chflags nouchg file # Clear the user immutable flag from file
sudo chflags norestricted file # Remove the SIP protection from file
sudo xattr -d com.apple.rootless file # Remove SIP protection from file

Se a Protecção de Integridade do Sistema (SIP) estiver activada, sudo chflags norestricted e sudo xattr -d com.apple.rootless devolverá também um erro “Operação não permitida”. Para limpar a bandeira e/ou atributo é necessário arrancar em macOS Recovery e executar os comandos a partir do Terminal (poderá ter de usar primeiro o Disk Utility para desbloquear e montar a sua unidade de arranque, depois lembre-se que os seus ficheiros estarão abaixo de /Volumes/Macintosh HD ou qualquer que seja o nome da sua unidade de arranque) ou desactivar completamente o SIP e depois reiniciar e os comandos deverão então funcionar. Esteja ciente, contudo, de que futuras actualizações do SO irão provavelmente restaurar a bandeira restricted e o atributo com.apple.rootless a quaisquer ficheiros de onde o tenha removido.

_ Desactivar o SIP não é recomendado _ pois remove muita protecção contra malware e danos acidentais, além de não ser necessário quando se pode simplesmente remover a protecção numa base por ficheiro. Se desactivar o SIP, volte a activá-lo quando terminar de fazer alterações.

Note que se ls -lO mostra que a bandeira schg está definida, tem de entrar em modo de utilizador único para a desactivar. Não vou entrar nisso aqui, pois há questões maiores sobre a razão pela qual o ficheiro tem essa bandeira definida e porque se está a tentar mexer com ela e quais serão as consequências.

Eu tinha o mesmo problema. Acontece que os ficheiros ofensivos foram marcados como “Bloqueados” pelo sistema operativo. Encontrei esta solução e resolvi os problemas em segundos: http://explanatorygap.net/2005/07/10/unlocking-files-recursively-from-the-command-line/

Parece que o comando rm mudou no Tigre de tal forma que se usar rm -Rf com privilégios elevados, desbloqueará automaticamente os ficheiros.

No OS X antes do Tigre: find /Volumes/Transit -flags +uchg -print0 | xargs -0 chflags nouchg

No OS X depois do Tigre: sudo rm -Rf foldername/

Também, mesmo depois do OS X 10.4, pode haver bandeiras de metadados de ficheiros tais como uchg e uappnd, o que impede qualquer modificação das permissões ou propriedade do ficheiro. chflags& pode remover as bandeiras. Alguns dos atributos/metadados do ficheiro e a forma como são tratados por diferentes ferramentas de cópia são aqui .

No OS X 10.11 (El Capitan), isto também pode ser causado pela nova funcionalidade Rootless*. Ver esta resposta para uma explicação.

Em suma, para certos directórios importantes, não há maneira de os modificar - quer se use sudo, chown ou chmod. Isto afecta o directório /usr, (embora lhe seja permitido modificar /usr/local).

Para modificar um directório protegido Rootless, é necessário desactivar o Rootless . E, claro, voltar a activá-lo depois de fazer as suas modificações, porque é um importante reforço de segurança.

Tive o mesmo problema com o Crashplan.app.

Todas as soluções aqui listadas não me ajudariam, mas esta fez o truque http://forums.macrumors.com/showthread.php?t=1546163

Tem de mudar o sistema e as bandeiras imutáveis do utilizador:

Faça isto para ver que bandeiras estão activas no seu ficheiro/pasta:

ls -lhdO MyFile

A resposta pode ter este aspecto:

drwxrwxr-x 3 root admin schg,uchg 102B Apr 8 2013 MyFile

schg , uchg* são essas bandeiras imutáveis. Uma para o sistema e outra para o utilizador. Para as remover, faça o seguinte:

chflags noschg CrashPlan.app # this removes system immutable flag
chflags nouchg CrashPlan.app # this removes the user immutable flags

Depois, pelo menos para mim, o ficheiro é desbloqueado e pode apagá-lo!

Depois de muita luta, eis o que tive de fazer para resolver o problema:

• Mudei o ficheiro para ~/Desktop
• sudo chown myusername:staff ./entries
• Mover o ficheiro de volta à sua localização original não funcionou (Operação não permitida, novamente), por isso…
• sudo rm ./entries
• sudo mv ~/Desktop/entries ./entries - 0x6&

Tive o mesmo problema, sobre a minha pasta de casa. No final, acabei de usar um localizador como este:

Go -> Computador -> o seu disco -> Utilizadores -> o seu nome de utilizador -> clique com o botão direito do rato -> Obter Info

Descobri que estava bloqueado, provavelmente fi-lo no passado e esqueci-me. Desmarquei a caixa de verificação bloqueada, problema resolvido.

Posso recomendar a utilização de ‘Get Info’ do finder para resolver este tipo de problemas.

(OS X 10.8.3)

Certifique-se de que tanto o ficheiro como a sua pasta principal estão desbloqueados

Eu estava a enfrentar um problema semelhante ao tentar apagar um ficheiro de assinatura de correio electrónico Mac Mail. Não consegui apagá-lo até ter desbloqueado o ficheiro, bem como a sua pasta principal.