OMV SMB/CIFS Share funktioniert nur mit einem User

[jokakilla]

Moin zusammen,
ich verzweifel gerade an der Einrichtung eines SMB Share in OpenMediaVault.
Das System ist ein OMV 6.8.0-1 auf Debian 11.7 auf einem NuC-artigen System. Also nicht so schwach auf der Brust.
Ich wollte nun einen Share einrichten. Der ist aber nur für einen Benutzer zugreifbar. Für alle anderen und neu angelegte funktioniert der Zugriff nicht.

Unter Storage, File Systems gibt es eine NVMe SSD als EXT4 formatiert, gemountet mit ausreichend Speicher.

Darauf gibt es ein Shared Folder:

Der SMB Service läuft:

Es gibt einen SMB Share für das Shared Folder:

Ein User ist angelegt:

Im Shared Folder bei den Permissions ist die Permission auf Read/Write gesetzt:

Ebenso taucht beim User unter den Permissions der test share mit Read/Write auf:

Ergänzung (12. September 2023)

Per SSH das test Verzeichnis geprüft:

drwxrwsr-x+ 2 root users 4.0K Sep 12 21:56 test

Ergänzung (12. September 2023)

Bei den Shares bei denen ich keinen Zugriff gegeben habe kommt beim Versuch darauf zuzugreifen erneut der Dialog zur Eingabe von Benutzer und Passwort.

Beim Test Share kommt sinngemäß eine Meldung wie "Zugriff verweigert. Bitte an den Admin wenden".

Ergänzung (12. September 2023)

Der Zugriff funktioniert von Windows 10 und auch Linux Mint nicht. Bei Mint kommt immer wieder der Dialog zur User/Passwort Eingabe.

Ergänzung (13. September 2023)

Ich habe temporär versucht AppAmor und UFW auf dem Server zu deaktivieren um Firewall und Security Probleme auszuschließen. Hat aber auch nix gebracht.

 

[Brudertuck]

hm... deine settings für den SMB share sind auf jeden Fall nicht Standard. Normalerweise ist da weder Inherit Permissions noch Inherit ACLs gesetzt. Evtl. hat es ja damit was zu tun...

 

[snaxilian]

Hat aber auch nix gebracht

Korrekt, solche try'n'error Sachen sind halt Verzweifelungstaten.

Steht etwas dazu im Log des smbd? Falls nein: Loglevel hochdrehen und erneut versuchen.

Klappt der Zugriff des funktionierenden Users von allen getesteten Endgeräten oder nur von einem?
Klappt der Zugriff wenn du bei Benutzername nicht nur den Namen angibst sondern auch den Servernamen? Also hostname-des-servers/test und nicht nur test.

SMB Zugriffe per IP-Adresse ändern afaik die Art und Weise der Authentifizierung (lanman, ntlmv1, ntlmv2). Ich musste mal vor Jahren in dieses Rabbithole kriechen für nen troubleshooting aber habe danach Details verdrängt. Hängen geblieben ist nur, dass es einen Unterschied macht und man Zugriff per IP vermeiden sollte. Nutze den Hostname, gibt keinen hier ersichtlichen Grund es nicht zu tun.
Dein Fehlerbild sieht hier nach einem solchen auth mismatch aus.

 

[jokakilla]

Inherit ACLs und Inherit Permissions habe ich entfernt.
Außerdem den Zugriff über smb://<hostname>/test von linux bzw. \\<hostname>\test von Windows probiert. Kein Unterschied zu sehen.

Nach dem Aktivieren des Loggings beim SMBD sieht man in der Log Datei sowas:

chdir_current_service: vfs_ChDir(/srv/dev-disk-by-uuid-bc703c85-a804-4329-ae12-bb9c765bdebf/test) failed: Permission denied. Current token: uid=1005, gid=100, 1 groups: 100

uid=1005 ist mein Testuser "blub" der eigentlich auf die test Freigabe drauf kommen sollte. Scheinbar scheitert es nicht an den SMB Berechtigungen sondern an den Filesystem Berechtigungen?

root@server:/var/log/samba# ls -lah /srv/dev-disk-by-uuid-bc703c85-a804-4329-ae12-bb9c765bdebf/test
total 16K
drwxrwsr-x+ 2 root users 4.0K Sep 12 21:56 .
drwxrwsr-x+ 13 root users 4.0K Sep 12 21:56 ..

Also user root darf alles. group users darf lesen und schreiben und set-uid?

root@server:/var/log/samba# groups blub
blub : users

blub ist also in der Gruppe users und hat damit rws permission. Fehlt da nicht das Execute damit er in das Verzeichnis wechseln darf?

Wobei die Samba Prozesse irgendwie eh unter root laufen und damit doch Zugriff haben müssten?

root@server:/tmp# ps aux | grep smb
root 285323 0.0 0.1 84540 24868 ? Ss 21:24 0:00 /usr/sbin/smbd --foreground --no-process-group
root 285325 0.0 0.0 82388 10268 ? S 21:24 0:00 /usr/sbin/smbd --foreground --no-process-group
root 285326 0.0 0.0 82396 8164 ? S 21:24 0:00 /usr/sbin/smbd --foreground --no-process-group
root 289387 0.0 0.0 8236 636 pts/0 S+ 21:42 0:00 grep smb

Ergänzung (13. September 2023)

Oder führt der smb Prozess die Dateisystemzugriffe dann unter dem User aus der sich authentifiziert hat? Wäre ja auch sinnvoll.

Btw: Das Execute Bit lässt sich für das Verzeichnis für die Gruppe nicht setzen :/

chmod g+x /srv/dev-disk-by-uuid-bc703c85-a804-4329-ae12-bb9c765bdebf/test

drwxrwsr-x+ 2 root users 4.0K Sep 12 21:56 test

Ergänzung (13. September 2023)

root@labskaus:/srv/dev-disk-by-uuid-bc703c85-a804-4329-ae12-bb9c765bdebf# getfacl test
# file: test
# owner: root
# group: users
# flags: -s-
user::rwx
user:jokakilla:rwx
user:blub:rwx
group::rw-
group:joka:rwx
mask::rwx
other::r-x
default:user::rwx
default:user:jokakilla:rwx
default:user:blub:rwx
default:group::rw-
default:group:joka:rwx
default:mask::rwx
defaultther::r-x

 

[jokakilla]

Ok fu**. Funktioniert jetzt. Es gab mehrere Probleme. @snaxilian hat recht und es geht von Windows aus nur über den Hostname weil wohl ein anderes Authentifizierungsverfahren benutzt wird als wenn man über IP geht. Windows

Dazu kamen die ACLs. Siehe oben: group::rw-
Damit ins Verzeichnis gewechselt werden kann muss die ACL Permission rwx sein.

Bei meinem User geht es weil der in der Gruppe jokakilla ist bei dem schon über "user:jokakilla:rwx" execute erlaubt war. Entweder hab ich da mal über die GUI vom OMV was falsch gemacht oder das ist OMV magic.

 

[snaxilian]

Windows

Hach immer wieder schön zu sehen wie unvollständige oder fehlerhafte Config und Verständnisprobleme des Admins versucht werden wegzulächeln und auf das Produkt zu schieben.
Ja, SMB ist ein Minenfeld mit vielen Stolperfallen heutzutage weil sich kaum jemand in der oft nötigen Tiefe damit beschäftigt. Oft auch nicht nötig wenn man sich an Vereinfachungen und Standards hält und dazu gehört auch der benutzerfreundliche Zugriff über menschenlesbare/verständliche Namen anstatt sich umständlich irgendwelche IPs merken zu müssen.
Das mag ggf. im privaten Umfeld noch funktionieren aber nicht in größeren Umgebungen und auch im privaten Umfeld wird es schwieriger mit IPv6 und wenn man dann noch verstanden hat, dass moderne Auth Methoden auch auf DNS setzen und kein IP-only unterstützen, dann erkennt man auch, dass sich Windows in diesem Fall ziemlich richtig verhalten hat.
Ja, Windows hat an vielen Stellen ein vergleichsweise komisches Verhalten, v.a. wenn es um Interaktion mit nicht-Windows-Systemen geht, aber wenn man sich mal die Technik dahinter und darunter anguckt dann ist es wieder logisch
Bonuspunkte für die Verdopplung der Fehlerquellen wenn man IPv4 und IPv6 parallel nutzt wobei die meisten Probleme auftauchen wenn Freizeitadmins glauben, sie wüssten es besser und nein ich bin da nicht überheblich, mir passieren da auch Fehler am laufenden Band in Themengebieten wo ich nicht sattelfest bin aber trotzdem (privat) drin herumpfuschen möchte^^

Scheinbar scheitert es nicht an den SMB Berechtigungen sondern an den Filesystem Berechtigungen?

Die Probleme hab ich auch in vielen anderen Umgebungen gesehen. Best Practice ist daher stets: Berechtigungen nur auf Filesystemebene vergeben (da granularer möglich) und beim SMB Server lediglich ggf. pro Share zu steuern welche Gruppe von Usern überhaupt darauf Zugriff haben sollte oder nicht.
Alternativ in der smb.conf mit der Option "force user" etc. arbeiten. Dann werden alle Operationen an Dateien und Ordnern von diesem einen User erledigt und lesen/schreiben Berechtigungen können in der smb.conf pro Share auf User- oder Gruppenbasis erfolgen.
Da ist dann halt nur simple Unterscheidung lesen ja/nein und schreiben ja/nein möglich und die Nachvollziehbarkeit geht etwas verloren da auf dem Server/NAS selbst alle Dateien und damit auch Änderungen, Löschungen etc. von dem force user erfolgen.

Appliances wie OMV oder auch fertige Lösungen wie QNAP oder Synology verstecken diese Unterscheidungen vor dem User und kümmern sich im Hintergrund darum oder führen per Assistenz/Wizard durch die Berechtigungen. Möchte man alles selbst/manuell erledigen, muss man auch an alles selbst denken.

Wobei die Samba Prozesse irgendwie eh unter root laufen und damit doch Zugriff haben müssten?

Nein aber du hast die Lösung ja selbst gefunden:

Oder führt der smb Prozess die Dateisystemzugriffe dann unter dem User aus der sich authentifiziert hat? Wäre ja auch sinnvoll.

Eben dies, auch ist ein privilegierter Start nötig um die privilegierten Ports (<=1024) verwenden zu können. Bei anderen Anwendungen läuft das ähnlich ab. Ein Apache Webserver startet auch oft als root um :80 und :443 nutzen zu können, die einzelnen Subprozesse, die dann die Webseiten etc. ausliefern sind dann aber andere Nutzer, z.B. www-data.

Dazu kamen die ACLs

Die Frage ist: Brauchst du wirklich ALCs oder reichen dir die normalen POSIX Berechtigungen?
Wenn du Appliances wie OMV nutzt dann solltest du auch jegliche Änderungen nur per OMV umsetzen und nicht daran vorbei per SSH. Sowas kann dann nämlich zu Inkonsistenzen und Problemen führen. Solche Appliances sind halt Segen und Fluch zugleich. Vieles wird vereinfacht aber wenn man aus den vorgegebenen Leitplanken ausbricht, passieren Unfälle.

 

[jokakilla]

Wie Du schreibst. SMB ist ein Minenfeld. Man muss halt die Hacks and Quirks kennen und ich finde man merkt das es ein altes gewachsenes Protokoll ist. Einen Webserver einrichten ist dagegen ein Witz. In diesem Fall kann man aber durchaus sagen dass das Verhalten eine Windows Eigenheit ist. Linux ist es ziemlich egal ob man eine IP oder einen Hostname nutzt.

Bin kein Berufsadmin aber ein bisschen Erfahrung hab ich wohl

Eine lokale Domain hab ich nicht weil der Mikrotik von Haus nicht so komfortabel eine Namensauflösung für eine lokale Domain bietet wie eine Fritz und co.
Abgesehen vom NAS läuft der Zugriff auf so gut wie alle im internen Netz laufenden Dienste über eine DE Domain die von außen über einen VPS auf dem Heimserver getunnelt werden. Intern löst PiHole die Domain natürlich auf die IP im lokalen Netz auf.

IPv6 hör mir auf ja ich habe mich rudimentär damit befasst. Aber mir fehlt die Muße mein internes Netz mit 6 VLANs und dem Routing auf IPv6 umzustellen.
Von außen geht es per IPv4 oder IPv6 per Wireguard ins Haus aber intern wird nur IPv4 gesprochen.

 

[jokakilla]

Aber vllt nochmal eine ernste Frage: Über IP scheint Windows das weniger sichere NTLMv2 zu nutzen. Mit Domain Kerberos. Die NTLMv2 Authentifizierung bei IP Verbindung von Windows lehnt Der Samba Server ja ab.

Unter Linux Mint mit Nemo über smb://<IP>/<share> funktioniert eine Verbindung. Sieht man irgendwo welches Authentifizierungsverfahren genutzt wird? Müsste ja Kerberos sein da NTLM ja nicht erlaubt ist. Hab mal Wireshark angeworfen. Oberflächlich sieht es erstmal so aus als würde Nemo es auch über NTLM versuchen.

Vllt ist der interessante teil aber auch nicht im Klartext sichtbar. Kerberos soll ja Token basiert laufen. Vielleicht hab ich den Abruf eines Access Token nur verpasst?