[gelöst] debian smb mount keine Berechtigung

[joe2017]

Guten Morgen zusammen,

ich habe ein kleines Problem und komme nicht weiter. Ich habe folgende Konstellation:

Server1 = Microsoft Active Directory Server
Server2 = Debian Samba Share
Server3 = Debian Server

Ich möchte eine smb mount von meinem Server3 auf den Server2 herstellen. Der Mount ist erfolgreich hergestellt. Jedoch habe ich mit meinem User keine Berechtigung.
Von Windows aus funktionieren meine Netzlaufwerke mit dem selben User einwandfrei.

Mein Test Mount Befehl sieht wie folgt aus:

Code: Alles auswählen

sudo mount -t cifs -o -rw,credentials=/path/to/file,cifsacl,uid=MS-Domain-User-UID //IP-Server2/Freigabe /path/to/local/mount

Als Admin angemeldet sehe ich mit ls -l die Ordner. Jedoch haben diese root Berechtigungen.
Als Admin angemeldet sehe ich mit getfacl die Berechtigungen. Jedoch sind die owner und group Berechtigungen mein Lokaler Admin (rwx).

Wenn ich mich als Benutzer anmelde hab ich somit keine Berechtigungen. Jedoch ist dieser User in Gruppen eingetrgen welche Berechtigungen erhalten.
Unter Windows funktioniert das alles einwandfrei. Unter Debian irgendwie nicht.

Ich hoffe mir kann hier jemand weiterhelfen.

[slu]

Du mountest ja mit sudo = root oder sehe ich das falsch?

[joe2017]

Nein ich mounte mit den credentials welche in meiner Daatei stehen.

[joe2017]

Ich habe gerade festgestellt, dass die Berechtigungen mit getfacl nicht identisch sind.

Auf meinem Server3 wo ich den mount einrichte sehe ich lediglich folgende acls Rechte

Code: Alles auswählen

# owner: admin
# group: admin
user::rwx
group::rwx
other::---

Auf meinem Server2 wo sich die shares befinden sehe ich alle gesetzen acls.

Code: Alles auswählen

# owner: admin
# group: admin
user::rwx
group::rwx
group:domainGROUP1:rwx
group:domainGROUP2:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:domainGROUP1:rwx
default:group:domainGROUP2:rwx
usw...

Weshalb sehe ich die zusätzlichen acls nicht in meinem mount? Fehlt Hier noch etwas damit diese gelesen werden können?

[oln]

Moin.
hast du den Mointpoint als lokaler User angelegt? Dann ist ja wohl klar warum die ACLs fehlen. Haben die Dateien in dem Mountpoint die ACLs?

[joe2017]

Ich habe gerade folgendes festgestellt.

Ich habe zwei unterschiedliche mountpoints. Beide verwenden die selbe credentials Datei.
Eine Freigabe von einem Windows Server
Die andere von dem Debian Server

wenn ich mir nach dem "mount -a" mit "ls -l" die Rechte anschaue, sehen diese wie folgt aus.

Code: Alles auswählen

sudo ls -l /path/mount/
DOMAIN\USER DOMAIN\GROUP Windows-Server-Mount-Pfad
local-admin local-admin Debian-Server-Mount-Pfad

In dem ersten Mount werden die Credentials richtig verwendet und auch mit getfacl kann ich die Rechte sehen.
In dem zweiten Mount sehe ich immer nur den Debian local-admin und auch mit getfacl werden nur diese Rechte angezeigt.

Die Mount Einträge in der /etc/fstab unterscheiden sich lediglich durch den Server

Code: Alles auswählen

//Server-IP/path	/path/mount/Windows-Server-Mount-Pfad	cifs	rw,credentials=/home/local-admin/.file,cifsacl,uid=xxx,gid=xxx,auto	0	0
//Server-IP/path	/path/mount/Debian-Server-Mount-Pfad	cifs	rw,credentials=/home/local-admin/.file,cifsacl,uid=xxx,gid=xxx,auto	0	0

Irgendwie komm ich nicht dahinter wo das Problem ist?

Wenn ich mit dem local-admin jetzt eine Datei in dem Debian-Server-Mount-Pfad/path1/file.txt anlege und diese auf dem Debian SMB Server mit getfacl überprüfe stimmen auch die Rechte (DOMAIN\USER DOMAIN\GROUP)

[joe2017]

Hat noch jemand eine Idee wo der Fehler liegen könnte?

Ich habe keine Idee weshalb die acl Informationen nicht an den Server weitergegeben werden?

Wenn ich auf dem Debian Server den Pfad mounte, sollten die acls doch trotzdem angezeigt werden. Schließlich kann ich ja auch mit getent passwd/group die Informationen von meinem Windows Domain Controller abfragen. Somit kann es eigentlich nur noch an einem Fehler in dem Mount sein?

Wenn ich von einem Windows Client denselben Mount als Netzlaufwerk verbinde, werden mir die acls auch richtig angezeigt. Somit dürfte das Problem nicht an meinem Debian Samba Server liegen.

Andererseits, wenn man die beiden Mounts (Windows Server/Debian Samba) auf meinem Debian Server vergleicht, gibt es ja auch keinen Unterschied. Und auf die Windows Server SMB Freigabe kann ich zugreifen.

Ich kann lediglich auf meinen Debian Samba Share von einem Debian Server nicht richtig zugreifen. Und das auch nur nicht mit einem Domain User, da die acls nicht richtig mitgegeben/angezeigt werden, und dieser somit keinen Zugriff erhält.

Ich bin gerade echt überfragt wo das Problem herkommt...

[debilian]

ist die Arbeitsgruppe von debian und Windows Geräten identisch?

[oln]

Moin,
sind die beiden Linux-Kisten der Domain beigetreten?

[joe2017]

Hallo und danke für die Rückfrage.
Ja beide Debian Server sind der Domain beigetreten. Andernfalls könnte ich ja keine user und gruppen abfragen.

Ich habe hier auch noch den Auszug meiner acl Berechtigungen.

Debian Samba Server (so sind die Berechtigungen vergeben)

Code: Alles auswählen

sudo getfacl /path/to/share/

getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: path/to/share/
# owner: localadmin
# group: localadmin
user::rwx
user:localadmin:rwx
user:domainadmin:rwx
group::rwx
group:system_backup-operators:rwx
group:domain_users:r-x
group:DOMAIN\\domain\040users:r-x
group:DOMAIN\\system_smb_mount:rwx
group:system_smb_mount:rwx
mask::rwx
other::---
default:user::rwx
default:user:localadmin:rwx
default:user:domainadmin:rwx
default:group::rwx
default:group:system_backup-operators:rwx
default:group:domain_users:r-x
default:group:DOMAIN\\domain\040users:r-x
default:group:DOMAIN\\system_smb_mount:rwx
default:group:system_smb_mount:rwx
default:mask::rwx
default:other::---

Debian Server mount (so werden die Berechtigungen angezeigt)

Code: Alles auswählen

sudo getfacl /path/to/share/

getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: path/to/share/
# owner: localadmin
# group: localadmin
user::rwx
group::rwx
other::---

[oln]

Debian Server mount (so werden die Berechtigungen angezeigt)

Code: Alles auswählen

sudo getfacl /path/to/share/

getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: path/to/share/
# owner: localadmin
# group: localadmin
user::rwx
group::rwx
other::---

Den Mountpoint hast du vorher als localadmin angelegt?
Dann wird sich das auch nicht mit einem Mount ändern.
Innerhalb des Mountpoint stimmen die Berechtigungen?
Ändere doch einfach die Rechte des Mountpoints auf die gewünschten.

[joe2017]

Also ich habe jetzt vor dem mounten die acl mit setfacl für meinen mountpoint erstellt.

Code: Alles auswählen

sudo getfacl /path/to/share/

getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: path/to/share/
# owner: localadmin
# group: localadmin
user::rwx
user:localadmin:rwx
user:domainadmin:rwx
group::rwx
group:system_backup-operators:rwx
group:domain_users:r-x
group:DOMAIN\\domain\040users:r-x
group:DOMAIN\\system_smb_mount:rwx
group:system_smb_mount:rwx
mask::rwx
other::---
default:user::rwx
default:user:localadmin:rwx
default:user:domainadmin:rwx
default:group::rwx
default:group:system_backup-operators:rwx
default:group:domain_users:r-x
default:group:DOMAIN\\domain\040users:r-x
default:group:DOMAIN\\system_smb_mount:rwx
default:group:system_smb_mount:rwx
default:mask::rwx
default:other::---

Nach dem mounten sehen die Berechtigungen wieder wie folgt aus.

Code: Alles auswählen

sudo getfacl /path/to/share/

getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: path/to/share/
# owner: localadmin
# group: localadmin
user::rwx
group::rwx
other::---

[joe2017]

Es muss doch einen Grund dafür geben, weshalb die acls nicht angezeigt werden.
Ich habe in meinem mount Befehl schon alle Parameter getestet. Alle haben nicht geholfen.
Wenn ich den selben share mit einem Windows Client mounte werden mir die AD Gruppen (acl) doch auch angezeigt.

Weshalb nicht in debian?

[oln]

Ok. Ich hab das jetzt auch mal probiert. Leider hatte ich das gleiche Ergebnis.
Eigentlich ist es auch logisch, denn der User der mountet, dessen Rechte werden auch gesetzt.
Was möchtest du denn errreichen?
Wäre pam_mount etwas für dich?

[joe2017]

Ich möchte erreichen, dass ich wie auch in Windows die Rechte des sharepoints erhalte.
Wie gesgt, wenn ich in Windows den selben sharepoint mounte, werden mir die gesetzten Rechte angezeigt und ich kann auch nur Zugreifen wenn ich Mitglied einer der gesetzten Gruppen bin.
So wie eben eine normale Server-Freigabe funktioniert.

Jetzt ging ich natürlich davon aus, dass wenn ich in Debian ein sharepoint mounte ebenfalls die gesetzten Rechte sehe und besitze.

Aus diesem Grund habe ich auch in meine credentials Datei den benötigten User eingetragen.
Dieser User steht auch in der gesetzten Gruppe und sollte somit Zugriff erhalten. Jedoch werden die acls nicht angezeigt und somit anscheinend auch nicht verwendet.

[oln]

Aber das ist genau was pam_mount macht.
In Windows:
-User loggt sich ein
- Verbindet Freigaben per GPO oder händisch in "seinem" Userspace.
- Verzeichnis(mountpoint) hat seine Rechte.

Oder übersehe ich etwas?

Da du unter Linux(fstab) mountest, erhält der Mountpoint root-Rechte.

[joe2017]

pam_mount sagt mir ehrlich gesagt nichts. Das schau ich mir morgen gleich mal an.

[joe2017]

Also ich bin mir nicht sicher was ich falsch mache. Aber mit pam_mount passiert leider gar nichts.

Ich habe folgendes durchgeführt.

sudo apt install libpam-mount

Überprüft ob folgende Einträge vorhanden sind.
sudo nano /etc/pam.d/common-auth

Code: Alles auswählen

auth	optional	pam_mount.so

sudo nano /etc/pam.d/common-session

Code: Alles auswählen

session	optional	pam_mount.so

Folgenden Eintrag erstellt
sudo nano /etc/security/pam_mount.conf.xml

Code: Alles auswählen

<!-- Volume definitions -->
<volume options="nodev,nosuid"	user"*"	mountpoint="~/shares"	path="SERVER-SHARE-FOLDER"	server="SERVER-IP"	fstype="cifs" />

<luserconf name=".pam_mount.conf.xml" />

Nach der Anmeldung wurde weder der Ordner ~/shares angelegt, noch der mount verbunden.
Hab ich noch etwas vergessen?

[joe2017]

Ich habe den Fehler im Log (/var/log/auth.log) gefunden.
Syntax error in /etc/security/pam_mount.conf.xml

Jetzt funktioniert alles! SUPER HINWEIS mit dem pam_mount!

[oln]

moin,
super das es jetzt geklappt hat.

[joe2017]

Ich habe jedoch noch eine Frage.

Da es sich um einen Server handelt welcher services im Hintergrund ausführt, müsste der Mountpoint auch hier vorhanden sein.
Jedoch ist dieser ja nur während einer Anmeldung verfügbar. Wie kann ich das anpassen?

Ich dachte es wäre ausreichend wenn ich folgenden parameter anpasse

sudo nano /etc/security/pam_mount.conf.xml

Code: Alles auswählen

<mkmountpoint enable="1" remove="false" />

Aber damit wird nur der mountpoint nicht gelöscht. Der mount an sich ist aber nicht mehr vorhanden.
Gibt es hierfür auch einen dauerhaften mount?

Kann man nicht einen fixen user mount beim systemstart eintragen?

[oln]

Mit pam_mount ist mir das nicht bekannt, dass es geht. Läuft ja auch über die Session. Und wenn die Session beendet wird, dann ist auch der Mount weg.
Wenn du eine ständige Verbindung für Dienste haben möchtest, dann ist schon die fstab der richtige weg.

[joe2017]

Aber dann habe ich wieder das Problem, dass der mount nicht die richtigen Rechte besitzt.
Bei pam_mount hat das alles gepasst.

Kann ich bei einem fstab mount vielleicht owner & group mitgeben?

[oln]

Eigentlich brauchst du das nicht.
Dein Dienst läuft doch bestimmt als root und sollte da rein schreiben können. Auf dem Share sollten dann die ACLs durch die default-ACLs richtig gesetzt werden.
Wenn das nicht dem entspricht, musst du mir noch einmal dein Szenario genauer beschreiben.

PS: Würdest du hier deine Config veröffentlichen? Evtl. möchte jemand anderes diese Sachen mal verwenden.

[joe2017]

Nein, der Service wird leider mit einem bestimmten Domain User ausgeführt, da nur dieser die ensprechenden Rechte besitzt.
Hierbei handelt es sich um einen Webserver, in welchem mehrere dieser Services angelegt sind.

Ich muss somit zwingend ein Mountpoint mit den User Rechten dieses Users anlegen.
Mit dem pam-mount funktioniert das. Jedoch nur solange wie der Benutzer angemeldet ist. Nach dem Logoff wird ja der mount wieder geschlossen.
Evtl. würde ein autologin weiterhelfen. Was jetzt aber nicht die sauberste Lösung ist. Und es handelt sich auch um einen Server, welcher keine GUI installiert hat.