Ich bin immer noch am Recherchieren, seit wann das so funktioniert ... denn es klappt tatsächlich auch für NFS-Freigaben - andere "Netzwerkfreigaben" habe ich noch nicht getestet.
Aber egal wo man auch nachliest - von der Man-Page für NFS über diverse Anleitungen im Internet (wobei die Primärquelle immer die Man-Page oder eine Dokumentation sein sollte und nicht ein "Erfahrungsbericht") bis zu unterschiedlichen CIFS-Quellen - es ist immer die Rede davon, daß da ein "share" (was üblicherweise als "Freigabe" ins Deutsche übertragen wurde) zu mounten wäre bzw. beim NFS dann ein "export", was sich mit den Angaben in der "/etc/exports" deckt. Selbst beim "Mount-Manager" vom "DietPi", dessen Bilder man oben sieht, steht (im fünften Screenshot) als Beispiel nur ein "mySharedFolder" und nichts von einem kompletten Pfad von der Freigabe bis zu einem Verzeichnis unterhalb einer solchen.
Da nicht alle "Dokumentierer" auf einmal geschlafen haben werden und es früher tatsächlich nicht funktionierte, muß es irgendeine Änderung gegeben haben, die an mir vorbeigegangen ist. Diese Änderung könnte jetzt rein zufällig diese Wirkung entfalten (was erklären würde, warum es nirgendwo (bei einer primären Quelle) dokumentiert ist) und gar nicht beabsichtigt sein. Oder sie wurde tatsächlich absichtlich so eingeführt, weil die Benutzer immer wieder bei der Frage, was sich letztlich mounten läßt (nämlich (lokale) Dateisysteme und (entfernte) Freigaben), durcheinander kamen - und da wollte man dann Abhilfe schaffen. Ich habe (zumindest bisher) noch keine Stellen dazu gefunden - erwartet hätte ich zumindest eine Diskussion auf der Kernel-Maillingliste o.ä., denn es erfordert ja zusätzlichen Aufwand (im Code), wenn man anstelle eines "filesystem objects" oder eines "remote shares" auch ein Verzeichnis auf einen "mount point" legen kann.
Denn spätestens in der Kommunikation mit dem Server muß der (lokale) Dateipfad ja dann wieder in seine richtigen Bestandteile zerlegt werden - dem Server muß ich schon mit dem richtigen "Aufsetzpunkt" beim Traversieren seiner Verzeichnisstrukturen kommen und da macht es dann schon einen Unterschied, ob eine "Ebene" in einem Dateinamen jetzt zum lokalen Pfad bis zum Mount-Point gehört oder schon zum entfernten Pfad zur Datei. Konkret sähe das z.B. so aus, wenn man mal eine Freigabe "share1" auf dem Server "server1" annimmt, die dann folgende Verzeichnisstruktur enthält:
Code:
dir1 (das "Wurzelverzeichnis" der Freigabe")
|
+---> dir1_1
| |
| +---> dir1_1_1
| | +---> file1
| |
| +---> dir1_1_2
| +---> file1
|
+---> dir1_2
Mountet man jetzt die Freigabe selbst (also
mount ... //server/dir1 /mnt/somewhere), braucht man nur den Pfad von der Datei
/mnt/somewhere/dir1_1/dir1_1_1/file1_1_1_1 rückwärts bis zum Mount-Point abzulaufen und man hat sofort den richtigen (relativen) Dateinamen (
dir1_1/dir1_1_1/file1) unterhalb der Freigabe, den man dann auch in der Kommunikation mit dem Server verwenden kann.
Mountet man jetzt aber so:
mount ... //server/dir1/dir1_1/dir1_1_1 /mnt/somewhereelse, gehört der Teil, den man in der Kommunikation mit dem Server ja trotzdem braucht (
dir1_1/dir1_1_1), jetzt zum Pfad bis zum lokalen Mount-Point und es braucht zusätzlichen Aufwand (im Code), diesen Pfad bis zum Mountpoint jetzt in die Freigabe und den relativen Pfad bis zum Verzeichnis, das beim Mounten verwendet wurde, zu zerlegen und diesen Pfad dann bei der Kommunikation mit dem Server noch dem Dateinamen hinzuzufügen - denn eine Datei
file1 gäbe es ja auch unterhalb von
dir1_1/dir1_1_2/file1 und das wäre eine andere.
Das hat dann auch Auswirkungen auf Kohärenz der Daten und anderes ... denn um unter Linux eine Datei eineindeutig intern anzusprechen, braucht es üblicherweise eine "device ID" und eine Inode-Nummer (
https://man7.org/linux/man-pages/man2/stat.2.html), die nur unterhalb der jeweiligen Device-ID eindeutig sein muß (sprich: zwei Dateisysteme können dieselbe Inode-Nummer für unterschiedliche Dateien verwenden, weil die nur innerhalb des Dateisystems gültig ist - wie eine Seitennummer in einem Buch). Das gilt zunächst zwar nur für lokale Dateien (wo es dann ein dediziertes "device" gäbe, z.B. eine HDD-Partition), aber es wird auch auf Netzwerk-Dateien übertragen. Dafür vergibt das System beim Mounten einer Freigabe eine Pseudo-ID für den Mount-Point - und das muß auch das lokale System machen, denn wenn ein Client mit zwei verschiedenen Servern arbeitet, könnte es wieder passieren (wenn der Server diese ID vorgäbe), daß beide dieselbe ID vergeben wollen. Üblicherweise basieren jetzt auch alle anderen Interna des Dateisystems (wie das Schützen vor parallelen Schreibzugriffen oder auch das Schützen vor dem Lesen sich gerade ändernder Daten durch einen anderen Prozess (Locking) und anderes) auf diesen "Beschreibungen" für eine Datei (Device-ID/Inode-Number).
Da sich offenbar NFS genauso verhält, was das Mounten von Verzeichnissen angeht, ist es einfacher, sich hier auf NFS zu konzentrieren bei der Suche - beim SMB/CIFS sind da noch zu viele zusätzliche Schichten dazwischen, angefangen beim Mapping von Benutzer-Accounts zwischen Server und Client, was eine Wissenschaft für sich ist, wie man der Samba-Dokumentation entnehmen kann. Das macht 1:1-Vergleiche dann schwerer und unübersichtlicher, weil jede dieser zusätzlichen Schichten irgendetwas anders machen könnte, als angenommen.
Denn es gibt bei Netzwerk-Mounts noch eine zweite Besonderheit - während es bei Dateisystem-Mounts nur möglich ist, einen einzigen Mount-Point als "beschreibbar" zu definieren (es kann aber noch andere Mounts geben, solange die "readonly" sind), klappt das bei Netzwerk-Mounts auch für mehrere, die sich auf dieselbe Freigabe (denselben Export) desselben Servers beziehen. Aber auch da müssen dann Zugriffe auf dieselbe Datei gegeneinander abgesichert werden - und das erfolgt üblicherweise wieder auf dem Server und zwar auch wieder anhand der Device-ID und einer Inode-Number. Deshalb bildet der Server dann wieder seinerseits eine "Filesystem-ID" für seine Exporte, die er selbst aus einer UUID oder einer Device-ID (wenn es etwas in der Richtung gibt, was nicht zwingend der Fall sein muß) ableitet und wenn der das nicht kann, muß ihn der Benutzer (oder der Admin) dabei mit dem "fsid"-Parameter bei einem NFS-Export unterstützen. Mit dieser FSID und der Inode-Number sollte dann der (NFS-)Server seinerseits das File-Locking für die Clients sicherstellen können ... aber dazu muß dann eben auch die FSID an der Freigabe "hängen", egal welche Pfadteile jetzt jeder Client "vor" dem Mount-Point noch eingeschlossen hat.
Und so gibt es noch einige andere Punkte, wo dieses "erweiterte Handling" auf Schwierigkeiten stoßen könnte/müßte ... man stelle sich nur mal eine Freigabe vor, für die der Benutzer A volle Zugriffsrechte hat, die aber ein Unterverzeichnis "subdir" enthält, für das er eben gerade keine Rechte hat - was passiert jetzt genau (bzw. was soll passieren, was ist beabsichtigt), wenn versucht wird, diese Freigabe unter Verwendung des Kontos von Benutzer A zu mounten und dabei aber gleich noch das "verbotene" Verzeichnis anzuhängen? Schlägt jetzt gleich das Mounten fehl oder weigert sich der Server erst dann, wenn auf diesen Mount-Point zugegriffen werden soll?
Ich wäre ja schon zufrieden, wenn ich irgendeine (Entwickler-)Diskussion über die Implikationen, die sich aus diesem (meiner Meinung nach eben erst später geänderten) Verhalten ableiten, finden könnte ... letztlich sind Bugs oder gar Sicherheitsprobleme, die sich in einer Software verstecken, häufig genug auch nur durch "Benutzung" aufgefallen, die nicht den Vorstellungen und Dokumentationen der Entwickler entsprach (außer diejenigen, die durch gezielte Analyse gefunden werden). Im Linux wurde im Laufe der Jahre praktisch alles auf die Benutzung einer allgemeinen Abstraktionsschicht mit dem Namen "Virtual File System" (VFS) umgestellt - seitdem gehen praktisch alle Dateizugriffe des Kernels über diese VFS-Schicht.
Ich tendiere im Moment zu der Vermutung, daß dabei irgendwann auch dieses Mounten von Verzeichnissen unterhalb einer Freigabe möglich wurde (was man auch nicht mit
mount -o bind ... verwechseln sollte, das fügt nur eine "indirection" hinzu für Dateien und Verzeichnisse und dabei kann man (zumindest glaube ich das zu wissen und vielleicht sollte ich das auch noch einmal prüfen) auch nicht einfach eine Datei über ein Verzeichnis mounten oder umgekehrt) und ich suche (immer noch) nach einer Diskussion, in der die Konsequenzen dieser Änderung mal Thema waren.
Was mich aber richtig irritiert, ist das Verhalten von Windows an dieser Stelle ... da ist zwar klar, daß UNC-Pfade auch ohne Mounten funktionieren (dank Redirector-Code bei der Namensauswertung - aber eben auch nicht in allen Windows-Programmen, wie man ab und an mal selbst bemerkt), aber daß man auch tieferliegende Verzeichnisse direkt mounten kann, war mir ebenso neu und wenn man sich mal die Syntax für das oben verlinkte "net use" ansieht, steht da mit dem
[\<volume>] hinter dem Share-Namen auch nur eine Angabe, die bei Netware-Emulation benutzt werden kann/soll und von einer "Alternative", wann da ansonsten noch weitere Pfade nach dem
\<ShareName> angegeben werden dürften, ist weit und breit nichts zu sehen. Nun ist die MS-Doku da zwar alt, aber sie sollte immer noch gelten und für Windows 10 habe ich keine neuere Dokumentation (bei MS) gefunden. Da ich nun vollkommen durcheinander war, habe ich aber einfach mal mit einem Windows 10 nachgesehen ... und da gibt es das "net"-Kommando immer noch und auch die Syntax für "net use" soll immer noch dieselbe sein, wo von "path_below_share" nichts zu sehen ist:
Code:
Microsoft Windows [Version 10.0.19042.746]
(c) 2020 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>net use /?
The syntax of this command is:
NET USE
[devicename | *] [\\computername\sharename[\volume] [password | *]]
[/USER:[domainname\]username]
[/USER:[dotted domain name\]username]
[/USER:[username@dotted domain name]
[/SMARTCARD]
[/SAVECRED]
[/REQUIREINTEGRITY]
[/REQUIREPRIVACY]
[/WRITETHROUGH]
[[/DELETE] | [/PERSISTENT:{YES | NO}]]
NET USE {devicename | *} [password | *] /HOME
NET USE [/PERSISTENT:{YES | NO}]
C:\WINDOWS\system32>
Auch die Idee, daß dann eben die Pfadangabe einfach zum "sharename" dazugeschlagen würde in der Beschreibung, leuchtet mir nicht so richtig ein ... denn auch bei anderen Sub-Kommandos ist es ziemlich eindeutig, was ansonsten unter einem "Share name" verstanden wird:
Code:
C:\WINDOWS\system32>net share
Share name Resource Remark
-------------------------------------------------------------------------------
C$ C:\ Default share
T$ T:\ Default share
D$ D:\ Default share
IPC$ Remote IPC
print$ C:\WINDOWS\system32\spool\drivers
Printer Drivers
ADMIN$ C:\WINDOWS Remote Admin
D D:\
Users C:\Users
The command completed successfully.
C:\WINDOWS\system32>
und denselben Begriff für unterschiedliche Inhalte zu verwenden, verbietet sich eigentlich von selbst.
Ich bin also einigermaßen ratlos - aber immerhin habe ich (der ich mich ansonsten an die jeweiligen Dokumentationen und frühere Erfahrungen halte) damit etwas dazugelernt (und so etwas kann ich auch problemlos zugeben) und nun wüßte ich halt auch noch gerne, ob diese Möglichkeiten (im Linux!) absichtlich eingebaut wurden oder doch nur ein Unfall sind, der dann Benutzern, die sich ansonsten nicht mit Dokumentationen befassen, aufgefallen ist, als sie eine eigentlich falsche Syntax verwendeten und den sie jetzt benutzen können.
Bei letzterem müßte/sollte man dann vielleicht tatsächlich noch einmal alle Konsequenzen überlegen und auch testen ... nur braucht das einen Plan (weil vieles auch eine spezielle Konfiguration braucht und da ist es dann blöd, wenn man für den dritten Test dieselbe Konfiguration bräuchte, wie für den ersten, die man dann aber für den zweiten Test schon wieder "vernichtet" (bzw. umgebaut) hat) und wohl auch entsprechenden "Antrieb" (inkl. Zeit dafür), was mir im Moment eigentlich beides fehlt. Trotzdem treibt mich das Thema so stark um, daß ich (obwohl ich eigentlich anderes machen wollte) schon einige Versuche der Recherche gestartet habe, die aber bisher noch nicht zu Ergebnissen geführt haben.
