Este é o comando que estou executando na inicialização para montar meu compartilhamento remoto.
sudo -u nuzz smbnetfs ~/netmount -o smbnetfs_debug=5 -o smb_debug_level=5 -o log_file=~/logs/smbnetfs.log -o allow_other
Eu posso navegar meus arquivos no compartilhamento de rede muito bem. No entanto, ao executar um trabalho do CMake em que o destino está no compartilhamento, o trabalho trava ou vai muito lentamente e os arquivos não são gravados no disco. O arquivo smbnetfs.log lê:
2016-01-02 17:44:16.758 srv(1942)->smb_conn_srv_read: errno=13, Permission denied
2016-01-02 17:44:18.779 srv(1943)->smb_conn_srv_read: errno=13, Permission denied
2016-01-02 17:44:18.801 srv(1944)->smb_conn_srv_read: errno=13, Permission denied
2016-01-02 17:44:20.822 srv(1945)->smb_conn_srv_read: errno=13, Permission denied
2016-01-02 17:44:22.838 srv(1946)->smb_conn_srv_read: errno=13, Permission denied
Também vi entradas no arquivo de log relacionadas a CMakeError.log, mas nenhum arquivo de log jamais foi gravado. Meu palpite é que este arquivo foi tentado para ser escrito, mas não poderia fazê-lo.
Navegar na pasta enquanto a tarefa cmake está interrompida também é muito lenta. Demora cerca de 20-30 segundos para algo para carregar.
Eu verifiquei que meu smbnetfs.auth está correto (alterá-lo significa que não consigo fazer login).
Verifiquei que minha conta de usuário está no grupo de fusíveis.
Esse problema NÃO ocorre quando a pasta de origem no cmake está no compartilhamento, mas o destino está na unidade local. A unidade remota é uma partição do Windows 10 NTFS.
Se eu usar o sinalizador -s no smbnetfs (modo single-threaded), esse problema ainda ocorrerá.
Existem mais registros que podem ajudar a iluminar?
Por algum golpe de sorte bizarro, descobri que isso tem algo a ver com o valor max_retry_count em smbnetfs.conf . Configurar este valor para 0 (era 2) fez com que os problemas de lentidão desaparecessem. No entanto, os erros Permission denied ainda aparecem em smbnetfs.log . Vou declarar isso resolvido para os propósitos desta questão, mas parece que um relatório de bug está em ordem.