Esta semana eu me deparei com um problema intrigante em uma rede mista composta de estações Linux, Windows e Mac OS. O cliente reclamava que sem qualquer motivo aparente todas as suas estações Apple tornaram-se absurdamente lentas para acessar compartilhamentos Samba enquanto as estações Linux e Windows continuam o acesso normalmente. A solução foi mais simples do que parecia e consistiu em apagar alguns arquivos irrelevantes que o sistema da Maça cria.
Quando eu digo “tornaram-se absurdamente lento” entende-se que eu quero dizer que antes do problema os diretórios compartilhados eram carregados em 5 segundos e após o problema passaram a levar até 5 minutos. E não falo aqui de diretórios muito grandes não. O maior diretório tinha cerca de 500 arquivos JPG.
Depois de muito pesquisar a relação entre os sistemas Apple e o Samba e também testar várias otimizações no smb.conf do servidor a conclusão que cheguei era que definitivamente o problema era o Mac e não o servidor. Então passei a procurar no Google simplesmente por “mac lento”, “otimizar mac” etc. Até que encontrei umas discussões em forums sobre uns arquivos de metadados que o Mac cria em qualquer disco externo formatado como FAT ou unidades de rede remotas SMB/CIFS.
Trata-se dos arquivos .DS_Store e ._nomedoarquivooriginal. O primeiro é criado pelo “Finder”, gerenciador de arquivos do Mac OS, para armazenar atributos da pasta onde ele está, como seu papel de parede, posição dos ícones etc – você deve encontrar um arquivo por pasta que o Finder resolva mexer; o segundo é para armazenar atributos individuais para cada arquivo, assim se você tiver um arquivo “Praia com a galera.jpg” você também terá um arquivo “._Praia com a galera.jpg” contendo metadados sobre o primeiro arquivo. Veja que estes arquivos são invisíveis pelo Mac. Você só os encontrará no servidor samba, pela linha de comandos, ou usando um gerenciador de arquivos gráfico que permita listar arquivos ocultos.
Todos os textos que li sobre otimização do Mac (nenhum deles oficial) sempre indicavam a exclusão destes arquivos. Em uma nova conversa com o cliente descobri que por algum tempo ele excluia estes arquivos manualmente pois eram “muito chatos”, mas ele acabou desistindo de apagá-los porque sempre apareciam denovo. Bingo! achei o motivo da lentidão e quando ela começou a aparecer.
Após convencer o cliente que este era o motivo da lentidão e conseguir sua autorização para removê-los, eu os removi a partir da linha de comandos do servidor Samba:
find /mnt/storage -type f -iname ".ds_store" -delete
find /mnt/storage -type f -iname "._*" -delete
Adicionei uma regra “veto files” na seção global do smb.conf impedindo a criação destes arquivos novamente:
veto files = /.DS_Store/._*/
E após reiniciar o serviço samba o problema estava resolvido.
service samba restart
ou, dependendo do seu S.O.:
service smb restart
service nmb restart
Foi só acessar o compartilhamento a partir de qualquer estação Mac OS e mostrar ao cliente que o trabalho estava concluído com sucesso.
Adicionalmente a isso, há no site da Apple[1] e em alguns outros sites uma dica para fazer o Mac OS não criar estes arquivos. A linha de comandos abaixo deve ser rodada na linha de comandos de cada estação Mac OS. Como teria que rodar isso em todas as estações eu optei por não executá-la, mas que ela fique aqui registrada para o caso de ser necessário usá-la futuramente:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
É importante lembrar, que excluir aqueles arquivos fará com que os usuários percam a capacidade de destacar arquivos com cores diferentes e fazer anotações sobre eles (por isso eu primeiro pedi autorização ao cliente) entretanto já podem acessar os seus dados mais rápido. Trocamos usabilidade por performance.
[1] Apple. Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections. http://support.apple.com/kb/HT1629
Show de bola, obrigado por compartilhar o conhecimento. Talvez, em breve, chegarão máquinas Mac onde trabalho e já estarei prevenido.
Meus parabéns !!!
Parabéns
Estava com mesmíssimo problema, vc me salvou
Cara, obrigado pela ajuda, funcionou dereitinho aqui na minha agência!!
Boa noite.
Tenho uma rede com um servidor AD Windows 2008 onde as estações MAC apresentaram a mesma lentidão no acesso às pastas compartilhadas.
Você acha que esse procedimento de aplica ao meu caso?
Grato
@Homero,
Nunca trabalhei com AD, mas possivelmente sim. Já que “em tese” o Samba se comporta como um servidor Windows e o problema não era relacionado ao Samba em si, mas ao ao acesso aos recursos de rede. Você pode testar remover os malditos arquivos em uma pasta pequena e se der certo fazer nas demais. abç
Obrigado, pela dica, funcionou muito bem, parabens
amigo, tive esse problema, porem solucionei de outra maneira muito simples, entre no finder e coloquei para conectar com o servidor, porem utilizei o protocolo AFP …. funcionou perfeitamente… esta muito rápido… não sou técnico .. posso estar usando algo ultrapassado .. porem não consegui executar esses comandos.. portanto.. minha solucao por ficar para os Noobs/
cara, 2023 e isso me ajudou! valeu demais
Estes comandos tem que ser executados como estão escritos? Ou tenho que mudar algum nome neles? Estou com este problema mas não estou conseguindo resolver, por favor espero ajuda de vocês meu email xxxxxxx@xxxxxx.com
@Rodrigo ,
Os dois comandos “find” devem ser executados a partir do prompt de comandos do seu servidor Samba. Você deve estar logado como “root” e deve alterar o “/mnt/storage” pelo caminho correto que corresponde ao seu compartilhamento.
amigo, eu tenho um imac com a versao 10.12 (sierra) e o servidor linux, acho que eh o linux samba.
tenho umas pasta com 15mil fotos que uso sempre pois diagramo produtos de supermercado e la estao todos os produtos, vc sabe me dizer se fazendo isso terei uma melhora?
bom dia Mauricio, não sei como as novas versões do Mac estão trabalhando mas se eles geram estes arquivos ainda, possivelmente sim. Só tem um jeito de descobrir. Testando. Na dúvida se você se sentir desconfortável faça um backup antes.
Amigo, depois que fiz o procedimento os arquivos carregaram normalmente, porem os programas como o photoshop por exemplo, o usuário não tem mais como alterar o arquivo pela rede da um erro de permissão, mais quando ela salva na mesa e copia o arquivo para rede salva. fiquei com essa bronca. se abrir pelo aplicativo como por exemplo o photoshop não salva as alterações nem salva um novo arquivo.
E ai Elizeu,
Eu descrevi três procedimentos no texto. (1) Localizar e remover os arquivos existentes; (2) Bloquear a criação dos arquivos no servidor samba; (3) impedir que o Mac OS crie novos arquivos.
O primeiro procedimento, como eu disse no texto, não deveria afetar nada mais além dos metadados adicionais da Apple;
O segundo que creio ser o culpado pelo problema já que em tese o seu Photoshop pode fazer questão de tentar gravar os arquivos de metadados mas o samba está com a configuração de “veto files” ativa o PS não consegue gravar o arquivo de metadados e reclama que não tem permissão.
Já o terceiro procedimento é uma possibilidade a testar, já que estamos dizendo ao Mac OS para não criar mais os arquivos e pode haver ai um problema de entendimento entre o que o Mac OS está determinando e o que o Photoshop quer fazer (bug?!)
Como você não disse exatamente o que fez só posso deduzir que tenha feito os três procedimentos, ou ao menos o segundo, ou o terceiro.
Minha sugestão. Se fez o terceiro procedimento desfaça-o em uma estação e verifique se resolveu. Se fez o segundo, desfaça-o na configuração do servidor samba e teste a partir de qualquer estação.
Se nenhuma das opções resolver então o mais provável é que este problema de permissão já existia mas só agora você está dando conta dele. Ai você vai ter que fazer uma analise mais minuciosa do caso e testar se não é a permissão da pasta, usuário, grupo, antivirus …
Excelente dica.
Parabéns e obrigado.
abs,
JR
Ficou bom.
Porém a única coisa é que todas as pastas ficou com a data de hoje. Para pesquisar e saber a última pasta dá um maior trabalho. Os arquivos não foram modificados ainda bem. 🙂
Ander.