Kürzlich habe ich meinen betagten DSL-Router des Internetanbieters durch einen neuen Asus N17U ersetzt. Unter anderem verfügt dieser auch über 2 USB Anschlüsse, mittels derer sich USB-Massenspeicher oder Drucker im Netzwerk freigeben lassen. Am vergangenen Wochenende hatte ich ein wenig Zeit, mich damit auseinander zu setzen. Dabei stolperte ich über ein paar Sachverhalte die mich unvorbereitet trafen – und über die ich hier berichten möchte.

Ich hatte noch eine 2,5-Zoll USB-Festplatte mit ca. 200 GB Kapazität übrig. Der Plan war, darauf 3 Partitionen anzulegen und damit die Funktionalität des Routers zu testen. Aus früheren Experimenten wusste ich, dass die Fähigkeiten solcher Router sicht meistens auf MBR Partitionierung und FAT32/NTFS beschränken. Wie sich herausstellte, war das auch beim Asus der Fall. Kein GPT, kein ext4 oder sonstiges. Bei 2 TB ist also Schicht. Nun ja, war erst mal egal.

Nach MBR-Partitionierung und Formatierung mit NTFS schloss ich die Platte am Router an. Erfreulichgerweise blieben mir weitere Überraschungen erspart. Der Router lieferte genügend Milliampere um die Platte ohne Y-Kabel bzw. separates Netzteil zu betreiben und erkannte direkt die 3 Partitionen, die mir als Ordner im Konfigurationsmenü präsentiert wurden:

Router shows 3 partitions as sibling folders under root
Abb.1 – So sieht die Platte mit den Partitionen im Asus Webinterface aus

Im nächsten Schritt musste ich dann erkennen, dass ich in diesen „Ordnern“ zunächst, ähm, Ordner anlegen musste. Erst diese lassen sich mit Benutzern und Zugriffsrechten zu entsprechenden Freigaben kombinieren. Gesagt, getan. Etwas später sah es dann so aus:

Shareable folder needs to be cerated as child of a folder that represents a partition
Abb.2 – Ein freigegebener Ordner auf Partition 2

Zufrieden, dass dieser Teil relativ problemlos erledigt war, machte ich mich einigermaßen euphorisch daran, die neuen Freigaben zu benutzen.

Auf Linux

Zurück vor meinem Ubuntu 16.04 Rechner startete ich den standardmäßig installierten grafischen Dateimanager (in meinem Fall caja) um zu sehen ob die Freigaben denn auftauchten. Also Eingabe der IP-Adresse des Routers unter Verwendung des Prefix smb:

smb://192.168.1.3

Seltsamerweise zeigte mir caja die freigegebenen Ordner zwar an …

In the GUI file manager, shares are shown correct
Abb.3 – Freigaben im Dateimanager

…ließ mich aber irgendwie nicht hinein:
Der Dialog zur Eingabe von Benutzername und Passwort erschien einfach immer wieder erneut, so als ob ich nichts eingegeben hätte. Keine Fehlermeldung, nichts.

Ich ließ mich im Stuhl zurücksinken und grübelte woran es liegen könnte. Irgendwann blieb mein Blick auf den Namen der freigegebenen Ordnern hängen und plötzlich war mir klar was hier los war: Die Asus Leute waren scheinbar der Meinung, den Namen des Elternordners meiner Freigabe an deren Namen anzuhängen. Wenn ich also beispielweise einen Ordner namens „pics“ auf der zweiten Partition angelegt hatte (die als „sda2“ erkannt wurde), machte der Router daraus eine Freigabe namens:

pics (at sda2)

Ich könnte jetzt aus tiefstem Herzen über das Wieso, Weshalb und Warum-zum-Teufel dieses Umstandes lamentieren. Aber letzendlich war das Problem nicht irgendwer bei Asus sondern einfach der Umstand, dass mir nicht aufgefallen war was das Ganze bedeutete:

Leerstellen im Freigabenamen

Um zu sehen ob meine Vermutung richtig war machte ich eine kurze Gegenprobe: Anlegen eines Verzeichnisses namens /mnt/foosrv und Verwendung desselben als Einhängepunkt mittels sudo mount im Terminalfenster, wobei der komplette UNC der Freigabe in Anführungszeichen eingeschlossen wurde:

sudo mount -t cifs "//192.168.1.3/pics (at sda2)" /mnt/foosrv -o username=myusername,password=mypassword,rw

Und das funktionierte völlig problemlos. Die Ursache musste also irgendwo beim Dateimanager liegen. Aber egal. Auf diese beiden Arten wollte ich die Freigaben ohnehin nicht nutzen, sondern vielmehr über einen permanenten Einhängepunkt. Also ab zur /etc/fstab und flugs eine Zeile angefügt mit dem Freigabenamen in Anführungszeichen. Und wer hätte es gedacht: Geht nicht.

An dieser Stelle muss ich zugeben, dass ich, obwohl ich mich seit mehr als zwei Jahrzehnten beruflich in der IT herumtreibe, immer noch ein relativer Anfänger bin wenn es um Linux geht. Die Notwendigkeit einer Problemlösungen führt daher bei mir gewöhnlich dazu, dass ich bei Google lande. So auch in diesem Fall, aus dem ich nicht nur lernte dass die meisten (grafischen) Dateimanager Probleme mit Leerstellen in Freigabenamen haben, sondern auch, dass beim Einhängen via fstab, entsprechende Leerstellen ausgesteuert werden müssen

Unter Verwendung des aussteuerns (des sogenannten „escapens“) wird anstelle des Leerzeichens dessen ausgeschriebene hex-Notation (040) verwendet. Damit sieht der Name dann so aus:

pics\040(at\040sda2)

In meinem Fall musste die komplette Zeile der /etc/fstab also wie folgt lauten:

//192.168.1.3/pics\040(at\040sda2)   /mnt/foosrv    cifs    username=myusername,password=mypassword    0    0

Und das funktionierte dann auch wie erwartet. So weit so gut.

Auf Windows

Aus reiner Neugier wollte ich dann schauen, wie sich denn eigentlich Windows bei solchen Freigaben schlagen würde. Das einzige Windows, dass ich Zuhause noch einsetze ist eine 7er Home-Version in VirtualBox. Und diese verhielt sich im Prinzip identisch zu Linux: Der Explorer fand zwar problemlos die Freigaben, konnte aber nach Doppelklick darauf und Eingabe der Zugangsdaten nichts damit anfangen. Angeblich existierte die Freigabe gar nicht.

Auf der Befehlszeile (also im „DOS-Fenster“) funktionierte der Trick mit den Anführungszeichen genau wie in Linux. Der "net"-Befehl verstand sofort, was von ihm verlangt wurde und funktionierte klaglos:

net use z: "\\192.168.1.3\pics (at sda2)"

Über den Explorer aber eine „feste“ Verbindung der Freigabe zu einem Laufwerksbuchstaben herzustellen war schon etwas komplizierter:
Den ganzen UNC-Pfad in Anführungszeichen zu stellen führte nicht zum Erfolg. Scheinbar fand irgendeine Verarbeitung der Eingabe statt die meinen Trick wieder aufhob. Mit ein wenig Herumprobieren fand sich aber schnell eine Lösung:

\\192.168.1.3\"pics (at sda2)"

Hier musste also lediglich der letzte Teil, der Ordnername selbst, in Anführungszeichen gestellt werden. Nett. Jetzt erklären Sie das mal jemandem, der relativ unbedarft in der PC-Nutzung ist…

Soviel zur Samba Interpretation in Redmond.

Auf LibreELEC (und ggf. auch OpenELEC)

Eine besonderes Schmankerl entdeckte ich dann noch bei LibreELEC auf meinem  Raspberry Pi. Ich vermute, dass dasselbe auch histroisch bedingt für OpenELEC zutrifft (aber das konnte ich icht überprüfen, daher nur als Hinweis).

Während das Einhängen der Freigabe über die Befehlzeile genau so mit den Anführungszeichen um den ganzen UNC-Pfad funktionierte wie in Linux oder Windows (bzw. DOS), gab es beim permanenten Einhängen einen entscheidenden Unterschied: Bei LibreELEC auf dem Pi gibt es keine /etc/fstab.

Nun ja, okay, natürlich gibt es eine datei namens „fstab“ im Verzeichnis /etc.
Aber diese ist standardmäßig leer und wird nicht verwendet. Bei LibreELEC auf dem Pi wird ein anderes Verfahren eingesetzt, nämlich mittels „systemd“. Zu meiner Überraschung brauchte es da aber keinerlei Tricks was den ansonsten eher problematischen Freigabenamen angeht:

...
[Mount]
What=//192.168.1.3/pics (at sda2)
...

So einfach kann es sein. Mehr Informationen zum Einhängen von Samba-Freigaben unter LibreELEC finden sich auf der entsprechenden OpenELEC wiki Seite.

Zusammenfassung

Quasi als kleiner „Rosettastein“ hier eine Übersicht der benötigen Notationen beim Umgang mit Leerstellen in Freigabenamen:

Plattform Befehlszeile permanent
Linux Anführungszeichen für ganzen UNC-Pfad

Aussteuerung innerhalb UNC

Windows Anführungszeichen für ganzen UNC-Pfad Anführungszeichen nur um den Freigabenamen
libreelec on Raspberry Pi Anführungszeichen für ganzen UNC-Pfad keine Tricks benötigt

Falls Sie über weitere Sonderfälle stoßen, lassen Sie es mich wissen. Besonders würde mich interessieren, wie es bei aktuellen Mac-OS(X) Versionen aussieht: Identisch zu Linux?


Diesen Artikel teilen:
Facebooktwitterlinkedinmail

Bild- und Urheberrechtsnachweise (siehe auch hier):