El permiso para compartir Samba denegó el archivo de escritura del usuario pero aún muestra

Problema muy extraño ...

Samba compartir en remoto:

[javaerpm]
    path = /u/abas/erpm/java
    force user = erpm
    guest ok = yes
    read only = no
    writeable = yes

Montar comando en local usando root:

root@crunchbang:/mnt/abas# mount -t cifs -o username=guest,rw,exec,auto //10.0.0.2/javaerpm ./javaerpm

Root puede leer / escribir / cd sin ningún problema:

root@crunchbang:/mnt/abas# cd javaerpm
root@crunchbang:/mnt/abas/javaerpm# touch test
root@crunchbang:/mnt/abas/javaerpm# ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test
root@crunchbang:/mnt/abas/javaerpm# rm test

Pero si cambio a un usuario normal y hago lo mismo, obtengo esto:

shawn@crunchbang:/mnt/abas/javaerpm$ touch test
touch: cannot touch `test': Permission denied

Puedo lly puedo ver que de todos modos escribió el archivo:

shawn@crunchbang:/mnt/abas/javaerpm$ ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test

Incluso rmno puedo problema:

shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$

He probado diferentes opciones de montaje. uid=501no cambia nada Intenté nounixpero luego no funciona en absoluto y no veo nada con el usuario root o shawn.

_{Nota: Solo estoy adivinando aquí, no soy un samba guru.}

Samba / CIFS, al menos la forma en que lo está utilizando aquí, no reproduce credenciales entre el servidor y el cliente. Debido a la force userdirectiva en el servidor, todas las operaciones se realizan como el usuario erpmen el servidor. Sin embargo, debido a que tanto el cliente como el servidor ejecutan un sistema unix, negociaron automáticamente las extensiones POSIF CIFS . Esto hace que los permisos de Unix parezcan funcionar hasta cierto punto, pero solo en la medida en que el servidor lo permita, y se ha topado con un caso en el que lo que afirman los permisos de Unix y lo que permite el servidor difieren.

Notarás que todos los archivos aparecen como ID de usuario 501. Ese es su uid en el servidor.

Cuando intenta crear o eliminar un archivo, esto requiere permiso de escritura en el directorio. Todos los accesos se asignan a un solo usuario en el servidor, por lo que el permiso de escritura se reduce a si erpmse permite escribir en ese directorio en el servidor. La respuesta es sí.

Cuando ejecuta touch, crea el archivo y luego cambia su hora de modificación. Cambiar el tiempo de modificación de un archivo requiere propiedad, y esto se prueba mediante el código genérico del sistema de archivos, en el lado del cliente.

Si ejecuta strace touch test, notará que la openllamada (que crea el archivo) tiene éxito, entonces la utimesllamada (o más bien en Linux, la utimensatllamada del sistema) no puede establecer los tiempos.

Esto es realmente un poco extraño porque utimes debería tener éxito, ya que lo touchllama con un argumento NULL (que significa "establecer la marca de tiempo a la hora actual"), y se supone que está permitido a cualquier persona que llame que pueda escribir en el archivo, y no solo al propietario le gusta establecer una marca de tiempo arbitraria. Sospecho que en utimensatrealidad está haciendo una verificación basada en permisos y determinando que los permisos dicen que no puede escribir en ese archivo, a pesar de que el sistema de archivos permitiría una operación de escritura independientemente de los permisos reales.

La principal ventaja de las extensiones POSIX de CIFS cuando el lado del servidor se ejecuta con los permisos de un usuario no root es transferir el bit ejecutable y posiblemente la propiedad del grupo. Puede ser menos confuso si asigna la propiedad del usuario a un solo usuario del lado del cliente con la forceuidopción de montaje.