Defina umask, defina permissões e defina ACL, mas o SAMBA não está usando essas?

Question

Estou executando no Ubuntu Server 12.04. Eu tenho uma pasta chamada Music e quero que as permissões de pasta padrão sejam 775 e o arquivo padrão seja 664.

Defina as permissões padrão na pasta Música como 775.

Eu configurei o ACL para usar essas permissões padrão também:

# file: Music
# owner: kris
# group: kris
# flags: ss-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

Eu também alterei a umask padrão para minha conta de usuário, kris, para 002 no perfil.

O novo arquivo / pasta agora não deve usar essas permissões ao gravar no compartilhamento do Samba? A ACL deve trabalhar com o Samba a partir do que posso reunir.

Atualmente, se eu escrevo para essa pasta usando meu mac, as pastas estão recebendo 755 e arquivos 644. Eu tenho outro aplicativo no meu mac chamado GoodSync que é capaz de sincronizar um diretório local no meu mac para um compartilhamento de samba de rede, mas essas permissões são ainda piores. arquivos estão sendo gravados como 700 usando esse programa.

Parece que o Samba está permitindo que o host / programa determine as permissões de pasta / arquivo.

Quais alterações eu preciso fazer para forçar as permissões que eu quero, independentemente do que o host tenta escrever no servidor?

    

Answer 1

Finalmente percebi isso.

Você precisa modificar o arquivo /etc/samba/smb.conf. Para o meu compartilhamento de música, adicionei as seguintes opções:

create mask = 664
force create mode = 664
security mask = 664
force security mode = 664
directory mask = 2775
force directory mode = 2775
directory security mask = 2775
force directory security mode = 2775

Não sei qual deles realmente resolveu o problema, mas está escrevendo as permissões corretas agora ao compartilhar via Samba. Eu acho que é o comando "force" que está sendo usado desde que o Mac está tentando forçar suas próprias permissões no compartilhamento (e agora o Ubuntu está forçando suas próprias permissões ao invés de aceitar o meu Mac). Espero que isso ajude alguém!

    

Answer 2

SAMBA / UMASK

Executando o Ubuntu 14.04, samba versão 4.1.6-Ubuntu. Eu estava anteriormente executando o Fedora 16 / samba3 e tudo estava OK. Com o Ubuntu / samba4, não consegui fazer com que o Samba definisse o bit de gravação de grupo nos diretórios.

parâmetros smb.conf (para teste) incluídos:

create mask = 700             # The file AND mask  
force create mode = 775       # The file OR mask  
directory mask = 700          # Directory AND mask  
force directory mode = 777    # Directory OR mask  

Do cliente Windows 7, eu poderia criar arquivos com o modo = 775, mas os diretórios criados sempre tinham o modo 755.

O problema é com o padrão "UMASK 022" no meu login pessoal, que eu uso para acessar os diretórios compartilhados. Editou /etc/login.defs e alterou "UMASK 022" para " UMASK 002 ". Os diretórios reinicializados e agora criados a partir do cliente Windows 7 têm mode = 775. Eu não acredito que este tenha sido o mesmo comportamento da minha configuração anterior (Fedora / Samba3).

Curiosamente, o parâmetro smb.conf "inherit permissions = yes" funcionou. Este parâmetro substitui os parâmetros anteriores. Com o diretório pai tendo mode = 2777, os subdiretórios criados tinham mode = 766 (os bits de execução não eram definidos) e os arquivos tinham mode = 755 (os bits de gravação de grupo / convidado não estavam definidos).

A interação e a interdependência do Samba / UMASK devem ser documentadas.

    

Answer 3

As seguintes entradas funcionaram para mim:

force security mode = 664
force directory security mode = 775

    

Answer 4

Uma nota simples. Procure o parâmetro "obey pam restrictions". Por padrão, é OFF, NO ou FALSE, mas deve ser ativado explicitamente, e o umask entrará em vigor! Eu perdi cerca de uma semana, tentando descobrir por que meus arquivos criados com 744 permissões regadless de força criar modo 666 ou 777 ... Problema estava neste parâmetro ligado, e não me lembro por que fiz isso. Desligá-lo resolveu o problema rw-vs-ro