Não é possível gravar no compartilhamento de samba com determinado nome

2

TL; DR: O que mais (além da propriedade de arquivo / read only = no em smb.conf) poderia impedir que o samba permitisse acesso de gravação a um compartilhamento? Como o nome do compartilhamento afeta as permissões?

Portanto, eu tenho o Ubuntu Server 16.04 LTS (a versão do samba é 4.3.9 + dfsg-0ubuntu0.16.04.2) com um dispositivo USB montado em / mnt / storage. A saída mount é

/dev/sdb1 on /mnt/storage type ext4 (rw,relatime,errors=remount-ro,data=ordered)

Todos os arquivos no diretório /mnt/storage são de propriedade e podem ser gravados pelo usuário htpc :

htpc@htpc:~$ ls -l /mnt/

insgesamt 16
drwxrwxr-x 13 htpc htpc 4096 Sep  8 23:26 storage

htpc@htpc:~$ ls -l /mnt/storage/

insgesamt 108
drwxr-xr-x 21 htpc htpc  4096 Mär 16 20:55 somedirectory
-rw-r--r--  1 htpc htpc  3870 Sep 11 09:02 somefile.txt
drwxr-xr-x 24 htpc htpc  4096 Apr 10 00:25 ...

Aqui está o meu compartilhamento smb.conf (todas as outras configurações são mantidas como padrão):

[Media]
path = /mnt/storage
comment = HTPC Media server
valid users = htpc
read only = no
browseable = yes

Eu criei um usuário do samba com sudo smbpasswd -a htpc .

O compartilhamento pode ser acessado com o Windows 10, mas eu não tenho permissão de gravação (a criação, a exclusão e a modificação de arquivos não são permitidas). O mais estranho é que eu não tenho esse problema quando compartilho qualquer outro diretório (por exemplo, crie um diretório simples /opt/testshare e compartilhe esse diretório da mesma forma como acima).

EDITAR

Isso é tão estranho. O problema não era o dispositivo usb, era o nome do compartilhamento "Mídia".

Por qualquer motivo, o compartilhamento é somente de leitura quando eu nomeio "Mídia" . Eu encontrei este tópico e este tópico que tem problemas semelhantes, mas chegam à conclusão de que o compartilhamento e o diretório não podem ter o mesmo nome. Primeiro eu pensei que era um problema do cliente (o Windows lembra os uids antigos da instalação anterior), mas eu tenho os mesmos problemas com o meu telefone (ES File Explorer) que eu nunca usei para se conectar ao meu servidor antes. Mesmo quando eu uso o smbclient para conectar e tentar criar um diretório, recebo o seguinte erro:

smb: \> mkdir test
NT_STATUS_MEDIA_WRITE_PROTECTED making remote directory \test

Eu aumentei o nível de log para 10 e achei isso:

[2016/09/17 09:15:35.902089, 10, pid=24086, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_get_set.c:495(pdb_set_user_sid)
  pdb_set_user_sid: setting user sid S-1-5-21-30211493-2420603996-3020390900-1003
[2016/09/17 09:15:35.902143, 10, pid=24086, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_compat.c:73(pdb_set_user_sid_from_rid)
  pdb_set_user_sid_from_rid:
    setting user sid S-1-5-21-30211493-2420603996-3020390900-1003 from rid 1003
[2016/09/17 09:15:35.902216, 10, pid=24086, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_get_set.c:557(pdb_set_group_sid)
  pdb_set_group_sid: setting group sid S-1-5-21-30211493-2420603996-3020390900-513
[2016/09/17 09:15:35.902291,  4, pid=24086, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:439(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/09/17 09:15:35.902351, 10, pid=24086, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:237(user_ok_token)
  user_ok_token: share Media is ok for unix user htpc
[2016/09/17 09:15:35.902405, 10, pid=24086, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:284(is_share_read_only_for_token)
  is_share_read_only_for_user: share Media is read-write for unix user htpc
[2016/09/17 09:15:35.902508, 10, pid=24086, effective(0, 0), real(0, 0)] ../libcli/security/access_check.c:337(se_file_access_check)
  se_file_access_check: MAX desired = 0x2000000 mapped to 0x80120089
[2016/09/17 09:15:35.902558,  5, pid=24086, effective(0, 0), real(0, 0)] ../source3/smbd/uid.c:163(check_user_share_access)
  falling back to read-only access-evaluation due to security descriptor
    
por Benjamin 11.09.2016 / 13:53

0 respostas

Tags