Netzwerkfreigabe mit Samba funktioniert nicht

[HPC]

Hallo zusammen,

ich bin kürzlich von Windows auf Debian 13 umgestiegen. Ich habe es auch schon hinbekommen mit Samba Ordner im Netzwerk freizugeben, scheitere jetzt aber daran, dass z.B. der Ordner "Fotos" durch bestimmte Benutzer, die einer Gruppe zugeordnet sind gelesen, geschrieben und ausgeführt werden dürfen (das klappt), anderere Benutzer, die ebenfalls einer Gruppe zugeordet sind, diese nur lesen und ausführen dürfen (klappt nicht).

Wenn ich mich mit der zweiten Gruppe anmelde, bekomme ich bei der lokalen Prüfung per smbclient immer den Fehler "tree connect failed: NT_STATUS_ACCESS_DENIED". Ich habe die KI jetzt schon eine Stunde bemüht, aber alle Versuche schlagen fehl …
Hier mal ein Ausschnitt aus meiner smb.conf. Kann es ggf. sein, dass sich die beiden Abschnitte beißen?

[Fotos]
path = /home/hpc/Fotos
browseable = yes
read only = no
writable = yes
guest ok = no
create mask = 0775
directory mask = 0775
valid users = @HPC
force group = hpc
force user = root

[Fotos_Proxmox]
path = /home/hpc/Fotos
valid users = jellyfin @proxmox
read only = yes
browsable = yes
guest ok = no
writable = no
force group = proxmox
create mask = 0770
directory mask = 2770
force create mode = 0660
force directory mode = 2770

Hier noch die Berechtigungen vom Ordner mittels ls -ld /home/hpc/Fotos
drwxr-x--- 5 hpc proxmox 4096 26. Jul 11:38 /home/hpc/Fotos

Und von sudo getfacl /home/hpc/Fotos
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: home/hpc/Fotos
# owner: hpc
# group: proxmox
user::rwx
group::r-x
other::---

 

[adfsrg]

Ich habe die KI jetzt schon eine Stunde bemüht, aber alle Versuche schlagen fehl …

Kann es sein, dass du die KI falsch nutzt? Gib ihr mal per SSH Zugriff und trag den Nutzer in sudoers so ein, so dass sie für sudo kein Passwort braucht. Dann kann die KI komplett automatisch auf dem Gerät arbeiten und das Problem lösen. Dann gibt's du ihr noch Zugriff auf den anderen Rechner und sie kann direkt ausprobieren, ob die Freigabe funktioniert. Denk natürlich vorher ans Backup und ändere hinterher alle Zugangsdaten.

 

[Azghul0815]

Ich versteh den Aufbau noch nicht ganz. Liegen die Bilder in einer VM oder einenm Cointainer? Wegen dem Proxmox?

 

[HPC]

Der Debian Rechner fungiert aktuell als Server. Das ist erst mal eine Übergangslösung. Perspektivisch soll alles nur noch unter Proxmox laufen, aber Jellyfin läuft aktuell als LXC auf Proxmox. Das ist aktuell alles zum Probieren und Testen. Sprich Jellyfin greift auf den unter Debian freigegebenen Ordner zu

 

[Tevur]

Gib ihr mal per SSH Zugriff und trag den Nutzer in sudoers so ein, so dass sie für sudo kein Passwort braucht.

Oh my fucking god.... 😱

 

[adfsrg]

@Tevur Funktioniert super. Die KI macht mir meine komplette Linux-Administration und es funktioniert einfach.

 

[Renegade334]

Ich tippe auf ein Berechtigungsproblem auf Dateisystemebene. Im ersten Share hast du force user und force group genutzt, daher dürfte das da nicht auffallen. Teste das mal als Gegenbeispiel bei dem 2. Share und schaue, ob du dann lesend zugreifen kannst.

Normal wäre eine kurze Config wie z.B.:

[Fotos]
path = /home/hpc/Fotos
valid users = @hpc
read only = no

create mask = 0664
directory mask = 0775

[Fotos_Proxmox]
path = /home/hpc/Fotos

valid users = @proxmox

read only = yes
browseable = yes

Und dann mit ACLs oder einer gemeinsamen Gruppe auf Dateisystemebene zu berechtigen. Den Share würde ich nicht als Einschränkung nutzen, da sonst lokal andere Rechte als Remote gelten.

Dann könntest du sogar mit nur einem Share arbeiten.

 

[h2f]

Ich hatte am Anfang das Problem, daß ich nicht verstanden hatte, daß lokale Rechte auf Dateisystemebene und Zugriffsrechte auf die Shares 2 verschiedenen Dinge sind und beide für den remote zugreifenden User passen müssen.

 

[Azghul0815]

Ok, ich hab SMB und NFS freigaben im LXC nur mit einbinden im Host und dann weiterleiten an den LXC hinbekommen.

im Host in der /etc/fstab hab ich folgendes eingetragen:

# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)
//192.168.178.30/Speicher/ /mnt/lxc_shares/backup cifs _netdev,x-systemd.automount,noatime,uid=48,gid=48,dir_mode=0777,file_mode=0777,user=NAME,pass=PASSWORD 0 0

und dann in der Config des Containers:
z.b. /etc/pve/lxc/100.conf

mp0: /mnt/lxc_shares/backup,mp=/mnt/nas/backup

 

[foofoobar]

Ich habe die KI jetzt schon eine Stunde bemüht, aber alle Versuche schlagen fehl …

Ich hätte die Zeit an deiner Stelle mit der Prüfung von Logfiles verbracht wenn du nicht so in dem Thema bist.

 

[Sykehouse]

Jellyfin läuft aktuell als LXC auf Proxmox

Ein unprivilegierter Container kann nicht auf SMB Shares zugreifen. Entweder was @Azghul0815 sagt oder du stellst den Container auf privilegiert, mit allen Implikationen bezüglich Sicherheit (daher eher nicht zu empfehlen, wenn auch im Heimnetz nicht unmittelbar gefährlich)

Edit: Hier gibt es ausführliche Lektüre zum Thema.

 

[Derduke]

Ok, ich hab SMB und NFS freigaben im LXC nur mit einbinden im Host und dann weiterleiten an den LXC hinbekommen.

im Host in der /etc/fstab hab ich folgendes eingetragen:

# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)
//192.168.178.30/Speicher/ /mnt/lxc_shares/backup cifs _netdev,x-systemd.automount,noatime,uid=48,gid=48,dir_mode=0777,file_mode=0777,user=NAME,pass=PASSWORD 0 0

und dann in der Config des Containers:
z.b. /etc/pve/lxc/100.conf

mp0: /mnt/lxc_shares/backup,mp=/mnt/nas/backup

Müssen da nicht noch die Rechte angepasst werden im Container?

In deinem Beispiel uid gid auf 1048

 

[Azghul0815]

Das läuft zumindest seit ein paar Jahren so.

 

[Sykehouse]

Wenn mit Permissions 777 gemoutet wird, klappt Lesen, für Schreibzugriff aus dem Container sind tatsächlich weitere Kilmmzüge nötig siehe mein Link, den ich oben noch eingefügt habe.

User und Passwort sollte man übrigens besser in ein Credential File auslagern statt direkt in die fstab zu schreiben.

 

[HPC]

Ich tippe auf ein Berechtigungsproblem auf Dateisystemebene. Im ersten Share hast du force user und force group genutzt, daher dürfte das da nicht auffallen. Teste das mal als Gegenbeispiel bei dem 2. Share und schaue, ob du dann lesend zugreifen kannst.

Normal wäre eine kurze Config wie z.B.:

[Fotos]
path = /home/hpc/Fotos
valid users = @hpc
read only = no

create mask = 0664
directory mask = 0775

[Fotos_Proxmox]
path = /home/hpc/Fotos

valid users = @proxmox

read only = yes
browseable = yes

Und dann mit ACLs oder einer gemeinsamen Gruppe auf Dateisystemebene zu berechtigen. Den Share würde ich nicht als Einschränkung nutzen, da sonst lokal andere Rechte als Remote gelten.

Dann könntest du sogar mit nur einem Share arbeiten.

Wenn ich das mache, dann komme ich mit dem User hpc per Netzwerk nicht mehr auf den Ordner.
Ich hatte ja oben einen Ausschnitt von getfacl des Ordners gemacht. Müsste das so nicht eigentlich passen?

Ein unprivilegierter Container kann nicht auf SMB Shares zugreifen. Entweder was @Azghul0815 sagt oder du stellst den Container auf privilegiert, mit allen Implikationen bezüglich Sicherheit (daher eher nicht zu empfehlen, wenn auch im Heimnetz nicht unmittelbar gefährlich)

Edit: Hier gibt es ausführliche Lektüre zum Thema.

Der Container ist aktuell priviligiert. Ich konnte damals zumindest die Freigabe vom damaligen Windows Rechner mounten. OK, aber gut zu wissen, dass man das besser nicht machen sollte. Aber sollte dann stand jetzt nicht trotzdem der Zugriff klappen?

Kurzer Nachtrag: Ich habe den User jellyfin mal der Gruppe hpc zugeordnet. Damit klappe der Zugriff. Meine Vermutung sind fehlende Rechte, aber ich stehe gerade auf dem Schlauch was nicht richtig sein soll ...