SMB: auto-smonta e quindi non ri-montare senza riavviare

Question

SMB: auto-smonta e quindi non ri-montare senza riavviare

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)

4

Ho un problema ricorrente con le directory remote di montaggio / smontaggio via SMB, tuttavia non so che cosa attiva il problema né come risolverlo.

Sfondo:

Dopo aver montato con successo la directory via SMB e dopo un po 'di tempo, la directory sembra smontare da sola. Quando ciò accade, non riesco a rimontare la directory finché non riavvio il sistema.

Se non riavvio il sistema e utilizzo la finestra di dialogo "Connetti al server" per provare a montare la directory tramite SMB, la finestra di dialogo scompare come se la connessione fosse riuscita, tuttavia non è stato montato nulla.

Se provo a fare la stessa cosa con una directory padre (che è la directory root del server), allora la connessione sembra avere successo e mi chiede di "Selezionare i volumi che vuoi montare su" xyz.server .name ":" con un elenco di directory. La directory che ho precedentemente montato (che auto-smontato) è elencata, ma è ghosted out e quindi non può essere selezionata.

Quando SSH-ing nel server, non sembra esserci alcun problema con l'accesso alla directory.

Questo problema si verifica anche per altre directory remote (sebbene non sia stato possibile testarlo su un altro server).

Inoltre, quando si tenta di riconnettersi in questo scenario, Console riporta il seguente problema:

"30/10/2014 11: 48: 20.520 am NetAuthSysAgent [3346]: smb_mount: mount non riuscito a my.server.com/mydirectory, syserr = Il file esiste"

Domande:

i) Cosa sta causando la rimozione della directory / volume?

ii) Come posso evitare che si verifichi l'auto-smontaggio?

iii) Se si verifica un auto-smontaggio, come posso rimontare la directory senza riavviare?

Dettagli del sistema:

OS X 10.9.5

Retina, 15 pollici, inizio 2013

Dettagli server:

Red Hat Enterprise Linux Server versione 5.11 (Tikanga)

Versione kernel 2.6.18-371.8.1.el5

Output di df:

Prima del problema:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899360656   75553192    93% 112484080    9444149   92%   /
devfs                                                    371         371          0   100%       644          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10486471008   82479408   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Dopo il problema:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899350976   75562872    93% 112482870    9445359   92%   /
devfs                                                    373         373          0   100%       648          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10466951592  101998824   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Osservazioni:

Le directory montate sono ancora elencate in / Volumi se visualizzate dal terminale, (ad esempio "ls / Volumes"), sebbene non sia sempre il caso, ma entrambe le directory sono inaccessibili. Non sono affatto visibili all'interno del Finder.

Tuttavia, sono ancora in grado di accedere al contenuto di una delle directory di Matlab, che era già all'interno di una sottodirectory di questa directory (la sua directory di lavoro). Se poi esco dalla directory in Matlab (per esempio, nella mia home directory), non posso tornare ad esso tramite il comando 'cd', ma invece devo premere il pulsante Indietro all'interno della barra di navigazione dei file e poi tutto è accessibile di nuovo da dentro Matlab.

mount smb

posta Josh 30.10.2014 - 02:27

fonte

5 risposte

Leggi altre domande sui tag mount smb

OS X Errori del disco fisso Yosemite anche dopo averli riparati Come posso eseguire il debug di un'applicazione che si blocca su OS X?

score 1 · Answer 1

Ho intenzione di dare una risposta alla domanda 3. Non sono sicuro che il resto possa essere facilmente diagnosticato.

"Se si verifica un auto-smontaggio, come posso rimontare la directory senza riavviare?"

Prova diskutil umount /Volumes/josh e dovrebbe fare il trucco.

L'errore "File esiste" viene visualizzato perché il punto di montaggio che desidera utilizzare è già presente. Sembra che il disco non sia effettivamente smontato, solo che il Finder non può vederlo. Questo è il motivo per cui Matlab può ancora accedere ai file su di esso.

score 0 · Answer 2

In base al sito di Red Hat , non supportano l'utilizzo di condivisioni SMB utilizzando il Finder di OS X. Sembra che tu possa ancora usarlo usando il Terminale, quindi per ora potrebbe essere una soluzione.

Per quanto riguarda la disconnessione casuale: sembra che la condivisione si connetterà inizialmente, e poi andrà fuori di testa dopo aver realizzato che è nell'ambiente Mac. Mi sembra che la condivisione non smonti correttamente, ed è per questo che non potresti ricollegarti ad essa. In realtà è ancora lì, ma non è visibile in Finder.

Se dovessi disinstallare manualmente la condivisione utilizzando il terminale, mi sarei aspettato che non sarebbe stato disattivato se dovessi provare a connetterti di nuovo.

Una correzione: a seconda di come è stato impostato il server Red Hat, dovresti essere in grado di eseguire l'FTP. Mac ha alcune GUI FTP che puoi provare, oppure usa il comando ftp del terminale.

score 0 · Answer 3

What is causing the directory/volume to be unmounted?

Molto probabilmente una instabilità della connessione di rete che potrebbe essere amplificata dall'uso della configurazione di Automatic che potrebbe passare da Ethernet a Airport cercando di mantenere la connettività di rete.

Per convalidare questa ipotesi, usa:

netstat -I
ping -c 90 -i 10 your_SMB_server
tail -f /var/log/system.log
...

How can I prevent the auto-unmount from happening?

Se questo problema di rete è confermato, correggilo:):

cambia cavo
cambia porta dello switch
chiedi al tuo amministratore di rete
...

If an auto-unmount occurs, how can I re-mount the directory without restarting?

Non puoi se unmount non è terminato correttamente. Alcune informazioni di stato all'interno dell'estensione del kernel SMB sono danneggiate (modificate a metà) e non possono essere corrette in nessun altro modo rispetto alla corretta conclusione del% co_de in sospeso. Se la tua connessione è stata interrotta, Conosco un modo unico per terminare un SMB% in sospesounmount: unmount di Mac OS X (ho provato un shutdown che ha portato a un errore totale).

Devi assolutamente evitare che si verifichi un simile smontaggio in sospeso.

score 0 · Answer 4

La risposta di miken32 non ha funzionato per me, ma mi ha portato sulla strada giusta. Il mio problema è stato risolto dopo aver smontato tutte le condivisioni sul server in questione (nel tuo caso "example.com").

Quindi, usando il tuo caso, diskutil umount /Volumes/josh non è sufficiente, perché /Volumes/semantic rimane ancora. Devi smontare anche quello. Dopo di ciò, il rimontaggio dovrebbe funzionare (almeno per me).

In parole povere, non devi usare diskutil, ma puoi eseguire

umount //[email protected]/josh

e

umount //[email protected]/semantic

score 0 · Answer 5

Ho lo stesso problema, lo avevo su 10.6.8 e ora su 10.11. La causa è duplice: per uno, si suppone che la condivisione smonti (ad esempio sul sonno), ma non può essere utilizzata (contrassegnata come), quindi muore e ciò che rimane è una cartella in / Volumi che a volte potresti solo cancella e poi rimonta. Tuttavia in 10.11 è invisibile in Finder DOPO che la condivisione muore (vedi Preferenze del Finder, dicono che Finder mostra solo le condivisioni attive.

Per il secondo, il flag che i file sono in uso è impostato da MatLab. Alcune volte puoi rimuoverli con il comando MatLab fclose all e cd in qualche altro posto per liberare la condivisione, alcune volte usi effettivamente i file (modificando lo script .m dalla condivisione). Ma spesso dopo un periodo di inattività va in un dead lock: umount e diskutil unmount non possono rilasciare la condivisione perché "Risorsa occupata" e MatLab non possono rilasciare i suoi flag perché la condivisione è sparita da tempo.

Uso macfusion, quindi c'è un meccanismo per la condivisione da morire quando sshfs perde la connessione al server. Di questi tre: Finder, MatLab e Fuse, direi che MatLab è malvagio, poiché altri programmi come BBedit non bloccano mai la condivisione in modo così micidiale. Spesso riesco a rimontare solo dopo aver lasciato MatLab.