Por que os arquivos em um compartilhamento montado no smbfs são criados com o bit executável configurado?

Question

Eu montei um compartilhamento de samba usando o comando smbmount:

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

Quando eu 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 pelo NFS, configura as permissões corretas sem nenhum bit executável definido.

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

    

Answer 1

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

O Samba foi inventado no mundo do 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 do Unix. Dependendo da configuração, todos os arquivos são marcados como executáveis (o que é irritante) ou todos os arquivos (exceto os diretórios) são marcados como não-executáveis (o que é irritante).

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

[global]
unix extensions = yes

    

Answer 2

Isso soa como o seu problema, intitulado: Os arquivos copiados ganham bit de execução no Samba / CIFS .

trecho

After copying a file with rw-r----- on a CIFS-mounted volume, the copy gets rwxr-----. So it's gaining the execute bit:

Mais abaixo na página, definindo map archive = no em /etc/samba/smb.conf :

trecho

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

    

Answer 3

Você pode tentar: mount -t cifs

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

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

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

    

Answer 4

Você pode descobrir por que isso está acontecendo na explicação a seguir no site do Samba na seção Permissões e Atributos de Arquivo no MS-DOS e Unix :

link

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

Um sistema de arquivos MS-DOS não faz uso de bits executáveis para que os três bits executáveis no sistema de arquivos Unix sejam reutilizados para representar os bits System, Hidden e Archive para o sistema de arquivos do MS-DOS.

Portanto, quando você visualiza as permissões de arquivo usando ls -l no Unix, está visualizando as permissões de arquivo adequadas para o MS-DOS (ou Windows), lembrando que os três bits executáveis no Unix representam o Sistema, Oculto e Arquivo. bits para o MS-DOS.

Em smb.conf , no entanto, você pode desativar esse mapeamento para um compartilhamento com:

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

e forçar o modo na criação de arquivos com:

force create mode = 0660

    

Answer 5

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

Embora eu tenha usado o seguinte no meu arquivo /etc/fstab

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