Der GNU/Linux-Thread

[The Poet]

Soweit schon mal vielen Dank, werte Kollegen, für den Input...

- ich hab beruflich ein paar hundert Debian Systeme mit unter meiner Fuchtel

+1

Wie behält man da den Überblick?

vorweg: ich glaube eine konkrete Empfehlung von mir wäre wenig hilfreich, deswegen gebe ich auch keine pauschale. aber ein paar Hinweise:

-die C'T hatte da kürzlich ein Titelthema zu

Ja, danke, die ist mir auch schon untergekommen ... und ich hatte sogar das Heft gekauft (bzw. das war doch die mit der "Subway map", oder?)... muss ich mal wieder rauskramen.

- ein Kollege schwört auf Arch(allerdings für seinen Desktop, wo man eher neuere Software braucht, für die man in Debian zusätzliche Repos braucht. Arch im Servereinsatz ist mir jetzt noch nicht begegnet, aber ich hab auch nicht so viel mit Servern am Hut. die wirklich großen Installationen betreuen andere Abteilungen.
- generell ist in meinen Augen der Geschmack wichtiger, als technische Details. wenn man in einer Distri fit ist, googelt sich ein Problem auch leichter

Denke auch (@Unterstrichenes), vielleicht nehm ich für den Server was altbekanntes und werd dann später mal auf einem Test-Desktop in Arch oder Fedora reinschnuppern.

Reines Debian (ohne GUI)

wie es sich für einen richtigen Nerd gehört.

Ach und ganz ohne GUI muss auch nicht sein, so ein Xfce/LXDE/LXQt braucht wenig Ressourcen und macht das Arbeiten doch angenehmer...

Jap, wohl wahr. Welche von diesen ressourcenschonenden Lösungen sieht denn deiner Meinung nach am hübschesten aus? ^^ Das Auge isst ja bekanntlich auch mit (anders als der Kannibale, der isst das Auge mit ).

[halbkaputt]

- ich hab beruflich ein paar hundert Debian Systeme mit unter meiner Fuchtel

+1

Wie behält man da den Überblick?

da könnte man Seitenlang drüber schreiben, da es enorm viele Aspekte gibt, was den Rahmen hier sprengen würde. deswegen so viel:

Automatisierung, Automatisierung, Automatisierung, Automatisierung und Standardisierung
um ein profanes Beispiel zu nehmen: die Timezone:
mit Servern und VMs auf verschiedenen Kontinenten will man die Syslogs alle in UTC haben. das kann man jetzt entweder überall manuell konfigurieren, oder ein System benutzen, dass das global überall ausrollt. im Idealfall hätte man dazu eine CMDB in der man den Standard setzt und im deployment wird das überall ausgerollt. in der Realität hat man gewachsene Strukturen und dann hat man z. B. für einige Teile ein deployment System(in dem Fall Ansible, teilweise über goCD) und für andere Aspekte wieder was anderes(in em Fall Puppet), was aber eigentlich schon wieder problematisch ist, weil inkonsistenzen auftreten können und um den Bogen zur Automatisierung zu schliessen: ein selbstgeschriebenes System, dass SSH keys von Leuten runterwirft, die gekündigt haben und Neueinstellungen einträgt. und. die Systeme müssen nur so weit installiert sein, dass Automatisierungslösung draufkommt und einen "known good"-Zustand herstellt und evtl. kaputte configs überbügelt

vorweg: ich glaube eine konkrete Empfehlung von mir wäre wenig hilfreich, deswegen gebe ich auch keine pauschale. aber ein paar Hinweise:

-die C'T hatte da kürzlich ein Titelthema zu

Ja, danke, die ist mir auch schon untergekommen ... und ich hatte sogar das Heft gekauft (bzw. das war doch die mit der "Subway map", oder?)... muss ich mal wieder rauskramen.

richtig! die Map wird auch in dem c'tUplink Podcast Video, das auf der Seite eingebettet ist, eingeblendet. das Heft hatte ich selbst gar nicht gelesen, trotz das ich Abonent bin, aber die Uplink-Folge gesehen. im Heft werden aber noch mehr Infos stehen

[Mit müden Augen]

Ach und ganz ohne GUI muss auch nicht sein, so ein Xfce/LXDE/LXQt braucht wenig Ressourcen und macht das Arbeiten doch angenehmer...

Jap, wohl wahr. Welche von diesen ressourcenschonenden Lösungen sieht denn deiner Meinung nach am hübschesten aus? ^^ Das Auge isst ja bekanntlich auch mit

Schönheit liegt im Auge des Betrachters... Die Frage ist was dir gefällt und wie viele Ressourcen du auf dem Server hast (ein ausgewachsenes Tier oder eine Himbeere?). Als ich damals rumprobiert habe war LXDE am sparsamsten aber auch irgendwie spartanisch, gefolgt von Xfce. LXQt kenne ich gar nicht. Ich nutze auf meinem Desktop Xfce weil das einfach funktioniert ohne viel unnötiges Zeug das nur Rechenleistung verbrät... Allerdings ist das Standardtheme unter Deb11 irgendwie ziemlich grau und depressiv, müsste ich mal ändern, naja, müsste...

(anders als der Kannibale, der isst das Auge mit ).

[uhu72]

LXQt ist die Weiterentwicklung von LXDE auf Basis des GUI Tollkit Qt. LXDE basiert noch auf GTK+2, das wird also irgend wann sterben, denke ich. GTK+3 ist nicht ganz so resourcenschonend und nicht abwärtskompatible.

[Mit müden Augen]

Ok, also wenn dann LXQt... Qt kenne ich vom Namen, kommt das nicht ursprünglich von Nokia oder schmeiße ich da irgendwas total durcheinander??

[Mit müden Augen]

Wie, kein Nerd der sich freut dass Nvidia seine Graka-Treiber als FLOSS veröffentlicht hat? heise und Co müssen darüber doch groß berichtet haben? (Ich will heise nicht aufrufen, tut mir nie gut... )

[halbkaputt]

Wie, kein Nerd der sich freut dass Nvidia seine Graka-Treiber als FLOSS veröffentlicht hat? heise und Co müssen darüber doch groß berichtet haben? (Ich will heise nicht aufrufen, tut mir nie gut... )

Fefe hat ein wenig darüber geschrieben. der hat zwar nicht die Reichweite wie Heise, aber gerade unter Nerds nicht unwesentlich. Ich für meinen Teil benutze Desktop-Linux nur auf dem Arbeitslaptop(der integrierte Intelgrafik hat) und daher find ich es prinzipiell gut, tangiert mich aber nicht sonderlich

[Mit müden Augen]

Sagt mal ihr Nerds, kann man udisk2 oder wem-auch-immer beibringen bei extern angestöpselten Festplatten/USB-Sticks mit ext4 und Co den Besitzer vom Dateisystem zu ignorieren, so dass $mmA die Platte nicht nur per Klick in PCManfm mounten kann sondern auch tatsächlich darauf schreiben? Für "alte" Dateisysteme wie FAT funktioniert das weil die keinen Besitzer im Dateisystem speichern, aber bei ext4 ist das anders. Das Problem ist eigentlich der Besitzer vom mountpoint, aber der (Ordner unter /media/$mmA) wird erst beim Einstöpseln automatisch erzeugt und dann wieder gelöscht, also nix mit ein einziges Mal chown. Klar, könnte ich jedes Mal machen, aber dazu muss ich ja erst wieder root werden und genau das will ich vermeiden. Der Versuch udisks2 per config-Datei eine fixe UID mitzuteilen ist mit einem "error ... not allowed" gescheitert, das geht offensichtlich für ext4 nicht.

Im aktuellen Fall habe ich den USB-Stick einfach neu formatiert und mkfs.ext4 meine UID mitgegeben, aber das kann ja nicht die Lösung sein, vor allem wenn ich mal fremde Sticks/Platten mit ext4 habe.

Ich meine unter Deb10 hatte ich das Problem nicht oder waren da alle meine externen Datenträger noch als FAT formatiert?

???

[Versingled]

Ich meine unter Deb10 hatte ich das Problem nicht oder waren da alle meine externen Datenträger noch als FAT formatiert?

Mountverzeichnis anlegen und $mmA als Eigentümer geht nicht? Ich habe allerdings wenig mit Anstöpselplatten zu tun.

[Mit müden Augen]

Wie meinst du das? Die Mountverzeichnisse unter /media werden automatisch angelegt und dann wieder gelöscht. Es könnte natürlich sein dass ein Mountverzeichnis das man manuell anlegt irgendwie nicht gelöscht wird, das müsste ich probieren.
Oder meinst du woanders ein Mountverzeichnis erstellen und dann per Kommandozeile mounten? Dafür brauche ich wieder root-Rechte, das will ich vermeiden (weil es einfach nervig ist für solche Kleinigkeiten erst ein Passwort eintippen zu müssen).

[Versingled]

Wie meinst du das? Die Mountverzeichnisse unter /media werden automatisch angelegt und dann wieder gelöscht. Es könnte natürlich sein dass ein Mountverzeichnis das man manuell anlegt irgendwie nicht gelöscht wird, das müsste ich probieren.

Das meinte ich. Aber wie gesagt ... mit Wechselmedien habe ich eher wenig zu tun.

[The Poet]

Sagt mal ihr Nerds, kann man udisk2 oder wem-auch-immer beibringen bei extern angestöpselten Festplatten/USB-Sticks mit ext4 und Co den Besitzer vom Dateisystem zu ignorieren, so dass $mmA die Platte nicht nur per Klick in PCManfm mounten kann sondern auch tatsächlich darauf schreiben? Für "alte" Dateisysteme wie FAT funktioniert das weil die keinen Besitzer im Dateisystem speichern, aber bei ext4 ist das anders. Das Problem ist eigentlich der Besitzer vom mountpoint, aber der (Ordner unter /media/$mmA) wird erst beim Einstöpseln automatisch erzeugt und dann wieder gelöscht, also nix mit ein einziges Mal chown. Klar, könnte ich jedes Mal machen, aber dazu muss ich ja erst wieder root werden und genau das will ich vermeiden. Der Versuch udisks2 per config-Datei eine fixe UID mitzuteilen ist mit einem "error ... not allowed" gescheitert, das geht offensichtlich für ext4 nicht.

Im aktuellen Fall habe ich den USB-Stick einfach neu formatiert und mkfs.ext4 meine UID mitgegeben, aber das kann ja nicht die Lösung sein, vor allem wenn ich mal fremde Sticks/Platten mit ext4 habe.

Ich meine unter Deb10 hatte ich das Problem nicht oder waren da alle meine externen Datenträger noch als FAT formatiert?

???

Irgendwie widersprichst du dir da, oder?

"Das Problem ist eigentlich der Besitzer vom mountpoint, aber der (Ordner unter /media/$mmA) wird erst beim Einstöpseln automatisch erzeugt "

würde heißen, dass du nur im Mountpoint das Problem hast, aber nicht auf dem Rest der Platte, sprich du brauchst nur eine Lösung für das Top-Level-Directory.

"und Co den Besitzer vom Dateisystem zu ignorieren, so dass $mmA die Platte nicht nur per Klick in PCManfm mounten kann sondern auch tatsächlich darauf schreiben?"

hingegen insinuiert, dass du das Problem überall hast, ergo: Gerne auf alles im Tree unter "/media/$mmA/my_fancy_ext4_usb_dönerbratdevice/*" rekursiv Schreibzugriff hättest, wie bereits jetzt unter "Omega-3-FAT"-Devices wegen der speziellen FAT-Filesystem-Eigenschaften. (Oder vielmehr: Dem Fehlen ebenjener Eigenschaft.)


Which of both is it?



Allgemein, so 3 Ideen:

1. Das ist auch nur Rumgerate meinerseits, aber (wenn ich dich richtig verstanden habe) vielleicht irgendeine Magie mit bindfs hinterher draufwerfen, automatisch als Script, sofern möglich? Das Tool "inotifywait" kann glaub ich pfadbasiert-feingranular auf Filesystem-Events reagieren, das wär also evtl. eine Automatiklösung, wenn es on demand das als Befehl feuert, was in dem verlinkten Posting da steht. (Hint: Gemeint ist nicht der abgehakte Beitrag, sondern der darüber vom User "Catskul".)


2. Evtl. Default ACLs setzen für "/media/$mmA" - so dass alle neu erzeugten Ordner automatisch schreibbar sind durch dich?

Code: Alles auswählen

setfacl -x d:u:$mma:rwx /media/$mmA

(IIRC.)

Danach müsste jeder neu erzeugte Ordner der Form "/media/$mmA/my_fancy_ext4_usb_dönerbratdevice" von dir les-, schreib-, betret- und nach etwas Grillzeit auch essbar sein.

Caveats:

2.a Ich weiß aber nicht, ob nach dem Mounten die ACL noch "funktioniert", und nicht durch das Dateisystem, das reingemounted wird, temporär "überschrieben" (bzw. überdeckt) wird, insbesondere
2.a.i - wenn die reingemountete ext4-Partition nicht per tune2fs ACLs aktiviert hat, aber sogar wenn
2.a.ii - wenn die reingemountete ext4-Partition per tune2fs ACLs doch aktiviert hat.

Ich befürchte es fast irgendwie...

Außerdem interessant, im Fall 2.a.ii: Ob vom internen Filesystem irgendwas an ACL-Gedöns automatisch ans externe Filesystem des Dönerbratgeräts weitervererbt werden kann, oder ob dazwischen durch das Mounten quasi automatisch eine Sperre ist, die das Vererben unmöglich macht.


2.b Falls 2.a.ii zutrifft und die Vererbung über Laufwerks-/Partitionsgrenzen hinweg möglich ist, wird es wohl so sein, dass du damit "aus Versehen" neu angelegten Ordner auf my_fancy_ext4_usb_dönerbratdevice automatisch per ACL rights geben kannst und auch wirst (auch rekursiv, bei jeder künftigen Erzeugung eines Objekts .../$FU/$BAR in einem Ordner $FU, sofern Ordner $FU bereits die gesetzte ACL-Eigenschaft hat, weil "default"-Zeug sich [logischerweise] vererbt), die du ihnen eventuell gar nicht geben willst.
Das wäre dann ein Security-Problem, und außerdem "pollutest" du dir die externen Dönerbratgeräte mit ACLs voll, die du da evtl. nicht haben willst, weiß nicht, ob du damit leben kannst.


3. Bleiben wir bei "inotifywait" ... theoretisch müsste es ja den Job übernehmen könnten, neuen Ordnern (im konkreten Fall: im Directory "/media/$mmA/" natürlich) Rechte zu geben, sobald ebendort ein neuer Ordner erstellt wird.
Vielleicht kannst du dir damit irgendwas basteln, was der ACL-Lösung ähnelt, aber actually funzt? (Falls die ACL-Lösung nicht funzt.)



Aber ehrlich: Das klingt alles so dirty & hack-ish, was ich hier propose... ich hoffe, es kennt sich noch jemand tieferergehend mit Debian aus und es fällt ihm oder ihr noch eine bessere auf seinem oder ihrem Wissen beruhende Lösung ein .



PS, Edith sagt: Vielleicht hilft auch das hier irgendwie weiter?

https://unix.stackexchange.com/question ... ny-linux-m

[Mit müden Augen]

Irgendwie widersprichst du dir da, oder?

würde heißen, dass du nur im Mountpoint das Problem hast, aber nicht auf dem Rest der Platte, sprich du brauchst nur eine Lösung für das Top-Level-Directory.

Der Rest der Platte ist ja sozusagen im Mountpoint.

Oder auf deutsch:
-Ich stecke $Datenträger (ext4) ein.
-Irgendwas (udev, udisks2, uboot, u-bahn, ...) erzeugt einen Ordner /media/$mma/$lange_ID_vom_Datenträger. Dieser Ordner gehört (ls -l) dem Besitzer des Dateisystems, also standardmäßig root weil ich $Datenträger in einer root-shell formatiert habe (muss ich ja, mkfs.ext4 geht nur da (oder?)) und keinen anderen Besitzer angegeben hatte.
-$Irgendwas ruft (vermutlich) mount auf um die eigentliche "Einhängung" zu machen. /dev/sdX ist jetzt unter /media/$mma/$ID vorhanden.
-Ich versuche auf dem Datenträger (in dessen /, aber das dürfte egal sein) eine Datei anzulegen aber bekomme einen "permission denied".
-Ich zünde den PC an.

Zu deinen Vorschlägen:
1) bindfs+Skript hatte ich auch schon im Kopf, irgendwie wird das per udev-Regel oder so wohl gehen, aber das riecht nach viel Gemurkse bis es funktioniert. Die Wege des Pinguins - naja du weisst schon... Ich gucke mir das bei Gelegenheit mal genauer an.

2) ACL kenne ich nur vom Namen, aber das ist einen Versuch wert. Auch das werde ich ausprobieren, aber heute (Freitag) habe ich eher wenig Zeit und jetzt ist es schon spät... Ja, deine Bedenken kann ich nachvollziehen. Wie schon gesagt, ich werde es ausprobieren.

3) Auch eine gute Idee. Idem.

Aber ehrlich: Das klingt alles so dirty & hack-ish, was ich hier propose...

Ja, teilweise habe ich diese Sachen auch schon per Suchmaschine gefunden, aber ich dachte/denke mir da muss es doch einen eleganten Weg geben?? Irgendwie sind diese Rechtegeschichten unter PinguinOS regelmäßig eine Quelle von Problemen. Wahrscheinlich muss man noch viel nerdiger sein als ich es bin um damit nie Probleme zu haben...

Auf jeden Fall Danke für die Ideen und gute Nacht.

[The Poet]

-Ich zünde den PC an.

lol'ed just soooo...

-Ich versuche auf dem Datenträger (in dessen /, aber das dürfte egal sein) eine Datei anzulegen aber bekomme einen "permission denied".

Aber betreten ("x"-right) kannst du den Datenträger, oder?

Falls ja, entzündet sich genau hier mein PC*⁾ empfundener Widerspruch: Ist das nicht "wanted behaviour"? Ich weiß ja nicht, mit welchem intended Use Case die Platte vorher (btw: von dir?) erstellt/formatiert wurde, aber dass nicht jeder im Wurzelverzeichnis dieser Platte "alles" machen kann, kann ja durchaus erwünscht sein, oder?

[+] Ok,

für private Backup-Devices hingegen ist das doof, klar. Aber ...

- angenommen, mein vorhin beschriebener "Fall 2.a: Überdeckung findet statt" ist zutreffend -

... da sollte es doch irgendwie möglich sein, auch das "/"-directory der gemounteten Partition (sofern gerade gemounted in "/media/mma/$lange_ID_vom_Datenträger" also gerade genau dieser Pfad "/media/mma/$lange_ID_vom_Datenträger/") selbst per chmod ein Mal (Betonung liegt auf "ein") auf mma:mma zu setzen, und beim nächsten Remount und Reconnect von dieser USB-Platte wird sie wieder als genau dieser User eingehängt?
(Weil das ja - hoffentlich, oder ich bin gerade völlig bekloppt - im root-inode irgendwo hinterlegt sein wird, wem dieser root-inode bzw. das Verzeichnis, das er beschreibt (also das Wurzelverzeichnis), gehört (root / hauptmannkarotte / mma / knut / demkänguru / sonstwer), sprich auf der externen Platte selbst gespeichert ist).

Bzw. die korrekte Formulierung ist wahrscheinlich (um heute mal ganz-ganz-ganz präzise zu sein): Sie wird als gar kein User eingehängt, aber die effektive user:group-Eigentumsinfo von "/media/mma/$lange_ID_vom_Datenträger" ergibt sich daraus, dass die user:group-Info des root-inodes der externen Platte die "alte" user:group-Info des Verzeichnisses (wo die externe Platte gerade reingemounted wurde) überdeckt.


Oder geht das alles auch wieder nicht, weil du die Platte an verschiedene Systeme hängen willst, und auf System A hat der User mma die ID "1" und knut die ID "2", auf System B hingegen hat der User mma die ID "2" und knut die ID "1"? Sprich das Wurzelverzeichnis von der frisch gemounteten Platte gehört (nachdem du es darauf gesetzt hast) "dir", also mma, auf System A, und, wenn du sie hinterher auf System B einhängst, gehört es plötzlich knut? (Was doof ist, weil dir die Apfelschorle für ihn ausgegangen ist, und du ihn nur damit überredet bekommst, dir Zugriff auf seine Dateien zu geben? )

Sofern du den Ordner betreten kannst, kannst du dann ja in die Unterordner descenden (die hoffentlich dir gehören) und da dann machen was du willst.

Ja, teilweise habe ich diese Sachen auch schon per Suchmaschine gefunden, aber ich dachte/denke mir da muss es doch einen eleganten Weg geben?? Irgendwie sind diese Rechtegeschichten unter PinguinOS regelmäßig eine Quelle von Problemen.

Ja, da hab ich mir auch schon die Zähne dran ausgebissen, auf verschiedensten Game-Leveln**⁾ des Penguin-Outbreak-Spiels.

Good luck!

____
*⁾ (SCNR )
**⁾ Gibt es eigentlich auf youtube ein Linux-Speedrun-Video, ähnlich des SuperMario-NES-Speedruns?

[Mit müden Augen]

Pouet Pouet!

Danke für deine nächtlichen Überlegungen, ich versuche nachher (wenn ich denn Zeit habe) genauer darauf einzugehen (aber nicht daran einzugehen...).

Nur kurz: Ja, vermutlich ist das "wanted behaviour", aber ich finde es halt unpraktisch...

[halbkaputt]

Pouet Pouet!

Danke für deine nächtlichen Überlegungen, ich versuche nachher (wenn ich denn Zeit habe) genauer darauf einzugehen (aber nicht daran einzugehen...).

Nur kurz: Ja, vermutlich ist das "wanted behaviour", aber ich finde es halt unpraktisch...

ich hab hier (auf Ubuntu) mal ein wenig rumprobiert, da das immer alles getan hatte und ich nie manuell reingreifen musste.
das Verhalten ist folgendes:

-USB Stick wird angesteckt
-Popup in KDE
- ich öffne mit Dolphin
- device ist unter /media/username/Seriennummer mit fstype vfat gemountet und gehört meinem Unixuser(chown - damit volle Schreibberechtigung)

Zusatzinfo: der Unixuser ist Mitglied vom der plugdev Gruppe. siehe: https://wiki.ubuntuusers.de/Benutzer_un ... n/#Gruppen

würde mich wundern, wenn du eine einigermaßen aktuelle Distri hast und es diesen (oder einen ähnlichen) Mechanismus nicht gibt

[Prinzessinnenschreck]

- device ist unter /media/username/Seriennummer mit fstype vfat gemountet und gehört meinem Unixuser(chown - damit volle Schreibberechtigung)

Thema verfehlt!
Es geht hier nicht um das Dateisystem FAT.

Für "alte" Dateisysteme wie FAT funktioniert das weil die keinen Besitzer im Dateisystem speichern, aber bei ext4 ist das anders.

[Don Rosa]

Pouet Pouet!

Danke für deine nächtlichen Überlegungen, ich versuche nachher (wenn ich denn Zeit habe) genauer darauf einzugehen (aber nicht daran einzugehen...).

Nur kurz: Ja, vermutlich ist das "wanted behaviour", aber ich finde es halt unpraktisch...

Dann bleib halt bei MS-DOS, das Single Super User-OS. Es ist definitiv Absicht, der Pseudo-User bei FAT ist die Krücke.
Für die eigene Platte/Stick einfach einmal mit

Code: Alles auswählen

sudo chown -R mmA:mmAgrp /mountpoint

den Besitzer und die Gruppe setzen. Wenn du auf den benutzten Rechnern unterschiedliche numerische IDs hast, tja, hätte man vorher dran denken sollen. Aber auch das lässt sich mit root-Power auf ähnliche Weise lösen.

[Mit müden Augen]

Dann bleib halt bei MS-DOS, das Single Super User-OS.

Habe ich irgendeinen wunden Punkt bei dir getroffen?

Danke für die Hinweise. Neue Sticks werde ich mit meiner UID:GID formatieren (mkfs.ext4 -E root_owner $UID:$GID wenn mich mein Gedächnis nicht täuscht), vorhandene/fremde Sticks/Platten, naja, da muss ich halt manuel eingreifen oder mir ein Skript schreiben. Ich werde berichten (falls es jemanden interessiert ).

[Don Rosa]

Dann bleib halt bei MS-DOS, das Single Super User-OS.

Habe ich irgendeinen wunden Punkt bei dir getroffen?

Nö, aber alles ist "works as designed" und wer es anders benutzt als gedacht, sollte mit den möglichen Abstrichen leben. ext4 ist nicht dafür gedacht, auf einer Wanderplatte benutzt zu werden. Android betreibt viel Aufwand, um auf einem Dateisystem wie bei einer eingesteckten (ex)FAT-SDCard eine Separierung der "besitzerlosen" Dateien für die Apps zu machen. Aber (ex)FAT ist halt Standard für SDCards und so muss das System sich mit Krücken behelfen.
Also zum Datenaustausch per physischem Medium (ex)FAT benutzen. Stammt eben aus einer Umgebung von Einzelbenutzersystemen und so ein neumodischer Schnickschnack wie mehrere Benutzer und Rechteverwaltung war nicht vorgesehen.
Wenn du es nerdiger willst, dann formatiere deine Austauschplatten mit UDF 1.50.

Hmm, vielleicht könnte ein Overlay-Filesystem helfen, den gewünschten Owner zu setzen ohne die darunterliegende Austauschplatte zu verändern, wenn du eine fremde Platte benutzt.