Depois de migrar um compartilhamento de rede maildir (CIFS) para um novo servidor de armazenamento, comecei a ter problemas com as permissões de arquivo (usuários incapazes de excluir emails antigos). Meu serviço IMAP é o Dovecot, mas podemos identificar o problema em um nível inferior a esse.
Como root , posso navegar para um diretório de correio que exibe esse problema no servidor que hospeda os arquivos e o servidor no qual eles estão montados (doravante denominado 'cliente') e experimente / observe o seguinte comportamento:
Procurando por quaisquer ACLs que possam estar afetando arquivos mais antigos, obtenho essa saída no servidor:
root@<storage-server>:/<path-to-share>/<site>/<user>/folders/cur# getfacl <filename>
# file: <filename>
# owner: mail
# group: mail
user::rw-
group::rw-
other::---
getfattr não produz nada.
O servidor de armazenamento era anteriormente um sistema operacional abandonware solaris + debian (Nexenta) servindo com o CIFS em um pool de armazenamento do ZFS. Agora é o Ubuntu 16.04, novamente servindo com o CIFS em um pool de armazenamento do ZFS. Em todos os casos, as ACLs são / foram suportadas, mas não usadas em nenhum lugar.
Minha configuração de compartilhamento do Samba:
[Maildir]
path = /<path-to-share>
browseable = no
guest ok = no
valid users = mail
writable = yes
create mode = 0660
directory mode = 0770
, que é montado como //<host>/Maildir /var/mail cifs auto,credentials=/root/.smb_mail,user,rw,exec 0 0 . Todas as propriedades do zfs estão no padrão para este sistema de arquivos e seus pais.
Eu tentei remover o modo modo de criação / diretório e adicionar @mail a usuários válidos, tudo sem efeito.
De que outra forma minhas permissões poderiam estar erradas?
Atualização:
Eu tentei mudar para um compartilhamento NFS, e o problema persiste . Eu tentei copiar o conteúdo do maildir para um novo local (em um novo sistema de arquivos diferente) com cp -r e chown -r mail:mail , e novamente ele persiste, enquanto é servido de um caminho completamente diferente.
Por fim, tentei mv somefile backup && rm somefile && cat backup > somefile && chown mail:mail somefile e a tentativa de ler esse arquivo ainda falha com Permissão negada.
Não sei como as operações em arquivos específicos podem ser bloqueadas de maneira independente do mecanismo de compartilhamento, localização lógica, permissões / propriedade do UNIX e até mesmo qualquer forma de metadados de arquivo.
Atualização 2:
Eu tive outra chance de mudar para um compartilhamento NFS e desta vez a questão da permissão foi embora. No entanto, eu não quero mudar para o NFS, pois está causando outros problemas, particularmente para a inicialização. O problema é definitivamente com o samba, mas limpar todos os dados operacionais (vários arquivos .tdb e .dat, etc.) também não ajudou.
Atualização 3:
O problema foi reduzido a nomes de arquivos com dois-pontos neles. Renomear um arquivo para remover o cólon o torna legível no cliente, e renomear para um nome arbitrário e original com dois pontos torna-o ilegível. Parece que o Dovecot está renomeando os arquivos ao longo do tempo para rastrear algumas informações e que adiciona dois pontos, o que eventualmente torna todos os emails ilegíveis / não-regraváveis, mas isso também teria sido o caso anteriormente.
Algumas observações adicionais: criar e ler um arquivo com dois pontos no cliente funciona (e os dois pontos aparecem como aspas duplas no servidor). Aliás, é assim que teríamos nomes de arquivos com dois pontos ... Os arquivos mais recentes parecem ter dois pontos, mas no servidor são mostrados como tendo uma aspa dupla e dois pontos.
Está começando a parecer algum tipo de problema de codificação - especialmente estranho, já que esses dois sistemas são homogêneos pela primeira vez.