Windows -> rsync -> samba: ACL werden nicht übertragen

[Tintom]

Hallo,
ich habe hier ein Active Directory mit einem Windows Server. Nun soll ein Debian Buster mit samba hinzustoßen und sich um Dateiarchivierung des ADS kümmern. Für die Dateisynchronisation möchte ich rsync benutzen, hier beginnen die Probleme... Momentan sieht mein Versuchsaufbau in einer VM wie folgt aus:

1. Freigaben des Windows-Servers werden mittels mount.cifs nach /mnt/freigabe gemountet
2. Mittels rsync -a -H -A -X /mnt/freigabe /srv/samba/<Datum>
3. Der Ordner /srv/samba/ wird mit samba im Netz freigegeben

Jedoch: Egal was ich tue, ich kann die Windows-Zugriffsrechte nicht mit rsync übertragen.

Gibt es einen Weg die Windows-ACLs mit rsync zu übertragen?

[JTH]

Hast du mal im Samba-Wiki geschaut? Samba Extended ACL Support und besonders Enable Extended ACL Support in the smb.conf File.

Nachtrag, anderer Hinweis: Hast du beim mount.cifs die Option cifsacl mit angegeben?

[Tintom]

Hallo und Danke für den Input!

Nachtrag, anderer Hinweis: Hast du beim mount.cifs die Option cifsacl mit angegeben?

Nein, weil ich auch ohne diese Option mit getcifsacl /mnt/freigabe/datei bereits sämtliche Berechtigungen angezeigt bekomme.

Jedoch bekomme ich bei https://wiki.samba.org/index.php/Settin ... s_and_ACLs ab dem Punkt Select the security tab einen Fehler. Wenn ich mit Windows den lokalen Administrator hinzufügen und ihm volle Berechtigungen für den Share geben will erhalte ich die Fehlermeldung 'Fehler beim Aufzählen der Objekte im Container. Zugriff verweigert'.

In der smb.conf existiert der Eintrag user map = /etc/samba/user.map und dort widerum steht drin: !root = DOMAIN\Administrator DOMAIN\administrator und die Samba-Maschine ist auch ohne Fehler der Domain beigetreten.

[weshalb]

Jedoch: Egal was ich tue, ich kann die Windows-Zugriffsrechte nicht mit rsync übertragen.

Gibt es einen Weg die Windows-ACLs mit rsync zu übertragen?

Das ist leider so, Rechte aus Windows werden mit Linux nicht beachtet. Man kann auf Windows alle Dateien wohl in einen Tarbal packen, den mit rsync zu sharexyz verschieben und dann msseitig wieder auspacken...da bleiben deine Dateierechte erhalten, doch das ist nicht das, was du möchtest.

Du könntest dir allerdings eine Samba-Rechte-Struktur auf dem Debianserver (je nach Umfang)aufbauen, die dem vom MS Server entspricht und dann die User msseitig mit den Zugangsdaten vom Samba an den Sambashare anbinden.

[habakug]

Hallo,

wie ist denn die Ausgabe von

Code: Alles auswählen

# net rpc rights list privileges SeDiskOperatorPrivilege -U "SAMDOM\administrator"

?

Gruss, habakug

[Tintom]

Hallo,
die Ausgabe ist:

Code: Alles auswählen

# net rpc rights list privileges SeDiskOperatorPrivilege -U "Domain\administrator"

SeDiskOperatorPrivilege:
  BUILTIN\Administrators

[habakug]

Hallo,

auch die Gruppe 'Domain Admins' benötigt das Privileg (AD ohne winbind):

Code: Alles auswählen

# net rpc rights grant "DOMAIN\Domain Admins" SeDiskOperatorPrivilege -U "DOMAIN\administrator"

Dann solltest du die Rechte auf dem Share mit den RSAT-Tools setzen können.

Gruss, habakug

[Tintom]

Leider nein, die Fehlermeldung bleibt gleich.

[habakug]

Hallo,

sind auf dem Fileserver keytabs vorhanden?

Code: Alles auswählen

# klist -k

Der AD-Server sollte der erste Nameserver in der resolv.conf des Fileservers sein.
Auf dem Windowsrechner:

Code: Alles auswählen

nslookup
[...]
> set type=SRV
> _ldap._tcp.domain.com.

sollte eine Ausgabe haben.

Gruss, habakug

[Tintom]

Hallo,
# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/archiv.domain@DOMAIN
2 host/ARCHIV@DOMAIN
2 host/archiv.domain@DOMAIN
2 host/ARCHIV@DOMAIN
2 host/archiv.domain@DOMAIN
2 host/ARCHIV@DOMAIN
2 host/archiv.domain@DOMAIN
2 host/ARCHIV@DOMAIN
2 host/archiv.domain@DOMAIN
2 host/ARCHIV@DOMAIN
2 ARCHIV$@DOMAIN
2 ARCHIV$@DOMAIN
2 ARCHIV$@DOMAIN
2 ARCHIV$@DOMAIN
2 ARCHIV$@DOMAIN

Auf dem Win-Server:

>nslookup
Standardserver: localhost
Address: ::1

> set type=SRV
> _ldap._tcp.DOMAIN
Server: localhost
Address: ::1

_ldap._tcp.DOMAIN SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = Server.DOMAIN
Server.DOMAIN internet address = 192.168.100.99

Der AD-Server sollte der erste Nameserver in der resolv.conf des Fileservers sein.

Ich lasse den Fileserver momentan über DHCP ihre Informationen beziehen. Dort steht:
domain DOMAIN
search DOMAIN
nameserver 192.168.100.99
nameserver 192.168.100.1

[weshalb]

Kann mir mal einer weiterhelfen? Bezogen auf die Threaderöffnung stößt mir dieser Satz nach wie vor auf.

Jedoch: Egal was ich tue, ich kann die Windows-Zugriffsrechte nicht mit rsync übertragen.

Seit wann bleiben Windowszugriffsrechte, sobald man diese mittels rsync unter linuxoiden Systemen kopiert, erhalten?

Wenn ich hier ein MS Laufwerk unter Debian mounte und die Files per Rsync sichere, haben die ab dem Zeitpunkt die Rechte des jeweiligen Owners unter Debian.

Worum geht es bei den Lösungsvorschlägen jetzt eigentlich?

[habakug]

Hallo,

es geht hier (auch) um

[...]die Fehlermeldung 'Fehler beim Aufzählen der Objekte im Container. Zugriff verweigert'.

Siehe erstes Posting. Das bedeutet, dass möglicherweise für den betreffenden Ordner die Vererbung abgeschaltet ist und daher Rechte fehlen. Da hier der Administrator betroffen ist, muss man einige Dinge prüfen.

Gruss, habakug

[Tintom]

Wenn ich hier ein MS Laufwerk unter Debian mounte und die Files per Rsync sichere, haben die ab dem Zeitpunkt die Rechte des jeweiligen Owners unter Debian.

Ich wäre mittlerweile auch zufrieden wenn der MS-Server seine Daten direkt auf den Samba-Rechner schreiben könnte. Die Funktionalität von rsync könnte ich auch durch Verwendung von MS-Tools so ähnlich realisieren. Aber irgendetwas ist an meiner Konfiguration falsch. Ich glaube, ich überdenke meinen Ansatz noch einmal von Grund auf.

[weshalb]

Wenn ich hier ein MS Laufwerk unter Debian mounte und die Files per Rsync sichere, haben die ab dem Zeitpunkt die Rechte des jeweiligen Owners unter Debian.

Ich wäre mittlerweile auch zufrieden wenn der MS-Server seine Daten direkt auf den Samba-Rechner schreiben könnte. Die Funktionalität von rsync könnte ich auch durch Verwendung von MS-Tools so ähnlich realisieren. Aber irgendetwas ist an meiner Konfiguration falsch. Ich glaube, ich überdenke meinen Ansatz noch einmal von Grund auf.

Das praktiziere ich sehr häufig. Ganz billig>

- lege einen Nutzer auf dem Debian und einen Order für ihn an
- vergebe dem Ordner die Rechte des Nutzers
- lege per smbpasswd ein Passwort für den Nutzer an
- bereinige deine smb.conf dementsprechend Beispiel

Code: Alles auswählen

[global]
  workgroup = WORKGROUP
  server string = Samba Server %v
  netbios name = debian
  security = user
  map to guest = bad user
  dns proxy = no
  
 [share]
   comment = share
   path = /home/share
   writable = yes
   guest ok = no
   browseable = no
   create mask = 0600
   directory mask = 0600
   force create mode = 0600
   force directory mode = 0600
  

- mounte mittels der erstellten Zugangsdaten Nutzer und smbpasswort direkt im MS Server das Sambalaufwerk

Ich kopiere dann nachts diese Daten per rsnapshot inkrementell weg und mounte diesen Ordner mit lediglich Leserechten als Archiv da, wo es benötigt wird.

[Tintom]

Ja, was soll ich sagen, manchmal sind es die einfachen Dinge, die einem das Leben schwer machen.

Als ich die Lösung von @weshalb angeschaut habe ist mir die Option writable = yes (analog zu: read only = no) aufgefallen. Die taucht im offiziellen Samba-Howto (s.o.) nicht auf und weil ich dachte "root darf alles" und auf den Samba-Server auch nur lesend zugegriffen werden soll, habe ich die Option vernachlässigt.
Nachdem ich die Option gesetzt habe funktioniert nun alles wie es soll. Okay, fast alles: Ich denke ich werde einen Ersatz für rsync brauchen, weil nachwievor root als Eigentümer gespeichert wird und auch keine ACLs von Windows gesichert werden, aber das kann ich wie gesagt mit Windows-Tools umgehen.

Danke @habakug, @JTH und @weshalb!