Por que os arquivos em um compartilhamento montado smbfs são criados com o conjunto de bits executável?

Montei um compartilhamento samba usando o comando smbmount:

$ sudo smbmount \\\\foo\\bar /mnt/bar -o user=tom

Quando crio novos arquivos, eles são criados com o bit executável definido para proprietário, grupo e mundo. Por exemplo

$ touch hello.txt 
$ ls -la hello.txt
-rwxr-xr-x 1 root root 0 Dec  2 12:28 hello.txt

O mesmo arquivo, quando criado em um compartilhamento montado no NFS, configura as permissões corretas sem nenhum conjunto de bits executável.

Por que isso está acontecendo? Como pode ser consertado?

O NFS foi inventado no mundo Unix e, portanto, entende as permissões tradicionais do Unix imediatamente. (A ACL dos sistemas unix modernos é outra questão, mas implementações recentes do NFS devem lidar com eles.)

O Samba foi inventado no mundo IBM / Microsoft PC, para trocar arquivos com sistemas que não tinham permissões além de somente leitura / leitura / gravação. Agora é nativo do Windows. Por padrão, o Samba não transmite permissões Unix. Dependendo da configuração, todos os arquivos são marcados como executáveis ​​(o que é chato) ou todos os arquivos (exceto diretórios) são marcados como não executáveis ​​(o que é chato).

Existem várias extensões para o protocolo Samba / CIFS que o tornam mais adequado ao uso do Unix. Tente ativar as extensões Unix na configuração do servidor:

[global]
unix extensions = yes

Isso parece com o seu problema, intitulado: Arquivos copiados ganham bits de execução no Samba / CIFS .

excerto

Depois de copiar um arquivo com rw-r ----- em um volume montado CIFS, a cópia fica rwxr -----. Então, está ganhando o bit de execução:

Parte inferior da página, colocando map archive = noem /etc/samba/smb.conf:

excerto

  [Global]
  <snip>
  map archive = no
  <snip>

Você pode tentar: mount -t cifs

O Google "mount cifs" para uso, não é difícil de entender, mas você deseja definir opções usando o sinalizador -o:

uid =, gid =, rw, noperm, dir_mask = 0775, file_mask = 0664

Usuário e grupo são IDs, como numérico, não o alias do texto. Essas opções garantirão que você tenha acesso r / w, as permissões serão controladas pela montagem no servidor e, especificamente file_mask=0664, garantirão que seus arquivos não sejam executáveis. Além disso, você poderá trabalhar com seus compartilhamentos de samba como diretórios locais.

Você pode descobrir por que isso está acontecendo na seguinte explicação no site do Samba, na seção Permissões e atributos de arquivo no MS-DOS e Unix :

https://www.samba.org/samba/docs/using_samba/ch08.html

Tem a ver com o mapeamento dos bits System, Hidden e Archive para um sistema de arquivos MS-DOS.

Um sistema de arquivos do MS-DOS não utiliza bits executáveis; portanto, os três bits executáveis ​​no sistema de arquivos Unix são reutilizados para representar os bits System, Hidden e Archive do sistema de arquivos MS-DOS.

Portanto, quando você ls -lexibe as permissões de arquivo no Unix, visualiza as permissões de arquivo adequadas para o MS-DOS (ou Windows), lembrando que os três bits executáveis ​​no Unix representam os bits System, Hidden e Archive do MS-DOS.

No smb.confentanto, você pode desativar esse mapeamento para um compartilhamento com:

map archive = no
map system = no
map hidden = no

e force o modo na criação de arquivos com:

force create mode = 0660

Eu uso um QNAP TS439 - e tive esse problema com os arquivos sendo executáveis.

Embora eu tenha que usar o seguinte no meu /etc/fstabarquivo

//192.168.0.1/audio /media/audio cifs credentials=/home/cheese/.smbcredentials,uid=1000,file_mode=0664,iocharset=utf8  0  0