¿Por qué los archivos en un recurso compartido montado en smbfs se crean con un conjunto de bits ejecutable?

Monté un recurso compartido de samba usando el comando smbmount:

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

Cuando creo nuevos archivos, se crean con el conjunto de bits ejecutable para el propietario, el grupo y el mundo. Por ej.

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

El mismo archivo cuando se crea en un recurso compartido montado en NFS configura los permisos correctos sin ningún conjunto de bits ejecutable.

¿Por qué está pasando esto? ¿Cómo se puede arreglar?

NFS se inventó en el mundo de Unix y, por lo tanto, comprende los permisos tradicionales de Unix listos para usar. (La ACL de los sistemas Unix modernos es otra cuestión, pero las implementaciones recientes de NFS deberían hacer frente a ellos).

Samba se inventó en el mundo de las PC de IBM / Microsoft, para intercambiar archivos con sistemas que no tenían permisos más allá de solo lectura / lectura-escritura. Ahora es nativo de Windows. Por defecto, Samba no transmite permisos Unix. Dependiendo de la configuración, todos los archivos están marcados como ejecutables (lo cual es molesto) o todos los archivos (excepto los directorios) están marcados como no ejecutables (lo cual es molesto).

Existen varias extensiones para el protocolo Samba / CIFS que lo hacen más adecuado para el uso de Unix. Intente habilitar las extensiones de Unix en la configuración del servidor:

[global]
unix extensions = yes

Esto suena como su problema, titulado: Los archivos copiados ganan bit de ejecución en Samba / CIFS .

extracto

Después de copiar un archivo con rw-r ----- en un volumen montado en CIFS, la copia obtiene rwxr -----. Entonces está ganando el bit de ejecución:

Más abajo en la página, el establecimiento map archive = node /etc/samba/smb.conf:

extracto

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

Puedes probar: mount -t cifs

Google "monta cifs" para su uso, no es difícil de entender, pero querrá configurar las opciones con el indicador -o:

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

El usuario y el grupo son id's, como en numérico no el alias de texto. Estas opciones asegurarán que usted tenga acceso r / w, los permisos están controlados por el montaje en el servidor y específicamente file_mask=0664garantizarán que sus archivos no sean ejecutables. Además de esto, podrá trabajar con sus recursos compartidos de samba como directorios locales.

Puede averiguar por qué sucede esto en la siguiente explicación en el sitio web de Samba en la sección Permisos y atributos de archivos en MS-DOS y la sección Unix :

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

Tiene que ver con el mapeo de los bits del Sistema, Oculto y de Archivo para un sistema de archivos MS-DOS.

Un sistema de archivos MS-DOS no utiliza bits ejecutables, por lo que los tres bits ejecutables en el sistema de archivos Unix se reutilizan para representar los bits de sistema, oculto y de archivo para el sistema de archivos MS-DOS.

Por lo tanto, cuando ve los permisos de archivo con ls -lUnix, está viendo los permisos de archivo adecuados para MS-DOS (o Windows) teniendo en cuenta que los tres bits ejecutables en Unix representan los bits de Sistema, Oculto y de Archivo para MS-DOS.

En smb.confSin embargo, puede activar esta asignación fuera de una parte con:

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

y forzar el modo en la creación de archivos con:

force create mode = 0660

Utilizo un QNAP TS439 y tuve este problema con los archivos ejecutables.

Aunque tuve que usar lo siguiente en mi /etc/fstabarchivo

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