[10.7 Lion] Netzwerklaufwerk lässt sich nicht trennen (Ausschalten geht auch nicht)

[gkroadking]

Hi,

bin neu hier und habe folgendes Problem mit meinen neuen MBA 13" late 2011; ich nutze ihn häufig mit iTunes für meine Musikbibliothek für die Familie (4 x iPhone 4 und 1 x iPAD2) sowie Logitech Squeezebox. Als Netzwerk-Drive für meine Musikfiles habe ich eine WD MyBook Live 2TB (WDBACG0020HCH) im Einsatz; und hier liegt mein Problem. Ich verbinde den MBA über afp mit dem Drive, auf dem der iTunes alles findet (Library, Musicfolder, Video etc.). das funktioniert soweit aber langsam. Wenn ich nach Nutzung mein Drive auswerfen will weigert sich das System diese auszuwerfen. Im Finder wird die Festplatte immer gezeigt.
Beim ausschalten weigert sich das System runter zufahren; der Sreen wird hellgrau und das Windrad läuft bis der Akku leer ist
Hier bleibt dann nur der Kill über Ausschalttaste (lange drücken)...NERVT!! :-c

Gibts irgendwelche Tipps? Firmware der WD ist aktuell, ebenso das OS-X

Danke

Chaos-gerhard

 

[fyysh]

Irgendwas greift auf die Platte zu und verhindert das auswerfen. Vielleicht sollte man erst herausbekommen, was das ist.

Im Terminal (/Programme/Dienstprogramme/Terminal.app) bekommst du das mit folgendermaßen heraus:

Zunächst musst du den Mountpoint kennen. Dazu gibst du den folgenden Befehl ein und bestätigst mit der Eingabetaste:

mount[code]

Als Beispiel: 
Ich suche den Mountpoint meines Mediathek-Shares auf meiner NAS kennen. Die wird mit im Finder als "mediathek@orion" angezeigt.
[code]fyysh@perseus: ~$> mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
localhost:/5Xx3SnBcbcdhIdKb9VJZ5g on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)
afp_1BNCPj4zmyT33D5roN4buWhw-15.3000007e on /Volumes/mediathek@orion (afpfs, nodev, nosuid, mounted by fyysh)

In der letzten Zeile sehe ich, dass die auf /Volumes/mediathek@orion gemounted ist (das ist Standard).

Jetzt will ich wissen, was auf /Volumes/mediathek@orion zugreift und nutze dafür folgenden Befehl:

lsof "/Volumes/mediathek@orion"

Beispiel:

fyysh@perseus: ~/Downloads/DL-INBOX
$> lsof /Volumes/mediathek@orion
COMMAND     PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
Path\x20F 29602 fyysh    6r   DIR 48,126      264    2 /Volumes/mediathek@orion

Bei dir müssten dann mehr als nur das ausgegeben werden.

Hier mal ein Beispiel wenn ich auf das Share zugreife (ich könnte es jetzt nicht auswerfen):

fyysh@perseus: ~/Downloads/DL-INBOX
$> lsof /Volumes/mediathek@orion
COMMAND     PID  USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
bash       7385 fyysh  cwd    DIR 48,126      264      2 /Volumes/mediathek@orion
Path\x20F 29602 fyysh    6r   DIR 48,126      264      2 /Volumes/mediathek@orion
tail      38737 fyysh  cwd    DIR 48,126      264      2 /Volumes/mediathek@orion
tail      38737 fyysh    3r   REG 48,126        0 126695 /Volumes/mediathek@orion/test

 

[gkroadking]

Danke für die ausführliche Anleitung dazu... Ich werde das heute abend durchspielen (muss jetzt leider Geld verdienen)

Feedback folgt.

Kompliment an das Forum; rasche Hilfe

 

[thrillseeker]

Ich greife den Thread mal auf, da wir hier dieselben Probleme haben. In einer Arbeitsgruppe mit Windows-, Mac- und Linux-Rechnern tauschen wir Dateien über ein NAS aus. Auf den Macs greifen wir über AFP zu.

Das Problem: Ein "normales" Auswerfen der Volumes über den Finder schlägt häufig (aber nicht immer) fehl:

• das Laufwerks-Icon verbleibt auf dem Desktop, wird aber grau dargestellt
• das Laufwerk bleibt in /Volumes gemountet

Der Prozess des Auswerfens scheint zu hängen, denn ein Neustart des Rechners ist nicht möglich. Force-Unmount übers Terminal schlägt ebenfalls fehl (der Prozess bleibt hängen und lässt sich auch nicht über ctrl-c abbrechen). Einziges Workaround ist das Trennen der Netzwerkverbindung (Airport ausschalten oder Kabel abziehen).

Die Konsole meldet dazu tausendfach:

kernel: AFP_VFS afpfs_DoReconnect:  Max reconnect time: 30 secs, Connect timeout: 15 secs for /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  connect to the server /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  Logging in with uam 8 /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  Restoring session /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  get the reconnect token

Was kann man da tun?

 

[thrillseeker]

Ich greife den Thread mal auf, da wir hier dieselben Probleme haben. In einer Arbeitsgruppe mit Windows-, Mac- und Linux-Rechnern tauschen wir Dateien über ein NAS aus. Auf den Macs greifen wir über AFP zu.

Das Problem: Ein "normales" Auswerfen der Volumes über den Finder schlägt häufig (aber nicht immer) fehl:

• das Laufwerks-Icon verbleibt auf dem Desktop, wird aber grau dargestellt
• das Laufwerk bleibt in /Volumes gemountet

Der Prozess des Auswerfens scheint zu hängen, denn ein Neustart des Rechners ist nicht möglich. Force-Unmount übers Terminal schlägt ebenfalls fehl (der Prozess bleibt hängen und lässt sich auch nicht über ctrl-c abbrechen). Einziges Workaround ist das Trennen der Netzwerkverbindung (Airport ausschalten oder Kabel abziehen).

Die Konsole meldet dazu tausendfach:

kernel: AFP_VFS afpfs_DoReconnect:  Max reconnect time: 30 secs, Connect timeout: 15 secs for /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  connect to the server /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  Logging in with uam 8 /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  Restoring session /Volumes/Volume-Name
kernel: AFP_VFS afpfs_DoReconnect:  get the reconnect token

Was kann man da tun?

EDIT: Beim nächsten Auftreten des Problems werde ich den Tipp mit lsof probieren, um herauszufinden, welcher Prozess das Auswerfen verhindert. TimeMachine habe ich nicht aktiviert, aber vielleicht ist Spotlight der Übeltäter …

 

[thrillseeker]

Update: Als ich das Problem heute wieder hatte, habe ich mal über den Verbindungsmonitor von LittleSnitch sämtliche Verbindungen zum NAS anzeigen lassen und diese dann nacheinander übers Terminal gekillt.

Ergebnis: Nachdem alle anderen Prozesse zwangsweise beendet waren, verblieb nur noch mach_kernel als Übeltäter. Der lässt sich aber bekanntermaßen schlecht killen.

Fazit:

Wir stehen selbst enttäuscht und seh'n betroffen
den Vorhang zu und alle Fragen offen.

(Brecht)