An einem Macbook 1,83/2GB 10.6.8 der ersten Generation hängt an einem Port eine USB-Platte als TimeMachine-volume. Ich stellte gerade wieder einmal fest, dass seit geraumer Zeit kein TimeMachine-Backup mehr gemacht worden ist. Bei näherem Hinsehen stellte ich fest, dass die USB-Platte auch nicht mehr auf dem Schreibtisch sichtbar war, was sie normalerweise ist. Sie dreht jedoch noch. Wenn ich sie dann abziehe und wieder anstöpsele, wird sie auf dem Schreibtisch wieder sichtbar und TimeMachine fängt mit seiner Arbeit an.

Wie kann ich feststellen, warum dieses "Unmounten" passiert? Wie kann ich es verhindern?

Das hängt mit USB zusammen, wenn der Mac in den Ruhezustand geht. Beim Aufwachen wird die Platte nicht mehr automatisch gemountet, dreht jedoch weiterhin, wenn sie eine eigene Stromversorgung hat (normalerweise 3,5"-HD). In der Regel kommt die Meldung, dass die Platte nicht ordnungsgemäß ausgeworfen wurde.

Manche Laufwerke können automatisch aufwachen, manche nicht, das hängt auch von der Laufwerk/HD-Kombination ab. Am sichersten die Platte abmelden (unmounten), bevor der Ruhezustand aktiviert wird.

Bei 2,5"-Platten kann das ebenso auftreten, sie drehen allerdings nicht mehr, wenn die Stromversorgung per USB erfolgt.

Der Rechner geht nie schlafen, sondern läuft durch.

schau mal bei optionen/strom in Systemeinstellungen…Platte wenn möglich in den Ruhezustand versetzen…an sowas kann es scheitern, wenn irgendeine 0815 Platte rumspackt…ggf. warten auf 10.9.4

Bei dem Rechner läuft 10.6.8 und "Wenn möglich, Ruhezustand der Festplatte(n) aktivieren" ist nicht angeklickt.

Bus-powered oder mit eigenem Netzteil? Falls ersteres, wenn wirklich MacBook ohne Pro und erste Generation dann hast Du die Ursache evtl. schon gefunden (zu wenig Saft. "Extra Power" an USB kam erst ab 2007)

Mittels Konsole.app müsste zumindest das Unmounten der Platten verfolgbar sein, kaum aber die Ursache, wenn's an der Platte, deren Controller oder der Stromversorgung liegt.

Ich tippe ja auf eine externe Western Digital die per USB angeschlossen ist.
Je nach Typ geht diese nach ca 10 min automatisch in den Standby. Nur leider
funktioniert das Aufwecken nicht immer wie gewünscht und das Feature lässt sich
auch nicht deaktvieren. Schön wenn der TE mal mehr Daten geben würde,
welche externe HD in welchem Gehäuse da angeschlossen ist.
Hersteller/Baujahr etc. dann müsste man nicht immer die Glaskugel bemühen.

Und das führt zu dem Zustand "Sie dreht jedoch noch"? Was für Variante von Standby setzt WD da um?

Gehäuse ist Icybox, das mit dem milchigen Aufklappdeckel; Platte ist Samsung 320GB HMJI, oder wie die hiessen.

Jetzt wollte ich mich gerade als admin anmelden, um in der Konsole das system.log zu sehen, da sehe ich, wie kurzzeitig die, am anderen USB-Port über einen USB-Hub angeschlossene Platte vom Schreibtisch verschwindet, rote Meldune ("Festplatte nicht richtig abgemeldet….") kommt, drei Sekunden später sie wieder da ist. Das war ungefähr um 12:07 Uhr. Log aus der Konsole steht unten. Ansonsten tue ich alles, was Ihr sagt. Eventuell ist es ja auch die Hardware des in die Jahre gekommenen Rechners.

20.03.14 12:07:30 mds[48] (Error) Task: <MDSFetchTask: 0x307fe70>{taskID:0x00006009 age:<1ms} couldn't fetch attributes: (os/kern) object terminated
20.03.14 12:07:30 SystemUIServer[186] Invalid kMDItemPath for (null)
20.03.14 12:07:31 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7bd09b69 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:31 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:32 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7bd09b69 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:32 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:33 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:33 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:33 fseventsd[53] read_disk_log: problems with history file: /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (fd -1, errno 6 ; is_reg 0; uid 0/0 gid 0/0)
20.03.14 12:07:39 fseventsd[53] event logs in /Volumes/Smilie/.fseventsd out of sync with volume. destroying old logs. (785201 1 788450)
20.03.14 12:07:46 com.apple.kextcache[20737] /Volumes/Smilie locked; waiting for lock.
20.03.14 12:07:46 fseventsd[53] log dir: /Volumes/Smilie/.fseventsd getting new uuid: FCCA35E4-9B99-4AFC-8748-823613E9B02A
20.03.14 12:07:46 fseventsd[53] disk logger: failed to open output file /Volumes/Smilie/.fseventsd/636573ab7be6b6b9 (No such file or directory). mount point /Volumes/Smilie/.fseventsd
20.03.14 12:08:05 com.apple.kextcache[20736] JMicronATA.kext does not declare a kernel dependency; using com.apple.kernel.6.0.
20.03.14 12:08:06 postfix/master[20744] daemon started -- version 2.5.14, configuration /etc/postfix
20.03.14 12:08:06 postfix/pickup[20745] EFDEB1457136: uid=70 from=<_www>
20.03.14 12:08:07 postfix/cleanup[20747] EFDEB1457136: message-id=<projekte2051_210020892089_pumpenrev1395313686@colibri.7eheiner.macbook-2gb.local>
20.03.14 12:08:07 postfix/qmgr[20746] EFDEB1457136: from=<_www@macbook-2gb.fritz.box>, size=6793, nrcpt=1 (queue active)
20.03.14 12:08:07 com.apple.backupd[20752] Starting standard backup
20.03.14 12:08:07 postfix/smtp[20749] EFDEB1457136: to=<virk@gmx.net>, relay=mx00.emig.gmx.net[213.165.67.114]:25, delay=0.76, delays=0.35/0.08/0.29/0.05, dsn=5.0.0, status=bounced (host mx00.emig.gmx.net[213.165.67.114] said: 550-Requested action not taken: mailbox unavailable 550 invalid DNS A/AAAA resource record (in reply to MAIL FROM command))
20.03.14 12:08:07 postfix/cleanup[20747] 8BF8B145713A: message-id=<20140320110807.8BF8B145713A@macbook-2gb.fritz.box>
20.03.14 12:08:07 postfix/qmgr[20746] 8BF8B145713A: from=<>, size=8806, nrcpt=1 (queue active)
20.03.14 12:08:07 postfix/bounce[20753] EFDEB1457136: sender non-delivery notification: 8BF8B145713A
20.03.14 12:08:07 postfix/qmgr[20746] EFDEB1457136: removed
20.03.14 12:08:07 postfix/local[20754] 8BF8B145713A: to=<_www@macbook-2gb.fritz.box>, relay=local, delay=0.12, delays=0/0.1/0/0.02, dsn=5.2.2, status=bounced (cannot update mailbox /var/mail/_www for user _www. error writing message: File too large)
20.03.14 12:08:07 postfix/qmgr[20746] 8BF8B145713A: removed
20.03.14 12:08:08 com.apple.backupd[20752] Backing up to: /Volumes/Zwischenlager/Backups.backupdb
20.03.14 12:08:21 com.apple.kextcache[20736] Created mkext archive /Volumes/Smilie/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext.
20.03.14 12:08:21 com.apple.kextcache[20732] /Volumes/Smilie: no supported helper partitions to update.
20.03.14 12:08:21 com.apple.kextcache[20737] Lock acquired; proceeding.
20.03.14 12:08:21 com.apple.kextcache[20737] /Volumes/Smilie: no supported helper partitions to update.
20.03.14 12:08:58 com.apple.backupd[20752] No pre-backup thinning needed: 5.64 GB requested (including padding), 21.13 GB available
20.03.14 12:09:06 postfix/master[20744] master exit time has arrived
20.03.14 12:09:41 mdworker[20705] kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
20.03.14 12:10:27 postfix/master[20769] daemon started -- version 2.5.14, configuration /etc/postfix
20.03.14 12:10:27 postfix/pickup[20770] E3FF21457192: uid=70 from=<_www>
20.03.14 12:10:27 postfix/cleanup[20772] E3FF21457192: message-id=<projekte2051_210020892089_pumpenrev1395313827@colibri.7eheiner.macbook-2gb.local>
20.03.14 12:10:27 postfix/qmgr[20771] E3FF21457192: from=<_www@macbook-2gb.fritz.box>, size=6917, nrcpt=1 (queue active)
20.03.14 12:10:28 postfix/smtp[20774] E3FF21457192: to=<virk@gmx.net>, relay=mx01.emig.gmx.net[213.165.67.115]:25, delay=0.6, delays=0.2/0.04/0.3/0.06, dsn=5.0.0, status=bounced (host mx01.emig.gmx.net[213.165.67.115] said: 550-Requested action not taken: mailbox unavailable 550 invalid DNS A/AAAA resource record (in reply to MAIL FROM command))
20.03.14 12:10:28 postfix/cleanup[20772] 763EA1457196: message-id=<20140320111028.763EA1457196@macbook-2gb.fritz.box>
20.03.14 12:10:28 postfix/qmgr[20771] 763EA1457196: from=<>, size=8930, nrcpt=1 (queue active)
20.03.14 12:10:28 postfix/bounce[20777] E3FF21457192: sender non-delivery notification: 763EA1457196
20.03.14 12:10:28 postfix/qmgr[20771] E3FF21457192: removed
20.03.14 12:10:28 postfix/local[20778] 763EA1457196: to=<_www@macbook-2gb.fritz.box>, relay=local, delay=0.04, delays=0/0.03/0/0, dsn=5.2.2, status=bounced (cannot update mailbox /var/mail/_www for user _www. error writing message: File too large)
20.03.14 12:10:28 postfix/qmgr[20771] 763EA1457196: removed
20.03.14 12:11:27 postfix/master[20769] master exit time has arrived
20.03.14 12:12:29 com.apple.backupd[20752] Copied 11575 files (99.6 MB) from volume Macintosh.
20.03.14 12:12:45 com.apple.backupd[20752] No pre-backup thinning needed: 5.58 GB requested (including padding), 21.02 GB available
20.03.14 12:13:24 com.apple.backupd[20752] Copied 9053 files (48.8 MB) from volume Macintosh.
20.03.14 12:13:58 com.apple.backupd[20752] Starting post-backup thinning
20.03.14 12:14:14 com.apple.backupd[20752] Deleted backup /Volumes/Zwischenlager/Backups.backupdb/Macbook_2GB/2014-03-12-230822: 21.02 GB now available
20.03.14 12:14:22 com.apple.backupd[20752] Deleted backup /Volumes/Zwischenlager/Backups.backupdb/Macbook_2GB/2014-03-12-220802: 21.02 GB now available
20.03.14 12:14:29 com.apple.backupd[20752] Deleted backup /Volumes/Zwischenlager/Backups.backupdb/Macbook_2GB/2014-03-12-210802: 21.03 GB now available
20.03.14 12:14:39 com.apple.backupd[20752] Deleted backup /Volumes/Zwischenlager/Backups.backupdb/Macbook_2GB/2014-03-12-200900: 21.03 GB now available
20.03.14 12:14:47 com.apple.backupd[20752] Deleted backup /Volumes/Zwischenlager/Backups.backupdb/Macbook_2GB/2014-03-12-190804: 21.03 GB now available
20.03.14 12:14:47 com.apple.backupd[20752] Post-back up thinning complete: 5 expired backups removed
20.03.14 12:14:48 com.apple.backupd[20752] Backup completed successfully.

Hatte so ein Problem auch schonmal, da war es das defekte USB Kabel.
Nimm mal ein neues USB2.0 zertifiziertes Kabel, also was hochwertiges
mit guter Abschirmung. Und nicht länger als nötig !
Welche IcyBox ist es denn ? vllt. gibt es ja dafür ein
Firmwareupdate. btw. wie alt ist das Gehäuse, kann ja auch sein das
es nur das Gehäuse ist, das den Geist aufgibt und die Platte noch soweit
i.O. ist.

@Thomas Kaiser... manchmal ist es auch nur der Lüfter der noch dreht und man denkt es sei die HDD... daher Glaskugel...ohne Info welche Hardware seinen Dienst verrichtet,
kann man leider wirklich nur auf Verdacht Tipps geben

Oder evtl. was anderes. Dein Log gibt leider so gut wie gar nix her, grad in Zusammenhang mit der Beschreibung. Es gibt also zwei Volumes, eines heißt Smilie, eines Zwischenlager. Auf "Zwischenlager" sollen wohl die Backups gemacht werden, das andere müsste dann das gewesen sein, das ca. 12:07 ausgeworfen wurde?

Schau mal, ob Du in 10.6 noch ein /var/log/diskarbitrationd.log findest, falls ja, lohnt evtl. ein Blick da hinein. Ansonsten hast Du irgendwas im System, das fröhlich Mails verschicken will aber nicht kann. Und die nicht versendeten Mails noch nicht mal mehr lokal speichern kann, weil "Mailbox full":

Du kannst mal per "postconf -d | grep size_limit" schauen, was das Mailbox-Limit ist. Aber normalerweise sollten das 50 MByte sein und dann sind das wohl häßlich viele Mails, die bei Dir da schon als nicht zustellbar drinnen stehen. BTW: Für Logfiles tauglicher dürfte es sein, die bei pastebin.com abzukippen und einen Link hierher zu posten.

Schon mal danke soweit. Das var/mail/_www ist 51,2MB gross, genauso groß wie mailbox_size_limit, siehe unten:

macbook-2gb:~ Heiner$ postconf -d | grep size_limit
body_checks_size_limit = 51200
bounce_size_limit = 50000
header_size_limit = 102400
mailbox_size_limit = 51200000
message_size_limit = 10240000
macbook-2gb:~ Heiner$

Kann/darf ich das file "einfach" löschen?

"/var/log/diskarbitrationd.log" gibt es nicht.

Klar, aber das ist halt völlig sinnlos und nicht nur bisserl sinnlos wie meist bei Symptombekämpfung. Weil anschl. werden immer noch Mails nicht zugestellt, das Mailbox-File wächst wieder, bis es 50 MByte groß ist und dann ist der jetzige Zustand wieder 1:1 hergestellt.

Die Mails kommen vom Account _www (also wohl 'ne Webanwendung, die auf der Kiste läuft), die Message-ID lautet "projekte2051_210020892089_pumpenrev1395313686@colibri.7eheiner.ma cbook-2gb.local" (das könnte Hinweise auf die Anwendung geben) und die Mail sollte an virk@gmx.net zugestellt werden, was aber aufgrund DNS-Geschissel nicht geklappt hat.

Und entweder es steht in den Mails was Interessantes drin (dann würde ich versuchen, die Zustellung an Deine GMX-Adresse hinzubekommen) oder nicht (dann würde ich die Mails gar nicht erst von der Webanwendung abschicken lassen).

Schade. Dann auch keine Idee mehr abseits rmayergfx' Hinweisen bzgl. Hardware. Wenn das Phänomen mit beiden Platten auftritt, die aber nicht am selben Hub hängen, dann würde ich aber vom Gefühl her eigentlich das Problem eher an/im MacBook bzw. dessen USB-Controller verorten.

Die mails werden von dokuwiki verschickt. Das ist ein wiki, was hier auf der Schüssel läuft. Ich werde das besagte file gleich löschen und dann mal beobachten und ggf. mitteilen.

…
Das Problem trat mindestens einmal sowohl an einer Platte auf, die direkt an einem USB-Port hing als auch an einer anderen Platte, die über einen Hub am anderen Port hing. Ich stocher' weiter im dunkeln Es ist nicht lebenswichtig; wenn der mal down ist für ein paar Stunden, bringt das hier keinen um.

Was auch immer das bringen soll

Im Ernst: GMX nimmt diese Mails nicht an, weil es mit dem Absender bzw. dem Domainpart der Absendeadresse "_www@macbook-2gb.fritz.box" nix anfangen kann: "550-Requested action not taken: mailbox unavailable 550 invalid DNS A/AAAA resource record (in reply to MAIL FROM command". Also entweder in Dokuwiki geradedengeln, in postfix fixen oder Mailzustellung deaktivieren.

Mir ist vorhin eingefallen, dass 'ne Freundin über ähnliche Symptome klagte. Kater war schuld, der immer über das MacBook samt USB-Stecker gestiefelt ist... abseits Tierreich: Evtl. mechanische Einwirkungen an den Steckern, die ursächlich sein können?

Naja, vorsicht: Wenn ein TM-Volume wiederholt "unsanft" ausgeworfen wird, dann können sich kleine Dateisystemfehler irgendwann zu einem großen aufsummieren bzw. das Ganze eher eskalieren. Und gemäß Murphy's Law passiert sowas genau dann, wenn Du das Backup mal brauchst. Wenn die Daten auf der Dulle irgendwie wichtig sind, würd ich ja mal die Firewire-Variante ausprobieren, ob das stabiler läuft...

Naja, erstens bleibt der Thread am leben und zweitens steht jetzt nach erneutem Versuch in eben dieser Datei näheres aktuelles. Ich bin bereits vonne Arbeit weg und zuhause, weiß also Montag erst mehr.

Ein solches Problem halte ich für unwahrscheinlich mit der Folge, dass ich danach zunächst nicht auf die Suche gehe. Der Rechner steht irgendwo inner Ecke auf'm Fußboden wo keiner dran kommt.

Ich nehme das zum Anlass, mal eben zu fragen, wie ich ein TimeMachine-volume auf "Korrektheit" testen kann. Langt es oder macht es Sinn, das Festplattendienstprogramm drüber laufen zu lassen: Findet das FPDP "die meisten Fehler"?

TimeMachine ist kein Backup…das macht man zusätzlich im Wochen oder Monatsrythmus

Ah, schön. Das war mein persönlicher "Bullshit des Tages". Wenn man TimeMachine mit rotierenden Medien betreibt, ist man verdammt nah am perfekten Backup dran. Im Gegensatz zu dem ganzen Klon- und Sync-Quatsch, der andere Szenarien abzufedern in der Lage ist aber nix mit Backup zu tun hat. Wobei... bei Dir weiß man ja leider nie, was eigentlich die Aussage gewesen sein soll...

Da TM komplett auf Datenträger und Filesystem basiert, reicht es bereits völlig, die Intaktheit des Dateisystems zu prüfen. Ergo: Festplattendienstprogramm drauf loslassen. Meines Wissens hat der backupd (also das Dings, das sichern soll) seit einigen OS X Versionen es auch schon von Haus aus drauf, grob auf "unsaubere" Dateisysteme zu prüfen und im Zweifel einen fsck anzuschmeißen -- zumindest bei "TM übers Netzwerk", das ja deutlich fragiler als auf direkt angeschlossene Platten ist (mehr als 'nen fsck -- File System ChecK -- macht das Festplatten Dienstprogramm ja auch nicht)

Auch viel Quark wird kein Guter Quark.

Nur weil dir diese Vorgehensweise nicht schmeckt…Alter Falter.

Du hast auch die Weißheit mit dem Löffel gefressen, komischer switcher

Bei sehr vielen Lebensmittelzubereitungen kann man durchaus davon ausgehen, daß größere Mengen die Qualität verbessern oder zumindest sicherstellen, daß der Ablauf wie gewünscht funktioniert. Apfelsaft etwa vergärt in großen Behältern so gut wie sicher zu einem geschmackvollen Stöffchen, in Kleinmengen dagegen besteht die große Gefahr, daß sich Fremdhefen und Bakterien vermehren und das Getränk umkippt. Auch Quark entsteht durch mikrobielle Prozesse.


Natürlich ist TimeMachine kein Backup, es ist ein Programm, das ein Backup anlegt.