MacBook Pro, Ende 2013, 1 TB SSD (brandneu, kürzlich von Apple ersetzt), APFS (kein Journaling, Groß-/Kleinschreibung wird nicht beachtet), High Sierra 10.13.2, Time Machine zur Netzwerkfestplatte.
no space left on device
.rm
, gotno space left on device
cat /dev/null > somefile
, gotno space left on device
Mit Shift-Command-R in den Wiederherstellungsmodus gebootet (lädt das System aus dem Internet herunter) und Erste Hilfe erneut ausgeführt. Diesmal mit mäßigem Erfolg:
** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0x16309a1): invalid xfields
** Checking the fsroot tree.
fsroot tree is invalid.
** The volume /dev/rdisk2s1 could not be verified completely.
Anscheinend ist der fsroot-Baum ungültig. Ich habe gesucht, konnte aber keine brauchbaren Ratschläge zur Behebung dieses Problems finden (außer natürlich Neuformatierung und Wiederherstellung aus dem Backup, was ich vermeiden möchte).
Auf dem System befindet sich eine Parallels Windows VM mit einer virtuellen 100-GB-Festplatte (ja, eine große Datei), die kürzlich verwendet wurde (daher war ein Backup erforderlich). Bei meiner letzten Nutzung des Rechners waren noch ca. 20 GB auf der macOS-SSD frei. Seit ungefähr einem Tag wurden Time Machine-Sicherungen nicht abgeschlossen, aber es wurde keine Fehlermeldung angezeigt. Als das Problem auftrat, hatte ich die Maschine über Nacht eingeschaltet gelassen, um eine inkrementelle Time Machine-Sicherung durchzuführen. Die Verbindung hier ist, dass Time Machine anscheinend APFS-Snapshots verwendet. Ich vermute, dass dies die Hauptursache dafür ist, warum dieses Durcheinander passiert ist.
Danke.
Beim Ausführen fsck_apfs
mit dem Debug-Flag -d
enthält die Ausgabe etwas mehr Informationen:
** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0x16309a1): invalid xfields
obj-id: 23267745 type: Inode
private-id: 23267745 parent-id: 12896552 cr/mtime: 1515089959653928186/1515090145416398252
def-prot-class: 0
uid/gid/mode: 0/0/0x8180 bsd_flags: 0x0 internal_flags: 0x8280 name: NO-NAME
** Checking the fsroot tree.
fsroot tree is invalid.
** The volume /dev/disk2 could not be verified completely.
Ich bin gerade auf ein ähnliches Problem gestoßen. Wahrscheinlich hätten Sie festgestellt, dass das Problem in einer der Dateien für die Parallels VM lag - zumindest war das in meinem Fall der Übeltäter. Ihr fsck_apfs -d /disk/<disk>
Scheck wurde zurückgegeben:
obj-id: 23267745 type: Inode
Wenn Sie das Terminal geöffnet hätten, hätten Sie den Pfad zu der Datei (oder den Dateien) mit diesem Inode mit dem folgenden Befehl erhalten können:
find / -inum 23267745
Von dort aus hätten Sie gewusst, welche Datei(en) wiederhergestellt werden müssten, anstatt eine vollständige Wiederherstellung durchzuführen.
In meinem Fall war die VM-Datei nur im Snapshot verfügbar, da ich meine VMs von TimeMachine ausschließe. Ich habe nur diese Datei aus einem früheren Snapshot wiederhergestellt und bin durch fsck_apfs weitergekommen - es kam durch die Festplatte, um Snapshots zu überprüfen, und bombardierte dann dieselbe Datei im 2. Snapshot. Glücklicherweise werden Schnappschüsse nur für höchstens 24 Stunden aufbewahrt, also sollte es nach diesem Zeitpunkt aufräumen.
Ihr Kilometerstand kann jedoch variieren, da es so "einfach" wie eine Datei oder nur die Spitze des Eisbergs sein kann.
Mike Wills
Hendrik
gctwnl