Montando el acceso SMB al servidor de ficheros
Pues ahora que ya tengo el equipo de virtualización activo y estable de nuevo, y puedo volver a acceder a mi máquina de producción, tendré que facilitarme a mi mismo su uso.
Tengo mis dos usuarios, samquejo , el que uso siempre para tareas ordinarias, y YoVirtualizador que se pasa de vez en cuando y es el de los tutoriales (siempre que me acuerdo) y resto de cosas relacionadas con el proyecto.
Pues eso, que andaba con mis temas y digo… ¿no es siempre caótico esto?
Tiene utilidad para cualquier usuario que está transicionando a linux, o que por algún motivo tiene redes mixtas, o que no quiere, sabe, necesita, otro protocolo más allá del SMB básico.
¿Y el servidor?
Pues el servidor ya lo contaré pero exporto un mismo recurso por samba, nfs, sshfs y sftp.
Bueno vale, es un poco trampa. Por ssh no exporto nada. Es inherente al protocolo.
El problema original
Lejos de lo de es que no me van las credenciales o es que no tengo permisos lo que me pasó como punto de inicio es que solamente root podía montar un FS.
Pues a buscar, y como siempre, el principio fué la línea de comandos. Y como no, man mount.
De su lectura pude destilar una cosa. Que necesito leer más sobre smbclient.
Puestos a ello, este ya lo conocía así que con una diagnosis inicial, quiero ver que comparte mi servidor, así que smbclient --list=herodoto.labsam.local para luego ejecutar el montaje de el mi caso Proyectos, con mount -t cifs smb://herodoto.labsam.local/Proyectos ./remoto.
Bien. La salida de smbclient me informa de lo que hay disponible, y que las credenciales son válidas. Y que SMB1 está deshabilitado.
Pero el montaje no funciona como espero.
This program is not installed setuid root - "user" CIFS mounts not supported.
Un error bastante feo. No aporta información al estilo de lo que esperaría un usuario pero si para un administrador, por tanto… ¿Debe todo usuario de un sistema linux ser también administrador?
¿Debe todo usuario de un sistema linux ser también administrador?
El paquete de mount, es de los paquetes base de cada distribución, pero los protocolos no, por lo que cada paquete de utilidades para un protocolo añade la funcionalidad adicional de dicho protocolo.
En el caso de samba/cifs, el añadido es mount.cifs y se localiza en /sbin por defecto.
Pero claro, el instalador de paquetes no sabe de las intenciones de quien instala, por tanto deja los ficheros en su sitio, y con los valores por defecto.
Fijando el setuid
En este caso, setuid es una característica del sistema de ficheros que permite que un usuario sin privilegios administrativos realize acciones con binarios que originalmente son de sistema.
Es decir, que pueda ejecutar acciones que de otra forma deberían ser ejecutadas con sudo.
Para ello, como sabemos que la ubicación es /sbin/mount.cifs lo que harémos será cambiar sus permisos con chmod u+s /sbin/mount.cifs y verificamos que han quedado configurados como -rwsr-xr-x. para permitir el uso sin elevación.
Haciendo permanentes los montajes
Ya sabemos que muchos usuarios tienen manía a la línea de comandos.
¿Debe todo usuario de un sistema linux ser también administrador?
Así que facilitar el uso de los recursos se convierte en una prioridad.
Lo primero es gestionar las credenciales, que en nuestro caso será una cosa muy simple, pero que se puede complicar enormemente.
Basta con crear un fichero oculto, de esos que empiezan por ., como en el ejemplo, y con los permisos de lectura y escritura solo para el propietario.
El caso es que exista un fichero tal que -rwsr-xr-x. 542 samquejo samquejo 64320 sep 16 00:03 .credentials que contiene el usuario y la contraseña tal como se ve en el ejemplo.
username=usuario
password=contraseña
La autenticación, ante la duda, mejor usar kerberos si es posible al estilo usuario@realm en lugar del esquema NTLM del tipo maquina\usuario o dominio\usuario. Ojo, que funciona, pero me ha dado problemas.
El fichero /etc/fstab contiene las definiciones de los diferentes puntos de montaje y uno de ellos puede ser este, en red.
Así que añadiendo una línea por usuario con los parámetros de noauto y la configuración de acceso a los ficheros de credenciales.
//herodoto.labsam.local/Proyectos /home/samquejo/remoto cifs credentials=/home/samquejo/.smbcredentials,iocharset=utf8,cifsacl,noauto,user 0 0
//herodoto.labsam.local/Proyectos /home/yovirtualizador/remoto cifs credentials=/home/yovirtualizador/.smbcredentials,iocharset=utf8,cifsacl,noauto,user 0 0
Con esas dos líneas, cubiertos quedan los dos usuarios de este equipo, y con ello, el acceso al FS controlado por identidad y bajo demanda.
¿Debe todo usuario de un sistema linux ser también administrador?
Añadiendo y ampliando
Pues sucede que a veces, tras una actualización, alguna configuración o algún permiso se rompe.
Y esto ha sido el caso, que en algún momento he actualizado a fedora 35 esta máquina, y el cambio de paquete ha decidido que había que restaurar los permisos por su cuenta, y volvemos a lo mismo. Si ese mensaje lo ve un usuario, pues eso.
Que toca reconfigurar de nuevo.
Y nada más.
Con esto queda documentado el proceso de montaje de un FS de un cliente linux tradicional.
YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://wt.territoriolinux.es/rss/short.xml
Sin más, os dejo los enlaces:
Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlace de afiliados de amazon: https://amzn.to/3gX3HmK
Enlace de referidos de la Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70
