Per alcuni mesi ho montato un paio di directory in remoto da una Debian Jessie, in una condivisione Windows.
Nelle ultime settimane, continuo a lamentarmi di disconnessioni casuali dal punto di montaggio e ho dovuto fare un
sudo mount -a
per riottenere la connettività di montaggio, un paio di volte (il server viene utilizzato una o due volte alla settimana).
per esempio. le cavalcature non si riprendono spesso dopo un certo periodo di inutilizzo.
L'amministratore di Windows mi ha anche detto che il server Windows non viene riavviato da un po'.
Oggi, per coincidenza, quando si esegue mount -a ancora una volta, ha funzionato solo al 2° tentativo, mentre il primo tentativo ha dato il seguente errore:
sudo mount -a
mount error(104): Connection reset by peer
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Le directory vengono montate da /etc/fstab come tale:
//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001 0 0
Quando esegui un comando di montaggio, puoi anche vedere l'opzione echo_interval viene attivato per impostazione predefinita a 60 minuti.
$mount
//10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=1.0,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)
Cosa fare?
Risposta accettata:
Ho trovato un interessante post correlato qui la cartella montata cifs continua a disconnettersi (server Ubuntu), parlando di un problema simile (stesso errore, condivisioni Samba).
Il bocconcino rilevante qui, per seguire il resto della risposta, è che i mount CIFS utilizzano il protocollo SMBv1.0 per impostazione predefinita, come può essere verificato emettendo il mount comando e prestando attenzione a vers=1.0 campo.
$mount
//10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=1.0,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)
Ho anche trovato in Stack Overflow, l'host CIFS post Mount è inattivo
Ciò potrebbe essere dovuto anche alla mancata corrispondenza del protocollo. Nel 2017 Microsoft
ha aggiornato i server Windows e ha consigliato di disabilitare il protocollo SMB1.
D'ora in poi, mount.cifs potrebbe avere problemi con la negoziazione del protocollo.
L'errore visualizzato è "L'host non è disponibile". ma quando esegui il debug con:
smbclient -L <server_ip> -U <username> -d 256
riceverai l'errore:
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
Il post menziona che le patch di Windows al protocollo/Wannacry e altri stanno incasinando/o più esattamente, alcune persone hanno disabilitato la funzionalità delle richieste CIFS v1; problemi simili si sono verificati sul fronte Windows e, data la tempistica, mi viene il sospetto che il problema sia correlato.
Non abbiamo disabilitato CIFS v1 in questo server specifico, AFAIK (e il test lo conferma), tuttavia i bollettini MS suggeriscono che il comportamento SMBv1 predefinito è stato (leggermente) modificato.
Ho finito per seguire l'idea generale suggerita nella citata domanda Samba. Da man mounts.cifs :
vers=
- Versione del protocollo SMB. I valori consentiti sono:
-
1.0 – Il classico protocollo CIFS/SMBv1. Questa è l'impostazione predefinita.
-
2.0 – Il protocollo SMBv2.002. Questo è stato inizialmente introdotto in Windows Vista Service Pack 1 e Windows Server 2008. Tieni presente che
la versione iniziale di Windows Vista parlava un dialetto leggermente diverso (2.000) che non è supportato. -
2.1 – Il protocollo SMBv2.1 introdotto in Microsoft Windows 7 e Windows Server 2008R2.
-
3.0 – Il protocollo SMBv3.0 introdotto in Microsoft Windows 8 e Windows Server 2012.
Tieni inoltre presente che mentre questa opzione regola la versione del protocollo utilizzata, non tutte le funzionalità di ciascuna versione sono disponibili.
--verbose
- Stampa informazioni di debug aggiuntive per la montatura. Nota che questo parametro deve essere specificato prima di
-o . Ad esempio: mount -t cifs //server/share /mnt --verbose -o user=username
Come si vede dal manuale, nelle recenti versioni di Windows successive a Windows 8
si utilizza almeno vers=2.0 può avere più senso; la sintassi alternativa nella riga di comando
con il --verbose l'opzione menzionata è anche utile
per eseguire ulteriormente il debug di eventuali complicazioni che potrebbero sorgere.
In quanto tale, poiché il server Windows da cui sto montando roba da questa domanda è un server Windows 2008 R2, ho inserito /etc/fstab :
//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001,vers=2.1 0 0
Quindi rimontalo per rendere effettiva l'opzione:
sudo mount -o remount /mnt/mount_point
Ora verifichiamo, con mount ancora, per confermare il protocollo negoziato:
$mount
//10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=2.1,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)
E possiamo davvero confermare di aver modificato con successo il protocollo SMB utilizzato.
Va inoltre notato CIFS v1.0, oltre ad essere obsoleto, è estremamente inefficiente e insicuro, rispetto alle versioni più recenti del protocollo.
Dai blog di MS:smetti di usare SMB1
SMB1 non è moderno o efficiente
Quando utilizzi SMB1, perdi le principali
ottimizzazioni delle prestazioni e della produttività per gli utenti finali.
- Letture e scritture maggiori (2.02+) – uso più efficiente di reti più veloci
o WAN a latenza superiore. Ampio supporto MTU. - Peer caching delle proprietà delle cartelle e dei file
(2.02+):i client conservano le copie locali delle cartelle e dei file
tramite BranchCache - Maniglie durevoli (2.02, 2.1):consentono alla connessione
di riconnettersi in modo trasparente al server in caso di
disconnessione temporanea - Modello di leasing oplock client (2.02+) – limita
i dati trasferiti tra client e server, migliorando
le prestazioni su reti ad alta latenza e aumentando la scalabilità del server SMB - Multicanale e SMB Direct (3.0+) – aggregazione della larghezza di banda della rete
e tolleranza agli errori se sono disponibili più percorsi tra
client e server, oltre all'utilizzo del moderno ultra-alto in RDMA
infrastruttura - Leasing di directory (3.0+) – Migliora i tempi di risposta dell'applicazione
nelle filiali tramite la memorizzazione nella cache
È interessante notare che quest'ultimo articolo suggerisce che è meno probabile che i problemi di disconnessione appaiano dopo una disconnessione (handle durevoli) se si utilizza un protocollo>=2.01, quindi sottolineo ancora una volta, per non continuare a utilizzare CIFS v1.0. (ad esempio, nella versione 1.0, echo_interval=60 lo mantiene connesso, se si verifica un problema tecnico di rete o qualche altra interruzione del server, il montaggio non si ripristinerà senza l'intervento manuale, durante l'utilizzo di CIFS v1.0)
Come ultimo consiglio, evita di fare sudo mount -a e inizia a fare:
sudo mount -o remount -a
Vedi anche la mia domanda CIFS che monta più copie della stessa condivisione sullo stesso punto di montaggio