Montaje de Windows Share usando SMB 2.1 o superior

12

Estoy intentando montar un recurso compartido SMB alojado en Windows (CIFS) usando Ubuntu 12.04 (usando el kernel 3.13.0-117-generic). El montaje con SMB1 funciona, pero eso no es aceptable, en su lugar debemos montar con SMB2.1 o superior.

A continuación se muestra el resultado de mis intentos de hacer esto pasando el argumento ver =

root@----:/# mount -t cifs //SERVER/smbtest /mnt/smbtest --verbose -o ver=2.1,user=administrator
Password:
mount.cifs kernel mount options: 
ip=10.16.0.40,unc=\\server.domain.net\smbtest,ver=2.1,ver=1,user=administrator,pass=********
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Como puede ver, hay dos argumentos ver en las opciones de montaje del núcleo mount.cifs, el que especifiqué y el predeterminado (1). Esto sucede si especifico algo diferente a 1 o 1.0 para ver.

La versión 5.1 de cifs-utils está instalada, y cifs.ko está en la versión 2.02. Desde la página de estado del núcleo SMB3 en la wiki de Samba, https://wiki.samba.org/index.php/SMB3_kernel_status ,

"The minimum version for use of the Linux kernel SMB3 support is kernel version 3.12 (or backport of cifs.ko module version 2.02 or later) but kernel version 3.18 or later (or equivalent, ie cifs module version 2.04 or later) is recommended for best SMB3 support."

¿Alguien puede ayudarme a tomar el camino correcto aquí? Debo estar perdiendo algo. ¿Qué otros métodos están disponibles para forzar conexiones SMB2 +? Esta es mi primera publicación aquí, y traté de ser breve, si me perdí algo, avíseme y agregaré la información a mi publicación.

Por lo que puedo decir, esto debería funcionar, aunque no me sorprendería si he entendido mal algo y SMB2 + no es compatible.

Gracias

EDITAR: Entiendo que 12.04 es EOL. Actualizaré esta publicación mañana con la información relevante para 14.04, que tiene el mismo problema. Si alguien puede responder re: 12.04, eso todavía sería apreciado.

security file-sharing cifs Oliver Vollmer
fuente
1
Esto es particularmente relevante en lugar de los objetivos de explotación de wannacry ransom ware SMB1
Jeff Puckett
Si tiene el nombre del dispositivo (por ejemplo, foo) pero no su ipaddr: nmblookup foo
phreed

Respuestas:

8

Si uso ver, realmente escribe "Argumento inválido" pero man mount.cifs dice que el nombre de la opción es "vers", no "ver".

       vers=
       SMB protocol version. Allowed values are:

       ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

       ·   2.0 - The SMBv2.002 protocol. This was initially introduced in
           Windows Vista Service Pack 1, and Windows Server 2008. Note
           that the initial release version of Windows Vista spoke a
           slightly different dialect (2.000) that is not supported....

me funciona en Mint 18.1:

mount -t cifs //192.168.1.1/public /home/user/Desktop/share --verbose -o vers=2.1,user=winuser
polizón
fuente
1

Encontré las opciones disponibles en mi página de manual local. Verifique esto en su propia máquina para ver qué es compatible. Una vez en la página de manual, escriba /vers=para encontrar ese argumento rápidamente.

man mount.cifs

Luego monté mi parte de la siguiente manera:

sudo mount -t cifs //nas/homes/mike /media/mike/nashome -o vers=3.11,credentials=/home/mike/.ssh/.smb_nas

Esto requirió un archivo de credenciales con el siguiente contenido en /home/mike/.ssh/.smb_nas, por lo que no necesito ingresar mi contraseña en el comando (lo que hace que se almacene en su historial de comandos en texto sin formato) o en el aviso (una molestia).

username=mike
password=[REAL PASSWORD]
domain=WORKGROUP

Estoy montando desde un Synology NAS que admite SMB versión 3.11. Tendría que verificar su versión de Windows (o lo que sea que aloje archivos a través de CIFS / SMB) para ver qué admite en el lado del servidor.

mightypile
fuente
1

Por extraño que parezca, si la computadora compartida no está en esa dirección IP, es posible que obtenga este mismo error. Un cambio en el DHCP "movió" nuestro NAS y esa fue la raíz de mi problema. Una vez que el recurso compartido volvió a la IP correcta, los errores se detuvieron.

Chris K
fuente