Mi è successo su un server Apple che dopo un riavvio forzato del sistema alcune applicazioni con documenti risiedenti su dischi o partizioni diverse dal disco di sistema facessero i capricci.
Accedendovi via SSH, mi sono accorto che il mount point (o directory radice se preferite) dei dischi esterni, quello che si trova nella directori “/Volumes” per intenderci, era duplicato, cosa abbastanza anomala.
Il mount point, giusto per la cronaca, è in parole povere la directory radice di un disco o una partizione, viene creata nei sistemi Linux/Unix al momento del caricamento di un volume. Su Mac OS X, ad esempio, se andate a vedere il contenuto della directory “/Volumes” senza alcun disco esterno o partizione montata, questa sarà vuota.
Ma se montate un disco con il nome “DiscoEsterno”, la directory “/Volumes” si presenterà così: “/Volumes/DiscoEsterno/”, e continuando a navigarla troverete tutto il contenuto del disco.
Ovviamente il contenuto di “/Volumes” viene cancellato automaticamente quando si smontano i volumi.
Nel mio caso, avevo una partizione “Services”, quindi una directory “/Volumes/Services” che il sistema per errore non ha cancellato dopo il reboot forzato, ed al riavvio mi sono ritrovato sia la directory “/Volumes/Services”, che la directory “/Volumes/Services1″. Uno dei due ovviamente era un falso.
Questo ovviamente non piaceva alle applicazioni che utilizzavano documenti e librerie contenute nel volume Services.
Spulciando nella preziosa knowledge base di Apple ho trovato spiegazione e soluzione.
Un documento tecnico Apple, tra l’altro recentemente aggiornato, spiega che il problema dei mount pont duplicati dopo un riavvio inaspettato (o brutale come nel mio caso) riguarda tutte le versioni di Mac OS X e Mac OS X Server dalla 10.2 in poi.
Apple fornisce anche le istruzioni per risolvere il problema, io ho preferito la strada del Terminale, riavviando in single-user mode (Mela S all’avvio), e spostando il finto mount point altrove, esempio:
mv /Volumes/falsovolume /
Io mi ero loggato in single-user mode come root, se l’utente root non è attivo credo sia necessario loggarsi almento come utente amministratore, e che occorra aggiungere “sudo” al comando, cosa che richiederà anche la password dell’utente. In pratica il comando diventa così:
sudo mv /Volumes/falsovolume /
Al riavvio successivo, tutto è tornato normale.
nel fine settimana lo provo: ho proprio il disco esterno con il suffisso ’1′
anche a me è successo ma penso sia qualche programma tipo HandBrake o transmit che mi abbia più di una volta creato il disco 1. Adesso però provo anche io con la nota ufficiale.
Beh, non è niente di fantascientifico…
Era capitato anche ad un mio cliente, in questo caso per aver disconnesso un disco esterno: riconnettendolo era stato creato un nuovo mount point (tipo “/Volumes/Disco 1″; a proposito fra il numero e il nome vero l’OS mette uno spazio).
Il risultato è stato che un programma di backup automatico, avendo come disco di backup proprio quello, al momento di eseguire il backup ha chiaramente cercato il disco col nome originario, facendo così il backup nella cartella “Volume/Disco” (se non c’è nulla di montato in quel mount point, non diventa che una semplice cartella). Così a un certo punto mi ha chiamato dicendomi di avere il disco di sistema pieno senza capire perchè.
Avendo sofferto già una simile esperienza con una coppia di terribili MyBook WD da 1 Tb (che si divertivano a sganciarsi allegramente dal sistema…), ho scoperto velocemente l’inghippo.
Comunque non è necessario partire in single user per rimettere a posto tutto: basta accertarsi di aver smontato il disco incriminato, andare in terminale nella cartella Volumes per verificare che il mount point fittizio esista sempre, ed eliminarlo con un bel sudo rm -rd mountpoint.
Esemplificando:
—– con il disco incriminato ancora montato:
% cd /Volumes
% ls -l
drwxr-xr-x 31 admin admin 1122 22 Mag 13:48 Backup mio
drwxr-xr-x 31 admin admin 1122 22 Mag 13:48 Backup mio 1
drwxrwxr-x 79 root wheel 2754 2 Set 2008 Mac OS X
lrwxr-xr-x 1 root admin 1 10 Giu 08:41 Macintosh HD -> /
% mount
/dev/disk2s2 on / (hfs, local, journaled)
/dev/disk1s3 on /Volumes/Backup mio 1(hfs, local, journaled)
/dev/disk2s3 on /Volumes/Mac OS X (hfs, local, journaled)
——
Il mount point “Backup mio 1″ è quello dove si è “riaccasato” il nostro disco esterno, perchè il mount point giusto (“Backup mio”) è rimasto bloccato (ce lo conferma anche il comando “mount”). Verifichiamo espellendo il disco dal Finder o con Utility Disco (per eccesso di sicurezza poi potete anche spegnerlo).
Adesso ricontrolliamo:
—– con il disco incriminato smontato:
% cd /Volumes
% ls -l
drwxr-xr-x 31 admin admin 1122 22 Mag 13:48 Backup mio
drwxrwxr-x 79 root wheel 2754 2 Set 2008 Mac OS X
lrwxr-xr-x 1 root admin 1 10 Giu 08:41 Macintosh HD -> /
% mount
/dev/disk2s2 on / (hfs, local, journaled)
/dev/disk2s3 on /Volumes/Mac OS X (hfs, local, journaled)
——-
Come previsto il mount point “Backup mio 1″ è sparito, e resta la cartella “Backup mio” (nuovamente, abbiamo conferma anche da “mount” che non c’è nulla montato su “Backup mio”); a questo punto possiamo eliminare la cartella fantasma:
——-
% sudo rm -rdf “/Volumes/Backup mio”
(mi raccomando di verificare due volte che il comando sia scritto correttamente, “rm” è un’arma potente e non si fa tante domande su cosa stiamo cancellando; usate le virgolette per racchiudere il percorso, in particolare se contiene spazi)
…dimenticavo, a questo punto ricollegando o rimontando l’hard disk (o partizione) in questione tutto sarà tornato a posto:
% mount
/dev/disk2s2 on / (hfs, local, journaled)
/dev/disk1s3 on /Volumes/Backup mio(hfs, local, journaled)
/dev/disk2s3 on /Volumes/Mac OS X (hfs, local, journaled)
…ovviamente un’occhiatina al contenuto del falso mount point prima della sua eliminazione è consigliabile (qualche programma potrebbe aver scritto nel falso mount point).
tutto sistemato: se il file system del disco esterno è smontato, basta anche un rm -r
ovviamente prima di cancellare il mount point, ho controllato e ci ho trovato circa un giga di roba dentro…
aggiungo che ora spotlight ha ricominciato a mostrarmi i file nel disco quando faccio una ricerca (oltre che per la time machine, nel tera esterno ci metto varie cose), ergo prima faceva riferimento al mount point errato
@naevus
“se il file system del disco esterno è smontato, basta anche un rm -r”
Beh, sì, -rdf è ridondante (-rf un po’ meno), ma mi terrorizza la tua frase… il comando rm _deve_ essere utilizzato a volume smontato, altrimenti ti rasi il volume!!!
lo scrivevo per gli altri: io lavoro abitualmente su macchine unix…
@naevus
Anch’io, ma il fatto che il volume vada smontato vale anche li’… rm non perdona.
a) Benvenuto nel club. Vedo che siamo in ottima compagnia
b) Problemi riguardo ai mountpoint ce ne sono svariati, mica solo quello del duplicato dopo il crash.
c) Ma una parolina sul fatto che Apple stessa ammette candidamente di non aver saputo o voluto risolvere il problema in 7 anni e 4 sistemi operativi, no eh?
@MacRaiser
c) effettivamente basterebbe che all’avvio facesse pulizia dei mount point prima di iniziare il mount dei volumi…
Durante l’uso la cosa è un po’ più complicata, in particolare se nella cartella del mount point ci è finito qualche file. Dovrebbe verificarlo e avvisare l’utente per chiedere il da farsi.
Se abbinasse l’UUID del disco al mount point potrebbe ridurre il problema, ma questo mi creerebbe problemi nel caso avessi due volumi con lo stesso nome da usare in tempi diversi.
La soluzione ideale non è così banale come potrebbe sembrare a prima vista.
@wallybear
Hai ragione. Per non essere stata affrontata e risolta in 7 anni e 4 versioni di sistema, con bilanci miliardari e pletore di ingegneri a disposizione, direi che si deve trattare di un problema pressoche’ insormontabile.