El SMB ha muerto, viva el CIFS: mount error 13 = Permission denied
Como ya he contado a menudo, en mi ordenador principal uso Debian Testing/Lenny, de forma que al mismo tiempo que puedo probar las últimos versiones de los paquetes, éstos me dan unos sustos espantosos que, a su vez, me sugieren interesantes temas a tratar como en el caso de hoy.
Veréis, yo tengo una línea en el fichero /etc/fstab para que al arrancar me monte automáticamente un directorio compartido por samba de otro sistema:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> [...] //sistemaremoto/supercoco /mnt/sistemaremoto smbfs uid=supercoco,credentials=/etc/sistemaremotosmb 0 0
La opción credentials=/etc/sistemaremotosmb la uso para no tener la contraseña a usar tan visible. Usando un archivo diferente, le puedo poner permisos muy restrictivos. Es lo que aconseja la página de man de mount.smbfs
credentials=<filename>
specifies a file that contains a username and/or password. The for-
mat of the file is:
username = <value>
password = <value>
This is preferred over having passwords in plaintext in a shared
file, such as /etc/fstab. Be sure to protect any credentials file
properly.
Así que mi fichero /etc/sistemaremotosmb tenía este aspecto:
# cat /etc/sistemaremotosmb username = supercoco password = barriosesamo # ll /etc/sistemaremotosmb -rw------- 1 root root 38 2008-02-09 07:44 /etc/sistemaremotosmb
Pues bien, hace unos días actualicé los paquetes de Lenny/Testing y a continuación me encontré con el siguiente problema al intentar montar el directorio compartido:
# mount /mnt/sistemaremotosmb/ mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
Tras buscar un poco, me encontré con el bug #455479 (failed to mount smbfs shares: mount error 13 = Permission denied), enlazado con el #369495 (smbfs: [manual] SMB credential file is not compatible with CIFS mount type) que nos vienen a contar que por la transición de smbfs a cifs, la sintaxis del fichero de credenciales ya no es la misma y que no debemos poner espacios después del = para evitar problemas con contraseñas que puedan empezar con un espacio en blanco. La nueva sintaxis, que podemos leer en la página de man de mount.cifs es:
credentials=filename
specifies a file that contains a username and/or password. The for-
mat of the file is:
username=value
password=value
This is preferred over having passwords in plaintext in a shared
file, such as /etc/fstab. Be sure to protect any credentials file
properly.
Por tanto, tras quitar los espacios ya he podido volver a montar el directorio remoto.
Pero, por otro lado, ¿qué es eso de la transición de smbfs a cifs?
Para empezar, es interesante saber que CIFS es un nuevo nombre que Microsoft quiso darle al protocolo SMB en 1996, pero a nivel de Linux, ¿qué diferencia hay entre mount.cifs y mount.smbfs/smbmount?
En el propio kernel de Linux podemos encontrar la respuesta si navegamos por la ayuda del make menuconfig:
Para SMB leemos que es el protocolo de los Windows 9x y de NT:
CONFIG_SMB_FS: SMB (Server Message Block) is the protocol Windows for Workgroups (WfW), Windows 95/98, Windows NT and OS/2 Lan Manager use to share files and printers over local networks.
Para CIFS leemos que es el protocolo que usan los Windows modernos, así como que Samba proporciona un excelente soporte de este protocolo como servidor:
CONFIG_CIFS: This is the client VFS module for the Common Internet File System (CIFS) protocol which is the successor to the Server Message Block (SMB) protocol, the native file sharing mechanism for most early PC operating systems. The CIFS protocol is fully supported by file servers such as Windows 2000 (including Windows 2003, NT 4 and Windows XP) as well by Samba (which provides excellent CIFS server support for Linux and many other operating systems). Limited support for OS/2 and Windows ME and similar servers is provided as well.
Vía Thou Shalt Not Use Smbfs (“No usarás smbfs”) ¡Pásate a Cifs! llego a entrada Thou Shalt Not Use Smbfs de la página de Christian Perrier, uno de los desarrolladores del paquete samba de Debian, en la que nos dice muy claramente que no debemos usar más smbfs:
I’m afraid that people who experience this bug just deserve what they got. Smbfs is bloody deprecated for years in favor of the cifs filesystem (samba upstream QA work never includes checks for smbfs stuff). CIFS Userland utilities are provided in the smbfs Debian package so the switch is mostly a matter of a few minutes work and manpage reading (some options might differ).
We should have told this earlier, probably, sorry for this. But it is now time to say it and even shoult it: if you’re using smbfs, you’re shooting in your own foot.
Por tanto, parece sensato comenzar a usar mount.cifs y “mount -t cifs” en lugar de smbmount, mount.smbfs y “mount -t smbfs“, pero me imagino que muchos no lo estábamos haciendo simplemente por la fuerza de la costumbre y por desconocimiento de los grandes beneficios de usar CIFS sobre SMB.
Pero parece ser que los desarrolladores de Debian, hartos de estos problemas, han decidido eliminar radicalmente el SMB. Para ello, como podemos ver en el changelog de la última versión de samba distribuido con la Testing/Lenny, han decidido suprimir las utilidades de smbfs:
* Don’t build the userspace tools for the deprecated smbfs kernel driver
anymore; instead, use a shell wrapper around mount.cifs that translates
option names between the smbfs and cifs drivers.
Closes: #169624, #256637, #265468, #289179, #305210, #410075;
LP: #29413Tue, 04 Dec 2007 18:35:29 -0800
Y, efectivamente, en una Testing/Lenny actualizada podemos ver que smbmount es un enlace simbólico a mount.smbfs (antes era al revés):
# ll /sbin/mount.smbfs -rwxr-xr-x 1 root root 2538 2008-01-25 16:26 /sbin/mount.smbfs* # ll /usr/bin/smbmount lrwxrwxrwx 1 root root 17 2008-01-30 21:45 /usr/bin/smbmount -> /sbin/mount.smbfs*
y que mount.smbfs ahora es un wrapper script cuya última línea es, precisamente, una llamada a mount.cifs:
# file /sbin/mount.smbfs
/sbin/mount.smbfs: Bourne-Again shell script text executable
# tail -1 /sbin/mount.smbfs
exec /sbin/mount.cifs "${args[@]}"
Así que ya saben, amiguitos, si quieren que los Reyes Magos les traigan muchas cosas el año que viene pórtense bien y ¡no usen el smbfs nunca más!
:wq
Muy interesante.
A veces es preferible cortar por lo sano radicalmente porque si no la gente se apalanca y siguen haciendo las cosas como se hacían hace 20 años. Todo por la retrocompatibilidad…hasta cierto punto.
Hace tiempo que utilizo cifs ante smbfs y la verdad que se nota una mejoría en todos los sentidos, estabilidad, velocidad y etc…
Por ejemplo en smbfs cuando el origen se perdía, el sistema de archivos se degradaba y tenía que volver a montar con otro nombre la unidad, quedando el anterior punto de montaje en estado ?… y algunas cosas más raras, cifs cuando el volumen está de nuevo “montable” sigue funcionando perfectamente.
Así que recomiendo a todo el mundo a pasarse al mundo cifs, y así lo uso yo.
-o username=algo,password=algo,dir_mode=0777,file_mode=0777,lfs,iocharset=utf8
Suelen ser una buenas opciones para soporte de ficheros “grandes” y poder ver caracteres raros cuando montemos carpetas en windows xp.
Un saludo a todos y ánimo a cambiar a mejor.
Muy interesante la distinción entre SMB y CIFS.
Pero ahora la pregunta obvia es: ¿sirve /sbin/mount.cifs para acceder a recursos de los viejos Win9x, o sólo sirve para recursos compratidos de Win2k y superiores?. O dicho de otra forma, ¿se elimina la posibilidad de acceder desde linux a una máquina con Win9x y viceversa, o por el contrario el soporte para SMB sigue allí y sólo se cambia el programa invocado desde mount?.
¿Se nota mucho que tengo todavía algún Win9x en funcionamiento? ;-D
Saludos
En hpux de hecho siempre se usa cifs, en vez de samba. Ahora para linux me lo apunto tambien
Felinux, personalmente no te recomiendo que pongas el user/pass en el fstab ya todos los usuarios tienen permisos de lectura sobre ese fichero con lo cual, la clave está a la vista de cualquiera. Lo que nos explica supercoco es “el método correcto” de hacerlo.
Tengo unos linux que se me quedan colgados los filesystems cuando se pierde la comunicación con un servidor windows, pese a que están montandos como soft. ¿Será esta la solución? Supercoco, como sea así te debo unas cañas
Muy interesante. Había leído algo de CIFS y lo tenía en la cola de tareas pendientes de probar.
Lo que nos cuentas en el artículo es de cara a montar un recurso compartido, pero qué ocurre con la compartición de archivos por medio de samba?. Es decir, configurar una máquina linux para compartir por medio de samba un filesystem a una máquina windows. Esto también ha cambiado?.
Saludos, Iván.
@Osqui Gracias, me alegro de que te haya parecido interesante. Y tienes razón, lo bueno del mundo Linux es que a menudo se corta radicalmente y se decide no cargar con pesados lastres de compatibilidad hacia atrás.
@Felinux Pues muchas gracias por tu aportación. Gracias a ella, aún encontramos más motivo para usar CIFS.
@AlBundy El CIFS también soportará montar unidades de los Windows 9x y se supone que con menos bugs y problemas. Si no, no se hubieran atrevido a eliminarlo de Debian… Además, si te fijas, Christian Perrier dice que el código de smbfs ya no se prueba como el de cifs:
@RuBiCK Sí, yo también estoy de acuerdo con que no es buena idea poner el password en el comando. Si está en el
/etc/fstab, es visible, y si es el línea de comandos, cualquiera que pase puede verte el terminal o curiosear entre el histórico de la shell.Sobre tus linux que se quedan colgados, ya nos contarás si es que están usando smbfs
.
@Iván Me alegro de que te haya parecido interesante. En el servidor de Samba no hay que cambiar nada. El proceso es el mismo y él contesta con un protocolo u otro según el cliente que se use.
Muchas gracias por la aclaración Super coco. Lo cambiaré en casa para probar.
Saludos, Iván.
No si yo no pongo eso en el fstab, nunca he dicho que lo ponga, lo tengo en un script que lo ejecuto a mano y tal uis, ya les dije mi secreto, tendré que matarlos a todos JAJAJAJJA.
A parte, suele ser para montar unidades de red en un windows, así que supongo que será mas fácil partir por medio a los windows que intentar darle matarile a mi maquina linux digo yo.
Resumiendo, que CIFS mejor que SMB en la práctica…
Un saludo y ver si aparece otro documento sobre VIA EPIA o similares, que son muy lectivos y entretenidos.
@Felinux Sobre una nueva entrada sobre las VIA EPIA, no sabría qué más contar de momento… Creo que ya conté todo lo que me parecía interesante
¿Se te ocurre algo? 
muy bonito aparentemente lo de cifs… y cortar con los antiguos y obsoletos windows, … peeero resulta que la cosa no es tan bonita como la pintan. Que funciona genial y todo eso. Los problemas vienen con que resulta que no es compatible cifs con un servidor samba 2.xx. Pues nada nos actualizamos el samba 2 (servidor en máquina linux) por el tres y asunto solucionado parece ¡pues no!, no es tan sencillo, hay un montón de pequeños dispositivos tipo nas, que usan samba 2, imposible poner samba 3 en principio. Adiós a nuestras pequeñas joyas de discos duros en red.
muy mal pensado la verdad la incompatibilidad de cifs, cuando una máquina moderna p.ej winxp es compatible aun con samba versión 2… , esto supone un retroceso para pensar en una migración a linux, curiosamente provocado por linux en este caso un nas con samba 2.
traté de cambiar uno de estos dispositivos a samba 3, pero resulta que ocupa una barbaridad (tal vez 30 megas), para la pequeña memoria que trae el dispositivo en cuestión, un asus wl500g-p con openwrt (8 megas para instalar aplicaciones).. Repito muy mala mosca me está dando esto del cifs por muy bien que funcione.
@danitool Es curioso lo que comentas. Yo diría que “samba 3″ debería de funcionar sin problemas con “samba 2″. No creo que los desarrolladores sean tan drásticos. Lo único que han hecho ha sido quitar la utilidad “
mount.smbfs” que sólo era capaz de usar el viejo estándar de Microsoft para poner en su lugar el “mount.cifs” que debería de ser capaz de montar lo viejo y lo nuevo.A día de hoy no soy capaz de hacer lectura y escritura con un montaje mount.cifs, ni mount.smbfs en ubuntu hardy, de comparticiones en un servidor samba 2,
Si hay una forma no la he encontrado, hasta entonces responderé que sí, han sido demasiado drásticos en cuanto al cambio que intentan hacer a cifs.
saludos
cifs apesta
mount.smbfs Vs mount.cifs… que bueno que se trate de mejorar las herramientas que utilizamos, y por lo que he leído pues “cifs” a remplazado a smbfs en los sistemas operativos debian y sus derivadas distribuciones incluyendo ubuntu 8.4 LinuxMint entre otros. y eso es bueno.. pero el asunto es tengo problemas con el mount.cifs.
Hace poco tenia mandriva 2007 el cual incluye todavia mount.smbfs, lo usaba para conectar a Ubuntu Server 7.10 via samba y no habia problemas podia entras a todas las carpetas y ficheros compartidos de acuerdo a los permisos establecidos. El echo es que hace dos semanas me instale ubuntu 8.4 y ya trae por defecto el cifs en hice el montaje de acuerdo a lo siguiente:
mount.cifs //servidor/compartido /mnt/montaje -o user=usuario,password=contrase,iocharset=utf8,rw,
y ya probe las opciones que nos dice FELINUX:
mount.cifs //servidor/compartido /mnt/montaje -o user=usuario,password=contrase,dir_mode=0777,file_mode=0777,lfs,iocharset=utf8
Mi problema es que al montar y ejecutar El FoxPro Emulado via Dosemu y ejecutarlo dentro algunas carpetas no puedo crear un espacio de trabajo porque me pone permiso denegado, pero en otras si puedo ejecutarlo de 15 carpetas puedo como en 4 solamente y ya cheque permisos de carpetas de usuarios de grupo y nada y ya me estoy chocando ya no se que mas hacer, ya cheque en otra maquina con mandriva 2007 y no hay problema alguno..Si alguien me puede ayudar a desenmarañar este misterio de las carpetas se lo agradecere.. gracias.
Hace unos meses actualizamos a samba version 3. He observado que a veces tengo ficheros nuevos con el nombre cifsxxxxx siendo xxxxx caracteres que a mi entender son aleatorios (letras y números).
Estos ficheros con nombres extraños cuando los edito veo que son ficheros que debían de haberse llamado con otro nombre. Es algo así como que no los ha copiado bien ¿?
Tanto el cliente (el que genera los ficheros) como el servidor tienen la misma versión de samba.
Alguna idea de a qué es debido y como puedo solventarlo?
Muchas gracias