mount.cifs no puede usar el mismo archivo de credenciales que smbclient usa

10

Estoy tratando de montar un recurso compartido CIFS de NetApp en uno de nuestros servidores y sigo recibiendo "Permiso denegado" impreso en stderr e NT_STATUS_WRONG_PASSWORDimpreso en ejecución dmesg.

root@xxxehpvld05 ~ $ mount.cifs -vv //zhp-nas.xxx.com/perspectives /mnt/secure/cifs -o credentials=/etc/cifs.creds
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
root@xxxehpvld05 ~ $ dmesg | tail
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

El smbclientcomando, sin embargo funciona sin problema, utilizando el mismo archivo de credenciales exactas:

root@xxxehpvld05 ~ $ smbclient -L //zhp-nas.xxx.com/perspectives -A /etc/cifs.creds
Domain=[XXX] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       Remote IPC
        ZHPSubmit-dev   Disk
    [...snip...]

Parece que si uno funciona, el otro también debería hacerlo especialmente porque el archivo de credenciales también especifica el nombre de dominio.

— Bratchley
fuente

¿Qué pasó con la recompensa?

Nunca recibí una respuesta que funcionó para mí, por lo que la recompensa finalmente expiró y todos esos puntos siguieron el camino del dodo.

— Bratchley

Si puede pensar en la respuesta, le otorgaré una nueva recompensa, simplemente no quiero seguir perdiendo puntos si no obtengo una respuesta.

— Bratchley

Entonces, estaba teniendo un problema similar (con el error -13 del módulo del kernel). Instalé el cifs-utilspaquete (Debian) y resolvió el problema. Pasé un poco depurando esto porque no esperaba ningún soporte sin haber instalado el paquete, así que supuse que sí. Esperaba algo como "sistema de archivos desconocido" de mount, pero eso no sucedió.

— Sherrellbc

7

Sin más información, no puedo decir con certeza, pero he visto este problema al conectarme a un servidor de Windows anterior que ejecutaba una versión de protocolo anterior. Recuerde que CIFS se considera un "Dialecto" (tipo) de SMB. Hay otros tipos y las configuraciones anteriores no usan CIFS.

Básicamente es como decir que dos personas están hablando. Un español y un inglés, y estás tratando de obligar al hablante de inglés a entender el español cuando claramente no lo hace.

SMBclient utiliza un dielect diferente para las negociaciones de seguridad. (o al menos detecta de manera diferente).

Tratar

mount -t cifs // ruta / cosa / / mount / punto -o nombre de usuario = usuario, contraseña = pasar, sec = ntlm

y mira lo que pasa. (sec = ntlm es la parte importante)

— coteyr
fuente

Mismo problema incluso cuando se especifica la autenticación NTLM. Lo mismo si lo hago ntlmo ntlmv2. No estoy seguro de cómo solucionarlo, así que si necesita más información, avíseme y actualizaré la pregunta. ¿Podría haber algunos controles de acceso en el lado de NetApp que el chico de SAN perdió?

— Bratchley

Versión del software del servidor, ¿hay algún enrutador o conmutador en el camino?

— coteyr

Misma subred. No estoy seguro de qué versión de Samba está del otro lado, ya que es un dispositivo NetTApp ONTAP.

— Bratchley

4

Jugando con los comandos, encontré una posible razón:

Desde la página de manual de smbclient:

   -A|--authentication-file=filename
       This option allows you to specify a file from which to read the
       username and password used in the connection. The format of the file is

           username = <value>
           password = <value>
           domain   = <value>

       Make certain that the permissions on the file restrict access from
       unwanted users.

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

   credentials=filename
       specifies a file that contains a username and/or password and
       optionally the name of the workgroup. The format of the file is:

          username=value
          password=value
          domain=value

Luego creé dos archivos de credenciales, uno con espacios, como se muestra en el primer fragmento y otro sin él y los nombré credsycreds.spacy .

El gran enfrentamiento:

Con credsarchivo:

mount.cifs -vvv //host/path /local/path -o credentials=/path/creds

Buen silencio, sin errores.

Con creds.spacyarchivo:

# mount.cifs -vvv //host/path /local/path -o credentials=/path/creds.spacy
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Entonces, obviamente, su archivo de credenciales contiene espacios, que mount.cifs no entiende.

Además smbclient, no importa si hay espacios. credsy creds.spacyno causó ningún urogallo.

Había una línea en blanco adicional al final del archivo, pero obtengo lo mismo después de eliminarlo. Esta es una versión ligeramente redactada de lo que está en el archivo de créditos. Las contraseñas redactadas y reales son contraseñas de mayúsculas y minúsculas que contienen "!" como un personaje especial

— Bratchley

Hay otro aspecto de esto, que esta solución me llevó a encontrar: las credenciales deben estar en el orden correcto, es decir, nombre de usuario, contraseña, dominio y no cualquier otro orden como dominio, nombre de usuario, contraseña (que es lo que tenía). Esto también funciona bien smbclientpero falla mount.cifs. Una vez que cambié el orden al correcto como se especifica en la documentación que citó aquí, comenzó a funcionar. Parece que estos (tanto el mal manejo de espacios como el problema de ordenar) son errores terribles que deberían ser fácilmente reparables por quien sea que los mantenga mount.cifs.

— leftclickben

2

Agregar sec = ntlm me corrigió el problema. Tengo un NAS más antiguo (netgear stora). La seguridad predeterminada para cifs en núcleos recientes es ntlmssp

— Ed Hourigan
fuente

A mí también me funcionó. Todavía no sé la verdadera causa. En caso de que ayude a alguien: isilon mount en ubuntu LTS 14.04. El isilon (algo SAN) habla con nuestro directorio activo de Windows. La misma cuenta funcionó como un encanto en otras máquinas y al montarla directamente en ventanas.

— Reinout van Rees

Nota adicional: 12.04 con las últimas actualizaciones funciona bien, 14.04 es de alguna manera parte del problema ahora (finales de abril de 2015).

— Reinout van Rees

Última nota adicional: el problema principal era un problema conocido de Microsoft con el almacenamiento y la actualización KB3002657 de emc isilon (o eso me dice mi administrador de sistemas en este momento :-))

— Reinout van Rees

2

Otra posibilidad que descubrí al intentar montar un recurso compartido hoy es que smbmountadmite la username=DOMAIN\\usersintaxis para proporcionar a un usuario en un dominio como credencial.

Para mount.cifs(y mount -t cifs) para el trabajo, estos dos tienen que ser proporcionado por separado: -o username=user,password=pass,dom=DOMAIN.

— fiskfisk
fuente

Para montar un recurso compartido smb 3.0 servido por un NetApp Clustered Data, ONTAP tuvo que llamar a ambos sec=ntlmydom=DOMAIN

— iii

1

Como explicó user55518, probablemente tenga espacios en su archivo de credenciales incluso si no los ve. Si editó su archivo de credenciales en Windows, probablemente tenga \ral final de sus líneas y eso arroja el error 13.

— Cyrlop
fuente

puede usar la lista de conjuntos de comandos en vim para verificar pestañas / espacios adicionales

— vfbsilva

0

Quiero agradecerles a todos !!! para este problema, ¡Realmente me ayudó mucho !, también encontré información importante sobre el parámetro "sec = ntlm", así que dejo el enlace si alguno de ustedes está interesado en ello, líneas a continuación:

Microsoft NTLM

Estaba tratando de montar un directorio compartido desde el escritorio de Windows 7, pero fue imposible agregar el parámetro "sec = ntlm" y funciona, y algunos detalles importantes podrían ser que no consideré que mi escritorio de Windows 7 estaba en un dominio, así que creo que fue el detalle más importante que debo considerar. por lo tanto, ¡funciona !, ¡realmente muchas gracias a todos ustedes, bendiciones! y buen rollo! :RE

— DarkPenguin15
fuente

0

En mi caso, solo necesitaba agregar la opción vers=3.0(CIFS era la versión 1, que ya no es compatible desde el kernel 4.13, así que cambié a SMBv3 en el servidor) y aún así tuve que reiniciar para que funcione, este es mi monte la línea /etc/fstabahora:

auto,rw,credentials=/usr/local/etc/smb.credentials,vers=3.0,file_mode=0664,dir_mode=0775,uid=myuser,gid=users

Mi archivo de credenciales:

username=myuser
password=****
domain=mydomain

En realidad, domainno es necesario, pero es la opción correcta para usar de acuerdo con la página de manual de mount.cifs ahora.

— Gregor
fuente

0

He estado luchando con esto por un tiempo.

Con los siguientes errores:

mount error(112): Host is down

aquí ayudó a establecer la opción vers = 1.0, luego informó

mount error(13): Permission denied

y resultó ser "caracteres extra en mi archivo de credenciales

donde originalmente tuve:

# cat /etc/samba/cred-file
username="john"
password="secret"

donde debería estar

# cat /etc/samba/cred-file
username=john
password=secret

— remigiusz boguszewicz
fuente