Ein einziges Dateisystem, mit Absicht: exFAT koennen Windows und Linux beide
von Haus aus, es kennt keine Besitzrechte auf dem Datentraeger und hat anders
als FAT32 keine 4-GB-Grenze je Datei. Die Auswahl faellt damit weg - eine
Entscheidung weniger, wenn es schnell gehen muss.
Neu in der Oberflaeche:
Taste v Uebersicht der Laufwerke mit Zustand
Enter darauf haengt am Host ein und startet den Commander - links das
Laufwerk, rechts der eigene Rechner
n / u / l anlegen, aushaengen, loeschen
Optionsmaske Mehrfachauswahl statt Groessenangabe
--transfer NAME dasselbe auf der Kommandozeile, mehrfach moeglich
Am laufenden System durchgespielt: Laufwerk angelegt, vom Host ein Skript
hineingelegt, Wiederherstellung damit gestartet, im Gast gelesen, ausgefuehrt
und geschrieben, Wiederherstellung verworfen - das Laufwerk lebte samt
Ergebnis weiter.
Zwei Rechtefallen dabei gefunden und geschlossen:
Der Gast konnte lesen, aber nicht schreiben. exFAT hat keine Besitzrechte
auf der Platte, die entstehen beim Einhaengen - mit der Vorgabe gehoert
alles root, und der root eines unprivilegierten Containers ist auf dem Host
uid 100000. Wird jetzt mit umask=0000 eingehaengt.
Ein durchgereichtes Laufwerk galt als "am Host eingehaengt", weil beim
Container genau das der Fall ist. Wer das sah, haette es aushaengen und dem
laufenden Gast den Boden wegziehen koennen. Die Belegung wird jetzt auch aus
Container-Konfigurationen gelesen, der Gast hat Vorrang in der Anzeige, und
Aushaengen wird abgelehnt, solange jemand darauf arbeitet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ext4 speichert Besitzer und Rechte auf dem Datentraeger. Das Wurzelverzeichnis
gehoerte root, weil der Host es angelegt hat - im Gast sitzt davor aber ein
gewoehnlicher Benutzer, der dann nichts hineinschreiben kann. Das sieht aus
wie ein schreibgeschuetzter Datentraeger, ist aber eine Rechtefrage.
Das Wurzelverzeichnis wird beim Anlegen jetzt auf 0777 gesetzt - in beiden
Wegen, dem alten --exchange und den neuen Transfer-Laufwerken. Bei exFAT und
FAT laeuft das ins Leere, weil sie ueberhaupt keine Besitzrechte kennen; dort
entscheidet der Einhaengevorgang, und der Automounter im Gast setzt den
angemeldeten Benutzer als Eigentuemer. Genau deshalb ist exFAT auch fuer
Linux-Gaeste die unkompliziertere Wahl.
vorher drwxr-xr-x root -> Benutzer im Gast kann nur lesen
nachher drwxrwxrwx root -> schreiben moeglich
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NTFS wird nicht mehr angeboten und nirgends mehr erwaehnt - exFAT deckt den
Windows-Fall ab, ohne dass etwas nachinstalliert werden muss, das 'fuse' und
damit pve-cluster gefaehrdet. In snapfs.py bleibt ntfs stehen: dort geht es
ums Lesen von Windows-Gast-Snapshots, eine ganz andere Sache.
parted legt nur noch die Partition an, ohne Dateisystem-Hinweis. Dabei ist
aufgefallen, dass genau dieser Hinweis vorher die Typ-Kennung gesetzt hatte:
ohne ihn vergibt parted 0FC63DAF-... ("Linux filesystem"), und Windows haengt
so eine Partition nicht ein. Die Kennung wird jetzt ausdruecklich gesetzt:
parted ... mkpart primary 1MiB 100% set 1 msftdata on
-> EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Nur darauf vergibt Windows von selbst einen Laufwerksbuchstaben.
Das alte --exchange kennt jetzt ebenfalls exfat statt ntfs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
exFAT kann Windows wie Linux nativ, und anders als FAT32 gibt es keine
4-GB-Grenze je Datei. Damit ist es die richtige Vorgabe fuer ein Medium, das
zwischen Host und beliebigen Gaesten pendelt. Fehlt der Formatierer, faellt
die Wahl auf ext4 zurueck.
Dabei ein eigener Fehler aufgefallen: exFAT und FAT lassen nur 11 Zeichen
Datentraegerbezeichnung zu, "PVESNAP-DUMPS" waeren 13 gewesen - mkfs haette
abgebrochen. Die Bezeichnung ist jetzt schlicht der Name in Grossbuchstaben,
je Dateisystem gekuerzt. Im Gast genuegt damit:
mount /dev/disk/by-label/DUMPS /mnt
Geprueft: GPT-Partition mit msftdata-Kennung (dafuer vergibt Windows sofort
einen Laufwerksbuchstaben), blkid meldet TYPE="exfat" LABEL="DUMPS".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Benannte, dauerhafte Austauschmedien zwischen Host und Gast - Abbilddateien
unter /var/lib/pvesnap/transfer, die zu keinem Gast gehoeren und jede
Wiederherstellung ueberleben.
Zwei Entwurfsentscheidungen, beide am Host geprueft:
Datei statt Proxmox-Volume. Ein Volume wuerde beim Entfernen der Maschine
mitgeloescht, auch aus der Weboberflaeche heraus - die vorbereitete
Werkzeugsammlung waere weg. Pfade ueberspringt destroy_vm ausdruecklich
("return if $volid =~ m|^/|"). Nachgestellt: VM mit --purge entfernt, das
Abbild lebte samt Inhalt weiter.
Loop-Geraet statt direktem Pfad. Eine Abbilddatei als scsi3 einzutragen
lehnt Proxmox ab ("unable to associate path to any storage"), /dev/... wird
dagegen durchgereicht. Ueber losetup -P bekommt der Gast eine Platte mit
Partitionstabelle - ohne die zeigt Windows nur "nicht initialisiert".
Verriegelung, am laufenden System geprueft: ein Laufwerk ist entweder am Host
eingehaengt oder an einem Gast, nie beides. Alle drei Wege wurden abgelehnt -
anhaengen waehrend Host-Mount, Host-Mount waehrend angehaengt, loeschen
waehrend in Benutzung. Der Gast-Zustand wird aus den Konfigurationsdateien
gelesen, gilt also auch fuer gestoppte Maschinen.
Installer: parted und exfatprogs werden bei Bedarf nachinstalliert
(--no-install-deps schaltet das ab). ntfs-3g bewusst nicht - apt entfernt
dafuer 'fuse', an dem pve-cluster (/etc/pve) und ceph-fuse haengen. Dazu gibt
es nur einen Hinweis samt Begruendung; fuer Windows ist exFAT ohnehin die
einfachere Wahl.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5