Conversei com as pessoas da infraestrutura, e a resposta é que existem ACLs estendidas no local que agem de maneira diferente com base na localização e que foram erroneamente definidas.
Sempre que eu criar novos diretórios em minha casa (ou em seus subdiretórios), eles não terão permissão de gravação, mesmo que umask esteja definida corretamente. Os arquivos que eu faço têm permissão de gravação.
[mmanary@seqap33 ~]$ umask
0002
[mmanary@seqap33 ~]$ mkdir testDir
[mmanary@seqap33 ~]$ touch testFile
[mmanary@seqap33 ~]$ ls -l
dr-xr-x--- 2 mmanary mmanary 0 Apr 15 10:25 testDir
-rw-rw-r-- 1 mmanary mmanary 0 Apr 15 10:26 testFile
Se eu alternar para um diretório de armazenamento de grupo compartilhado, os novos diretórios terão permissão de gravação. Eu posso trocá-los com o chmod facilmente, MAS ao usar tar, o novo diretório não pode ser escrito para que o tar falhe com "Permission Denied". Qualquer ajuda é apreciada.
Editar: li outras perguntas sugeridas, mas não pareço aplicar diretamente porque elas envolvem casos mais complicados (outros usuários envolvidos). Caso isso ajude:
[mmanary@seqap33 ~]$ getfacl .
# file: .
# owner: mmanary
# group: mmanary
user::rwx
group::r-x
other::---
Edit2: Sob conselho de comentários, meu sistema de arquivos é NFS
A única vez em que vi esse tipo de cenário é quando o compartilhamento NFS é exportado de um servidor Windows executando NFS para serviços do Windows. Os atributos POSIX exigidos pelo mundo Unix / Linux não são mapeados corretamente nos atributos NTFS e o resultado é que as permissões exibem uma coisa e (às vezes) agem como outra.
Em nossa situação específica, passamos algumas semanas tentando resolver a situação e, por fim, apagamos o sistema Windows e instalamos um sistema baseado em Linux no hardware.
Se o bit chmod + pegajoso estiver definido na pasta, o umask será substituído pelos atributos do proprietário da pasta. é por isso que você pode estar vendo resultados inconsistentes entre pastas.
Tags permissions chmod umask mkdir linux