impossibile usare mount.cifs: mount error (2): nessun file o directory

17

Il comando mount.cifs non è in grado di funzionare in 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)

È stato confermato che l'esistenza e l'accessibilità del file mountpoint / home / directory / percorso e file credenziali / etc / user . Inoltre sono stati abilitati i moduli e i servizi pertinenti, ovvero

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

e

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

Questo problema è stato identificato da molti utenti, ad esempio un esempio . NOTA ANCHE che lo stesso comando eseguito nel mio sistema Ubuntu / debian è in grado di montare correttamente.

Altre informazioni nella macchina problematica:

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

la versione di mount.cifs installata in debian / ubuntu è 6.0

mount 
— Chenming Zhang
fonte
/home/directory/pathesiste sicuramente nell'ambiente Gentoo? Strano che non lo menzioni, poiché questa è la prima ovvia domanda che si pone.
— Hauke ​​Laging,
Sì, ho confermato l'esistenza e l'accessibilità del mount point / home / directory / path .
— Chenming Zhang,
È necessario aggiungere queste informazioni alla domanda in modo che altri lettori non debbano leggere i commenti per ottenerle.
— Hauke ​​Laging,

Risposte:

8

Potrebbe essere necessario fornire l'opzione vers = al comando mount per forzare la versione 3.0 se si sta tentando di montare una condivisione da una versione più recente di Windows. Uno dei nostri file server è stato recentemente aggiornato a 2012R2 ed è allora che il mio mount ha smesso di funzionare. Impostandolo su vers = 3.0 risolto il problema. Come la maggior parte degli errori Samba / CIFS, il messaggio "Nessun file o directory del genere" non è di grande aiuto.

Come esempio:

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

..Dove ho il mio dominio, nome utente e password contenuti nel file .cifs_user.

Apparentemente, smbmount utilizza una versione più recente del protocollo SMB per impostazione predefinita poiché ha funzionato senza problemi o con opzioni speciali.

Si noti di seguito che la versione del protocollo predefinita è 1.0.

Dalla pagina man 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
fonte
Ho avuto un problema simile con il flag "nounix" che non deve essere supportato in v1.0. Il passaggio alla versione 2.0 (l'ultima disponibile per me) ha risolto il problema. Anche le autorizzazioni per i file sono più sensate con vers = 2.0 (755 anziché 777)
— cxrodgers,
2
Grazie mille per la soluzione relativa all'opzione vers =! Ha funzionato per me, solo all'indietro ... Dopo l'aggiornamento di opensuse passa dalla versione 42.3 alla 15.1, una voce fstab per il montaggio di un'unità di rete, che ha funzionato, ha smesso di funzionare in 15.1. Ho usato l'opzione vers = 1.0 e indovina un po '... Probabilmente il salto 15.1 utilizza una versione più recente del protocollo SMB che non è stato in grado di trovare la directory remota.
— Giovanni
La connessione a una condivisione ospitata su Windows Server 2003 da Ubuntu 19.04 non è riuscita per me finché non ho aggiunto vers = 1.0 al mio elenco di opzioni. Grazie!
— user8675309
Ha funzionato per me, TRANNE: ho dovuto dichiarare la versione DUE vers=2.0per montare le condivisioni samba del mio sistema NAS di 5 anni ... con 3.0 ho superato l'errore.
— Frank Nocke,
etc/fstabutenti: basta mettere quello vers=3.0(o 2.0 ...) giusto e senza spazio prima delle altre opzioni, vale a direvers=2.0,guest,uid=1000,iocharset…
— Frank Nocke
5

Puoi usare l' nodfsopzione? cioè per le tue -oopzioni input passa l'input come sotto.

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

cioè aggiunto ,nodfs

Ha funzionato per me.

— Sanath
fonte
grazie! Prima ho provato tutti gli altri suggerimenti, ma su fedora30 non ne avevo bisogno prima
— Jens Timmerman,
2

Potrebbe essere necessario modificare il secparametro: questa impostazione ha funzionato sulla mia configurazione:

mount.cifs ... -o sec=ntlm

Estratto pertinente di man mount.cifs:

sec=Modalità di sicurezza. I valori consentiti sono:

  • none - tenta di connettersi come utente null (nessun nome)
  • krb5 - Utilizzare l'autenticazione Kerberos versione 5
  • krb5i - Utilizzare l'autenticazione Kerberos e abilitare forzatamente la firma dei pacchetti
  • ntlm - Utilizzare l'hash della password NTLM
  • ntlmi - Utilizzare l'hash della password NTLM e forzare la firma dei pacchetti
  • ntlmv2 - Utilizzare l'hash della password NTLMv2
  • ntlmv2i - Utilizzare l'hash della password NTLMv2 e forzare la firma dei pacchetti
  • ntlmssp - Utilizzare l'hash della password NTLMv2 incapsulato nel messaggio Raw NTLMSSP

  • ntlmsspi - Utilizzare l'hash della password NTLMv2 incapsulato nel messaggio NTLMSSP non elaborato e forzare la firma dei pacchetti

    L'impostazione predefinita nelle versioni del kernel mainline precedenti alla v3.8 era sec=ntlm. Nella v3.8, il valore predefinito è stato modificato in sec=ntlmssp.

    Se il server richiede la firma durante la negoziazione del protocollo, potrebbe essere abilitato automaticamente. La firma dei pacchetti può anche essere abilitata automaticamente se è abilitata /proc/fs/cifs/SecurityFlags.

— Benoit Duffez
fonte
1

Mi sono imbattuto in questo su Ubuntu 18.04. Il problema era che avevo bisogno del pacchetto keyutils per eseguire l'autenticazione Kerberos ( sec=krb5opzione mount), che non era installata insieme a cifs-utils (che forniva mount.cifs). Non sono sicuro che il nome del pacchetto sia uguale o meno su Gentoo. (Grazie a https://forum.zentyal.org/index.php?topic=18601.0 per la soluzione.)

— Chris
fonte
1

Prova a installare i keyutils del pacchetto:

sudo apt-get install keyutils

Non so esattamente perché questo aiuti, forse qualcun altro ha una risposta qui. Ma almeno ha fatto il trucco per me: con keyutils la cifs mount ha funzionato bene.

— Klaus
fonte
Aggiungi alcune informazioni su come risolvere il problema indicato nella domanda. Cosa fa questo pacchetto e come si inserisce nel problema sollevato dal PO?
— Haxiel,
Buona domanda. Non sono sicuro di come il pacchetto keyutils aiuti. Nel mio caso almeno questo è ciò che ha fatto il trucco. Dopo l'installazione di keyutils, il mio mount cifs ha funzionato bene, mentre prima ho ricevuto il messaggio di errore "mount error (2): No tali file o directory", proprio come nell'OP.
— Klaus
Duplica di questa altra risposta
— roaima,
1

Volevo aggiungere un'altra fonte di questo problema che ho riscontrato oggi. Una volta modificato l'ID utente di un utente unix, l'utente smb creato tramite smbpasswd potrebbe non essere più in grado di autenticarsi per la condivisione samba con lo stesso errore.

Quindi, se hai modificato il tuo ID utente unix tramite, usermod -u 1000 my_userpotresti riscontrare problemi. La correzione per me è stata quella di eliminare e aggiungere nuovamente l'utente smb in seguito:

smbpasswd -x my_user
smbpasswd -a my_user
— Ryad
fonte
Sebbene sia vero, in che modo è correlato alla domanda originale?
— RalfFriedl,
Come ho detto, se si modifica l'ID utente di un utente, viene visualizzato lo stesso errore della domanda originale. Quindi, se qualcuno ha fatto lo stesso e trova questa discussione, potrebbe trovare utile il mio suggerimento.
— Ryad,
1

Aggiungi $a alla fine, in questo modo//winserver/sharename$

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename$ /mnt/mymountpoint
— Fahri çetin
fonte
Wow! Hai idea di cosa faccia il '$'? Lo ha risolto per me, ma non ho idea del perché
— Gabriel Fair,
Il simbolo $ è una condivisione amministrativa nel contesto della condivisione di Windows, se attivato dal sistema, un utente con diritti amministrativi può accedere a tutti i percorsi. Esempio \\ MY-SERVER \ c $
— Phil795
0

Mi sono imbattuto in questo stesso errore "errore di montaggio (2): nessun file o directory di questo tipo" utilizzando mount.cifs su una VM CentOS 7. Non ho mai determinato esattamente il motivo per cui l'errore veniva generato quando si utilizzava la sicurezza ntlm predefinita (e le varianti), ma ho scoperto che l'utilizzo dell'autenticazione Kerberos ha aggirato il problema. Quindi la mia riga di comando di lavoro finale sembrava così:

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

mentre questo comando che ha dato l'errore "nessun file o directory" era:

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

Per usare Kerberos, ho installato il pacchetto "krb5-workstation" e l'ho configurato.

— Mark Edington
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.