error de montaje 13 = Permiso denegado

45

Uno de mis servidores está configurado para montar automáticamente un directorio de Windows usando fstab. Sin embargo, después de mi último reinicio, dejó de funcionar. La línea en fstab es:

//myserver/myfolder /mnt/backup cifs credentials=home/myfolder/.Smbcredentials

El .Smbcredentialsarchivo es:

username=myaccount
password=mypassword
domain=mydomain

Hago un mount -ay recibo mount error 13 = Permission denied. Si hago esto lo suficiente, bloqueará mi cuenta de Windows, así que sé que lo está intentando. He comprobado que mi contraseña es correcta.

¿Qué estoy haciendo mal?

Conservar en vinagre
fuente
44
¿Podría intentar montar desde la línea de comandos con mount -t cifs //myserver/myfolder /mnt/backup --verbose -o credentials=home/myfolder/.Smbcredentialsy agregar la información de depuración (desinfectada) a su pregunta?
bsd
¿Cuál es la distribución y la versión cifs-utilsque tienes instalada? He tenido este problema antes y creo que se debió a una actualización.
slm

Respuestas:

44

Un par de cosas para revisar. Hago algo similar y puedes probar montarlo directamente usando el mountcomando para asegurarte de que tienes las cosas configuradas correctamente.

Permisos en el archivo de credenciales

Asegúrese de que este archivo tenga permiso correcto.

$ sudo ls -l /etc/smb_credentials.txt 
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt

Montaje detallado

Puede obtener más información al mountusar el -vinterruptor que a menudo le mostrará dónde se están tropezando las cosas.

$ sudo mount -v -t cifs //server/share /mnt \
    -o credentials=/etc/smb_credentials.txt

Resultando en esta salida si funciona:

mount.cifs kernel mount options: ip=192.168.1.14,unc=\\server\share,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********

Revisa los registros

Después de ejecutar el comando de montaje anterior, eche un vistazo dentro de sus archivos dmesgy / /var/log/messageso en /var/log/syslogbusca de cualquier mensaje de error que pueda haberse generado al intentarlo mount.

Tipo de seguridad

Puede pasar muchas opciones adicionales a través del -o ..interruptor para montar. Estas opciones son específicas de la tecnología, por lo que en su caso son aplicables mount.cifsespecíficamente. Eche un vistazo a la mount.cifspágina de manual para obtener más información sobre todas las opciones que puede pasar.

Sospecho que te falta una opción sec=.... Específicamente una de estas opciones:

   sec=
       Security mode. Allowed values are:
       ·   none - attempt to connection as a null user (no name)
       ·   krb5 - Use Kerberos version 5 authentication
       ·   krb5i - Use Kerberos authentication and forcibly enable packet 
           signing
       ·   ntlm - Use NTLM password hashing
       ·   ntlmi - Use NTLM password hashing and force packet signing
       ·   ntlmv2 - Use NTLMv2 password hashing
       ·   ntlmv2i - Use NTLMv2 password hashing and force packet signing
       ·   ntlmssp - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP
           message
       ·   ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw 
           NTLMSSP message, and force packet signing

       The default in mainline kernel versions prior to v3.8 was sec=ntlm. 
       In v3.8, the default was changed to sec=ntlmssp.

Es posible que deba ajustar la sec=...opción para que sea sec=ntlmo sec=ntlmssp.

Referencias

slm
fuente
1
La comprobación dmesgfue muy útil. Esta respuesta fue de 2014, y desde entonces, la explotación de SMB1.0 de WannaCry la ha dejado en desuso, así que asegúrese de agregar vers=2.02.1 o 3.0, lo que sea compatible con el servidor, ya que el 1.0 predeterminado ya no será compatible.
Michael Plautz
1
Solo un aviso: dado que la carpeta de destino está bajo Windows, que a menudo requiere el cambio de contraseña de vez en cuando, la contraseña en el archivo de credenciales puede no ser válida. mountEl comando no le dirá tales detalles.
HongboZhu
22

Gracias, pero un poco más de google encontró la solución. Estaba usando el tipo de seguridad incorrecto por defecto; este comando funcionó:

$ sudo mount -t cifs //172.16.1.5/myshare/ /mnt/myshare \
    -osec=ntlmv2,domain=MYDOMAIN,username=myusername,password=mypassword
Conservar en vinagre
fuente
¡Esto fue! Ejecutar mount -t cifs //10.0.0.138/usb1_1 /mnt/usbdisk -ousername=theusername,password=thepassord,file_mode=0644,dir_mode=0755,uid=rooten una máquina Fedora 25 funcionó bien, pero falló cuando ejecuté exactamente el mismo comando en un cuadro openwrt (Chaos Calmer 15.05.1). Agregar lo sec=ntlmv2hizo funcionar allí también.
hlovdal
2
Vine aquí tratando de montar un miembro de Debian 9 AD de un no miembro de CentOS 6, y esto me acercó, para mi caso la magia fuesec=ntlmssp
Cheetah el
La solución para mí fue usar la domainpalabra clave y especificarla aparte del nombre de usuario.
Jim cayó
sec = ntlmv2 tiene la opción que solo necesitaba para mi acceso smb de Ubuntu 18.04 a Windows 10 share. Gracias Pickle.
noel aye
12

Me encontré con este problema y resultó que no formateaba correctamente los valores en mi archivo de credenciales. Lo intenté:

username=DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

También probé:

[email protected]
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Y:

username=FULLY.QUALIFIED.DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Una vez que solo utilicé mi nombre de usuario de inicio de sesión:

username=mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Pude hacer que mi montaje cifs tuviera éxito.

Mark Salisbury
fuente
gran explicación!
Dima Lituiev
2

Este complemento funciona en Linux científico 6.6 (RedHat 6.6)

editar /etc/fstab
crear archivo = .credentials(por ejemplo, en /etc) con estos detalles:

username=value
password=value
domain=value

//SERVER/SHARE1 /mnt/SHARE1 cifs credentials=/etc/.credentials,rw,uid=1000,gid=1000,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0 
stoferontheweb
fuente
¡Las banderas file_mode y dir_mode han sido resueltas para mí! :)
Rafael Moni