no se puede usar mount.cifs: error de montaje (2): no existe tal archivo o directorio

17

Se encuentra que el comando mount.cifs no puede ejecutarse en un sistema gentoo con systemd

ae429-1105 etc # mount -t cifs //file.abc.edu.au/user /home/directory/path -o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Se ha confirmado la existencia y accesibilidad del punto de montaje / home / directorio / ruta y el archivo de credencial / etc / user . También se han habilitado los módulos y servicios relevantes, es decir,

 ae429-1105 etc # lsmod |egrep 'fuse|cifs'
 fuse                   72589  5 
 cifs                  312131  0

y

ae429-1105 etc # systemctl -t service -a |grep Samba
nmbd.service                         loaded active   running Samba NetBIOS                     name server
smbd.service                         loaded active   running Samba SMB/CIFS     server
winbindd.service                     loaded inactive dead    Samba Winbind daemon

Este problema ha sido identificado por muchos usuarios, por ejemplo , un ejemplo . TAMBIÉN TENGA EN CUENTA que el mismo comando ejecutado en mi sistema Ubuntu / debian puede montarse con éxito.

Otra información en la máquina problemática:

ae429-1105 etc # mount.cifs --version
mount.cifs version: 6.1

la versión de mount.cifs instalada en debian / ubuntu es 6.0

mount 
— Chenming Zhang
fuente
/home/directory/pathes seguro que existe en el entorno de Gentoo? Es extraño que no lo menciones, ya que esta es la primera pregunta obvia que surge.
— Hauke ​​Laging
Sí, he confirmado la existencia y accesibilidad del punto de montaje / inicio / directorio / ruta .
— Chenming Zhang
Debe agregar esta información a la pregunta para que otros lectores no necesiten leer los comentarios para obtenerla.
— Hauke ​​Laging

Respuestas:

8

Es posible que deba proporcionar la opción vers = al comando de montaje para forzar la versión 3.0 si está intentando montar un recurso compartido desde una versión más reciente de Windows. Uno de nuestros servidores de archivos se actualizó recientemente a 2012R2 y fue entonces cuando mi montaje dejó de funcionar. Establecerlo en vers = 3.0 solucionó el problema. Como la mayoría de los errores de Samba / CIFS, el mensaje "No existe tal archivo o directorio" no es de mucha ayuda.

Como ejemplo:

# mount -t cifs //win2012r2/someshare -o cred=/home/foo/.cifs_user, vers=3.0 /mnt/tmp

.. donde tengo mi dominio, nombre de usuario y contraseña contenidos en el archivo .cifs_user.

Aparentemente, smbmount usa una versión más nueva del protocolo SMB por defecto, ya que funcionó sin problemas ni ninguna opción especial.

Observe a continuación que la versión de protocolo predeterminada es 1.0.

Desde la página de manual de mount.cifs:

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.

           ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

           ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.
— foobrew
fuente
Tuve un problema similar con el indicador "nounix" que no debe ser compatible con v1.0. Cambiar a la v2.0 (la más reciente disponible para mí) solucionó el problema. También los permisos de archivo son más sensibles con vers = 2.0 (755 en lugar de 777)
— cxrodgers
2
¡Muchas gracias por la solución relacionada con la opción vers =! Funcionó para mí, solo al revés ... Después de actualizar el salto de uso abierto de la versión 42.3 a 15.1, una entrada fstab para montar una unidad de red, que funcionó, dejó de funcionar en 15.1. Utilicé la opción vers = 1.0 y adivina qué ... Probablemente Leap 15.1 utiliza una versión más nueva del protocolo SMB que no pudo encontrar el directorio remoto.
— John
La conexión a un recurso compartido alojado en Windows Server 2003 desde Ubuntu 19.04 me falló continuamente hasta que agregué vers = 1.0 a mi lista de opciones. ¡Gracias!
— user8675309
Funcionó para mí, EXCEPTO: tuve que indicar la versión DOS vers=2.0para montar los recursos compartidos de samba de mi sistema NAS de 5 años ... con 3.0 obtuve el error anterior.
— Frank Nocke
etc/fstabusuarios: simplemente ponga eso vers=3.0(o 2.0 ...) correcto y sin espacio antes que sus otras opciones, es decirvers=2.0,guest,uid=1000,iocharset…
— Frank Nocke,
5

¿Puedes usar la nodfsopción? es decir, para su -oentrada de opciones, pase la entrada de la siguiente manera.

-o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777,nodfs

es decir, adjunto ,nodfs

Funcionó para mi.

— Sanath
fuente
¡gracias! Intenté todas las otras sugerencias primero, pero necesitaba esto en fedora30 donde no lo necesitaba antes
— Jens Timmerman
2

Es posible que deba cambiar el secparámetro: esta configuración lo hizo funcionar en mi configuración:

mount.cifs ... -o sec=ntlm

Extracto relevante de man mount.cifs:

sec=Modo de seguridad. Los valores permitidos son:

  • none - intento de conexión como usuario nulo (sin nombre)
  • krb5 - Utilice la autenticación Kerberos versión 5
  • krb5i - Use la autenticación Kerberos y habilite forzosamente la firma de paquetes
  • ntlm - Use el hash de contraseña NTLM
  • ntlmi - Use el hash de contraseña NTLM y fuerce la firma de paquetes
  • ntlmv2 - Use el hash de contraseña NTLMv2
  • ntlmv2i - Use el hash de contraseña NTLMv2 y fuerce la firma de paquetes
  • ntlmssp - Use el hash de contraseña NTLMv2 encapsulado en un mensaje NTLMSSP sin procesar

  • ntlmsspi - Use el hash de contraseña NTLMv2 encapsulado en un mensaje NTLMSSP sin procesar y fuerce la firma de paquetes

    El valor predeterminado en las versiones principales del kernel anterior a v3.8 era sec=ntlm. En v3.8, el valor predeterminado se cambió a sec=ntlmssp.

    Si el servidor requiere la firma durante la negociación del protocolo, entonces puede habilitarse automáticamente. La firma de paquetes también se puede habilitar automáticamente si está habilitada en /proc/fs/cifs/SecurityFlags.

— Benoit Duffez
fuente
1

Me encontré con esto en Ubuntu 18.04. El problema era que necesitaba el paquete keyutils para realizar la autenticación Kerberos ( sec=krb5opción de montaje), que no se instaló junto con cifs-utils (que proporcionaba mount.cifs). No estoy seguro de si el nombre del paquete es el mismo en Gentoo o no. (Gracias a https://forum.zentyal.org/index.php?topic=18601.0 por la solución).

— Chris
fuente
1

Intente instalar el paquete keyutils:

sudo apt-get install keyutils

No estoy seguro exactamente por qué esto ayuda, tal vez alguien más tenga una respuesta aquí. Pero al menos funcionó para mí: con keyutils el montaje cifs funcionó bien.

— Klaus
fuente
Agregue información sobre cómo esto resolvería el problema indicado en la pregunta. ¿Qué hace este paquete y cómo figura en el problema planteado por el OP?
— Haxiel
Buena pregunta. No estoy seguro de cómo ayuda el paquete keyutils. En mi caso, al menos esto es lo que funcionó. Después de instalar keyutils, mi montaje cifs funcionó bien, mientras que antes recibí el mensaje de error "error de montaje (2): No existe tal archivo o directorio", como en el OP.
— Klaus
Duplicado de esta otra respuesta
— roaima
1

Quería agregar otra fuente de este problema que encontré hoy. Una vez que cambie la identificación de usuario de un usuario de Unix, es posible que el usuario smb creado a través de smbpasswd ya no pueda autenticarse para el recurso compartido de samba, lo que da como resultado el mismo error.

Entonces, si cambió su identificación de usuario de Unix a través de, usermod -u 1000 my_userentonces puede tener problemas. La solución para mí fue eliminar y volver a agregar el usuario smb después:

smbpasswd -x mi_usuario
smbpasswd -a mi_usuario
— Ryad
fuente
Si bien es cierto, ¿cómo se relaciona esto con la pregunta original?
— RalfFriedl
Como dije, si cambia la identificación de usuario de un usuario, aparece el mismo error de la pregunta original. Entonces, si alguien hizo lo mismo y encuentra este hilo, él o ella podrían encontrar mi sugerencia útil.
— Ryad
1

Agregue un $al final, como este//winserver/sharename$

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename$ /mnt/mymountpoint
— Fahri çetin
fuente
¡Guauu! ¿Alguna idea de lo que hace el '$'? Lo arregló para mí, pero no tengo idea de por qué
— Gabriel Fair
El signo $ es un recurso compartido administrativo en el contexto del recurso compartido de Windows, si el sistema lo activa, un usuario con derechos administrativos puede acceder a todas las rutas. Ejemplo \\ MY-SERVER \ c $
— Phil795
0

Me encontraba con este mismo "error de montaje (2): no existe tal archivo o directorio" error usando mount.cifs en una máquina virtual CentOS 7. Nunca determiné exactamente por qué se generaba el error al usar la seguridad ntlm predeterminada (y las variantes), pero descubrí que usar la autenticación Kerberos solucionó el problema. Entonces mi línea de comando de trabajo final se veía así:

mount.cifs -v -o domain=MYCODOMAIN,sec=krb5 //winserver/sharename /mnt/mymountpoint

mientras que este comando que dio el error "no existe tal archivo o directorio" fue:

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename /mnt/mymountpoint

Para usar Kerberos, instalé el paquete "krb5-workstation" y lo configuré.

— Mark Edington
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.