smbfs mount nur root-lesbar

h^2

hat ne Keule +1
Die gute Nachricht: ich kann bei der Arbeit FreeBSD verwenden, die schlechte Nachricht: ich kriege das Netzlaufwerk per SMB.

Das mounten klappt relativ normal mit mount_smbfs, der einzige zusätzlich benötigte Parameter is -W DOMAINNAME (keine config).
Leider klappt das mounten aber nur als root, ansonsten bekomme ich:
Code:
mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): syserr = Operation not permitted
Längeres Suchen brachte keine Lösung dieses Problems zu Tage... An fehlenden Modulen liegt es nicht, denn die selbe Nachricht kommt, wenn vorher (erfolgfreich) dieselbe Share von root gemountet wurde. Dies wäre schön gelöst zu kriegen, wäre aber nicht unbedingt notwendig, da ich root auf dem Rechner habe.

Das Hauptproblem ist, dass wenn ich es als root mounte, ich auch nur als root darauf zugreifen kann. Das ist sehr merkwürdig, da die Benutzerrechte eigentlich richtig übertragen werden. Das Ziel-directory gehört dem user und ein ls -ahl als root in dem gemounteten Dir zeigt auch an, dass alles dem user gehört und lesbar ist. Der user selbst kann aber nicht darauf zugreifen. Ich habe auch schon beim mounten -M USERNAME -O USERNAME -u USERNAME gesetzt, hat aber alles nichts geholfen.

Irgendwelche Ideen?
 
Hast du mal versucht die Rechte über den Mountpunkt zu machen? Das funktioniert bei mir.
 
Der Aufruf verändert doch nur die Group-Ownership, oder nicht?

Falls das vorher nicht klar war, der Mountpunkt gehört dem Target-user und liegt sogar in dessen Home...

edit: das Ausführen der Rechte-Änderung und erneutes Mounten ändert aber auch nichts...
 
Hmm, bei funktioniert das. Mounten als root und die gemounteten Daten gehören dem Eigentümer des Mountpoints.

Ich sehe gerade Du hast einen Bindestrich in Deinen Charset-Einstellungen. Bei mir funktioniert -Eutf8:cp1252 aber -Eutf-8:cp1252 geht nicht.
 
Hm, charset-Konversion mache ich garicht explizit...

Ich bin da insgesamt auch ziemlich ratlos:
Code:
h4nn3s@celegans ~ % mount | grep mihome
//H4NN3S@MI-HOME/H4NN3S on /usr/home/mi/h4nn3s/mihome (smbfs)
h4nn3s@celegans ~ % lh | grep mihome
drwx------  1 h4nn3s  operator  16K  1 Jan  1970 mihome/
h4nn3s@celegans ~ % lh mihome
total 0
ls: mihome: Permission denied
 
Wenn man die modes explizit mit -f und -d angibt, dann geht es. Sehr merkwürdig, denn auch wenn man das nicht tut werden die modes als korrekt angezeigt. Riecht mir nach einem Bug.
 
Ok, es wird noch bizarrer. Es hängt von den Group-Rechten ab. Das Verzeichnis ist eigentlich so eingerichtet, dass es nur vom owner anzeigbar ist. Der wird anscheinend in keinem Fall richtig gesetzt. Wenn ich -d 774 übertrage, dann kann ich zugreifen, weil anscheinend die Gruppe richtig zugeordnet wird, bei den Zugriffsrechten. -d 700 oder auch 740 sorgt dafür, dass das Verzeichnis nicht gelistet werden kann.
Noch paradoxer wird es wenn ich dann in dem Verzeichnis eine Datei erstelle. Diese wird auf meinem Client mit richtigen cridentials angezeigt (user und gruppe stimmen, Rechte sind so wie die anderen Dateien). Schau ich mir das Verzeichnis dann auf dem Server an, dann hat die Datei erstmal komplett andere owner, sieht ungefähr so aus:
-rwx------ 1 4294967294 4294967294 0 Aug 20 14:25 foo2*

Nach einer undefinierten Zeit nach dem unmount werden dann auf einmal die Ownerships auf der Datei auch server-seitig korrigiert, jedoch user und group auch nicht gleichzeitig. Das könnten allerdings auch Scripte auf dem Server sein, die Home-Verzeichnisse überwachen, das weiß ich nicht.

Insgesamt ein großes WTF.

Gibt es hier noch Dinge, die ich debuggen sollte oder wo ich vielleicht weiter kommen kann? Nachdem es schon ein Politikum war FreeBSD benutzen zu können und man mir sagte, dass man froh sei vor Jahren alle Solaris und FreeBSD-Maschinen los zu sein, will ich mich hier ungern an die Admins wenden, da das wahrscheinlichste Szenario ist gesagt zu bekommen, dass der FreeBSD-Client broken ist und ich Linux benutzen soll.
 
Ich bin ja sehr zufrieden mit: http://www.freshports.org/sysutils/fusefs-smbnetfs/ Ist wie jede FUSE-Anwendung nicht unbedingt eine Performance-Bombe, aber für den täglichen Einsatz völlig ausreichend.

So etwas naheliegendes wie eine andere Samba-Implementierung auszuprobieren kam mir natürlich nicht in den Sinn. Werde ich gleich morgen ausprobieren! Korrekte Arbeitsweise ist mir in jedem Fall wichtiger als Performance.
 
Das funktioniert in der Tat ganz gut, mounten als user klappt auch. Ein großes Haken hat es aber: das Passwort muss Plaintext in eine Datei, das gefällt mir noch nicht...
Und der Performance-Unterschied ist auch sehr merkbar (50MB/s write performance in-kernel-smb VS 10MB/s in userspace), aber das hatte ich schon befürchtet.

Naja, mal schauen wie die Implementierungen sich sonst schlagen.
 
Mache alle Timeouts schön kurz, denn wenn mal die Verbindung weg ist hängen sonst tmux für 'ne halbe Stunde bevor du das Panel schließen kannst in dem auf ein Share zugegriffen wird.

Code:
listen_timeout 30
max_retry_count 1
reply_timeout 10

Die Sache mit den Passwörtern geht theoretisch auch über gnome-keyring. Das habe ich aber noch nie ausprobiert.
 
Back
Top