mount.cifs non può usare lo stesso file di credenziali utilizzato da smbclient

10

Sto cercando di montare una condivisione CIFS di NetApp su uno dei nostri server e continuo a far stampare "Autorizzazione negata" su stderr e NT_STATUS_WRONG_PASSWORDin esecuzione 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

Il smbclientcomando, tuttavia, funziona senza problemi, utilizzando lo stesso file di credenziali esatte:

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...]

Sembra che se uno funziona anche l'altro, specialmente perché il file delle credenziali specifica anche il nome del dominio.

— Bratchley
fonte

cosa è successo alla taglia?

Non ho mai avuto una risposta che abbia funzionato per me, quindi alla fine la taglia è scaduta e tutti quei punti sono andati sulla via del dodo.

— Bratchley,

Se riesci a pensare alla risposta, ti assegnerò una nuova ricompensa, non voglio continuare a perdere punti se non ottengo una risposta.

— Bratchley,

Quindi, avevo un problema simile (con l'errore -13 dal modulo kernel). Ho installato il cifs-utilspacchetto (Debian) e il problema è stato risolto. Ho trascorso un po 'di debug perché non mi aspettavo alcun supporto senza che il pacchetto fosse stato installato, quindi ho pensato che lo fosse. Mi aspettavo qualcosa come "filesystem sconosciuto" da mount, ma non è successo.

— Sherrellbc,

7

Senza ulteriori informazioni non posso dirlo con certezza, ma ho riscontrato questo problema durante la connessione a un server Windows più vecchio che eseguiva una versione di protocollo precedente. Ricorda che CIFS è considerato un "dialetto" (tipo) di SMB. Esistono altri tipi e le configurazioni precedenti non usano CIFS.

Fondamentalmente è come dire che due persone stanno parlando. Uno spagnolo e un inglese, e il tuo tentativo di forzare chi parla inglese a capire lo spagnolo quando chiaramente non lo fa.

SMBclient utilizza una diversa selezione per le negoziazioni sulla sicurezza. (o almeno rileva diversamente).

Provare

mount -t cifs // percorso / cosa / / mount / punto -o nomeutente = utente, password = passaggio, sec = ntlm

e vedi cosa succede. (sec = ntlm è la parte importante)

— coteyr
fonte

Stesso problema anche quando si specifica l'autenticazione NTLM. Lo stesso se lo faccio ntlmo ntlmv2. Non sono sicuro di come risolverlo, quindi se hai bisogno di ulteriori informazioni fammi sapere e aggiornerò la domanda. Potrebbero esserci dei controlli di accesso sul lato NetApp che il ragazzo SAN ha perso?

— Bratchley,

Versione del software server, ci sono router o switch sulla strada?

— Coteyr,

Stessa sottorete. Non sono sicuro di quale versione di Samba sia dall'altra parte poiché è un dispositivo NetApp ONTAP.

— Bratchley,

4

Giocando con i comandi, ho trovato un possibile motivo:

Dalla pagina man di 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.

Dalla pagina man di 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

Quindi ho creato due file di credenziali, uno con spazi, come mostrato nel primo frammento e uno senza e li ho nominati credse creds.spacy.

La grande resa dei conti:

Con il credsfile:

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

buon silenzio, nessun errore.

Con il creds.spacyfile:

# 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)

Quindi ovviamente il tuo file di credenziali contiene spazi che non sono compresi da mount.cifs.

Inoltre smbclient, non importa se ci sono spazi. credse creds.spacynon ha causato alcun fagiano di monte.

C'era una riga vuota in più alla fine del file ma ottengo la stessa cosa dopo averlo eliminato. Questa è una versione leggermente ridotta di ciò che è nel file dei crediti. Le password redatte e reali sono password miste contenenti "!" come personaggio speciale.

— Bratchley,

C'è un altro aspetto in questo, che questa soluzione mi ha portato a trovare: le credenziali devono essere nell'ordine corretto, ovvero nome utente, password, dominio e non qualsiasi altro ordine come dominio, nome utente, password (che è quello che avevo). Funziona bene anche con, smbclientma fallisce mount.cifs. Una volta modificato l'ordine con quello corretto, come specificato nella documentazione che hai citato qui, ha iniziato a funzionare. Sembra che questi (sia la cattiva gestione degli spazi che il problema degli ordini) siano terribili bug che dovrebbero essere facilmente risolvibili da chiunque mantenga mount.cifs.

— leftclickben

2

L'aggiunta di sec = ntlm ha corretto il problema per me. Ho un NAS più vecchio (netgear stora). La sicurezza predefinita per cifs nei kernel recenti è ntlmssp

— Ed Hourigan
fonte

Ha funzionato anche per me. Non conosco ancora la vera causa. Nel caso in cui aiuti qualcuno: isilon si monta su Ubuntu LTS 14.04. L'isilon (qualche cosa di SAN) parla con la nostra directory attiva di windows. Lo stesso account ha funzionato come un incantesimo su altre macchine e durante il montaggio diretto su Windows.

— Reinout van Rees,

Nota aggiuntiva: 12.04 con gli ultimi aggiornamenti funziona correttamente, 14.04 è in qualche modo parte del problema ora (fine aprile 2015).

— Reinout van Rees,

Ultima nota extra: il problema principale era un problema noto di Microsoft con l'archiviazione emil isilon e l'aggiornamento KB3002657 (o almeno così mi dice il mio amministratore di sistema in questo momento :-))

— Reinout van Rees

2

Un'altra possibilità che ho scoperto durante il tentativo di montare una condivisione oggi è che smbmountsupporta la username=DOMAIN\\usersintassi per fornire un utente in un dominio come credenziale.

Per mount.cifs(e mount -t cifs) per il lavoro, questi due devono essere fornite separatamente: -o username=user,password=pass,dom=DOMAIN.

— fiskfisk
fonte

Per montare una condivisione smb 3.0 servita da un NetApp Clustered Data ONTAP ha dovuto chiamare entrambi sec=ntlmedom=DOMAIN

— iii

1

Come spiegato da user55518, probabilmente hai degli spazi nel file delle tue credenziali anche se non li vedi. Se hai modificato il tuo file di credenziali su Windows, probabilmente hai \rla fine delle tue righe e questo genera l'errore 13.

— Cyrlop
fonte

è possibile utilizzare l'elenco dei set di comandi in vim per verificare la presenza di tab / spazi extra

— vfbsilva,

0

Voglio ringraziare tutti voi !!! per questo problema, mi aiuta davvero molto !, ho anche trovato alcune informazioni importanti sul parametro "sec = ntlm", quindi lascio il link se alcuni di voi sono interessanti al riguardo, righe di seguito:

Microsoft NTLM

Stavo cercando di montare una directory di condivisione dal desktop di Windows 7, ma era impossibile fino ad aggiungere il parametro "sec = ntlm" e funziona, e alcuni dettagli importanti potrebbero essere che non ho considerato che il mio desktop di Windows 7 fosse in un dominio, quindi penso che sia stato il dettaglio più importante che dovrei considerare. quindi funziona! Grazie davvero a tutti voi! Benedizioni !! e buone vibrazioni! : D

— DarkPenguin15
fonte

0

Nel mio caso, dovevo solo aggiungere l'opzione vers=3.0(CIFS era la versione 1, che non è più supportata dal kernel 4.13, quindi sono passato a SMBv3 sul server) e ho comunque dovuto riavviare per farlo funzionare, questo è il mio montare la linea /etc/fstabora:

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

Il mio file di credenziali:

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

In realtà, domainnon è necessario, ma è l'opzione corretta da usare ora secondo la pagina man mount.cifs.

— Gregor
fonte

0

Ho lottato con questo per un po '.

Con i seguenti errori:

mount error(112): Host is down

qui ha aiutato a impostare l'opzione vers = 1.0, quindi ha riportato

mount error(13): Permission denied

e si è rivelato essere "caratteri extra nel mio file di credenziali

dove originariamente avevo:

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

dove dovrebbe essere

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

— remigiusz boguszewicz
fonte