Samba 4.1 process_usershare_file: o estado de / var / lib / samba / usershares / share falhou. mesmo que o usuário possa listar essa pasta e o arquivo stat

2

Eu tenho dois usuários idênticos, um pode acessar o compartilhamento enquanto os outros não conseguem. O nome do compartilhamento é storage_photos , está localizado na pasta /storage/photos/ .

$ getfacl /storage/photos
getfacl: Removing leading '/' from absolute path names
# file: storage/photos
# owner: root
# group: photos
user::rwx
group::rwx
group:photos:rwx
mask::rwx
other::r--
default:user::rwx
default:group::rwx
default:group:photos:rwx
default:mask::rwx
default:other::r--

Os dois usuários em questão são membros do grupo photos :

$ groups john
john : john sambashare photos

$ groups lisa
lisa : lisa sambashare photos

E a partir de sua participação na pasta sambashare, eles podem listar /var/lib/samba/usershares/ :

sudo -u lisa ls -ltha /var/lib/samba/usershares/
total 24K
drwxrwx--T 2 root sambashare 4.0K Oct 25 17:06 .
-rw-r--r-- 1 root root        125 Oct 25 17:06 storage_photos

Com isso em mente, é estranho descobrir que um usuário não consegue acessar o compartilhamento enquanto o outro consegue:

smbclient //Server/storage_photos -U lisa%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED

smbclient //Server/storage_photos -U john%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
smb: \>

No lado do servidor, a falha, com o nível de registro 2, se parece com:

[2015/10/25 23:12:20.646681,  0] ../source3/param/loadparm.c:4365(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied
[2015/10/25 23:12:20.649381,  2] ../source3/smbd/service.c:407(create_connection_session_info)
  guest user (from session setup) not permitted to access this share (storage_photos)
[2015/10/25 23:12:20.649437,  1] ../source3/smbd/service.c:550(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

Enquanto isso, o sucesso é chato:

[2015/10/25 23:14:30.321507,  2] ../source3/smbd/service.c:856(make_connection_snum)
  device (ipv4:192.168.1.5:46134) connect to service storage_photos initially as user john (uid=1000, gid=1000) (pid 5297)
[2015/10/25 23:16:10.409218,  1] ../source3/smbd/service.c:1130(close_cnum)
  device (ipv4:192.168.1.5:46134) closed connection to service storage_photos

Agora, a parte interessante da falha é a seguinte: process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied . Por que o acesso falharia mesmo que o usuário pudesse registrar o arquivo:

sudo -u lisa stat /var/lib/samba/usershares/storage_photos
  File: ‘/var/lib/samba/usershares/storage_photos’
  Size: 125             Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 137795      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-10-25 17:06:46.704318935 +0100
Modify: 2015-10-25 17:06:46.700318935 +0100
Change: 2015-10-25 17:06:46.700318935 +0100
 Birth: -

A partir disso, podemos concluir que, por alguma razão, o samba não está usando o usuário unix correto para registrar o arquivo quando o lisa tenta efetuar login, mas é quando o john faz.

Tanto john como lisa podem fazer ssh na máquina. A máquina tem libpam-smbpass instalado conforme prescrito em esse estouro de pilha pergunta . Mas, depois de reiniciar o servidor, o problema persiste.

Tudo isso está usando o seguinte, muito padrão, Ubuntu 14.04 smb.conf. Os compartilhamentos são definidos por sistemas de arquivos ZFS com o parâmetro sharesmb ativado.

[global]  
        workgroup = ONE  
        server string = %h server (Samba, Ubuntu)  
        server role = standalone server  
        map to guest = Bad User  
        obey pam restrictions = Yes  
        pam password change = Yes  
        passwd program = /usr/bin/passwd %u  
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .  
        unix password sync = Yes  
        syslog = 0  
        log file = /var/log/samba/log.%m  
        max log size = 1000  
        dns proxy = No  
        usershare allow guests = Yes  
        panic action = /usr/share/samba/panic-action %d  
        idmap config * : backend = tdb
    
por Rovanion 25.10.2015 / 23:57

2 respostas

1

Por algum motivo, a reinstalação de winbind no servidor resolveu o problema, mas não imediatamente. Como se houvesse algum cache acontecendo com a autenticação. Portanto, a solução é executar o seguinte e depois relaxar por um tempo.

sudo apt-get remove winbind && sudo apt-get install winbind

Sinto muito, mas não consigo pensar em uma razão pela qual isso resolveria o problema ao reiniciar o winbind, porque o apt deve preservar arquivos de configuração, desde que você não esteja limpando um pacote.

    
por 25.10.2015 / 23:57
1

A mensagem de erro "process_usershare_file" é muito enganosa e está relacionada a user_shares, que se destinam a permitir que um usuário local conectado à GUI compartilhe pastas com outras estações de trabalho, no estilo windows. Essa configuração é completamente irrelevante em servidores samba dedicados (onde ninguém nunca trabalha no console local), mas infelizmente está ativada por padrão na maioria das distros, e frequentemente causa erros espúrios como esses. Pior, o fluxo de erros até atrasa o servidor às vezes (é muito perceptível em servidores conectados rápidos de 10GigE).

Para se livrar dessa mensagem, adicione isso à seção [global] do arquivo smb.conf :

usershare max shares = 0

E reinicie o smbd para ativá-lo. Pelo menos, impedirá que os clientes do Samba tentem acessar compartilhamentos de usuários inexistentes e spam seus registros.

    
por 27.07.2018 / 16:59

Tags