Das grundlegende Problem besteht darin, dass ich ein mit einer Domäne verbundenes QNAP habe und die RSnapshot-Snapshots über Samba veröffentlichen möchte, damit Benutzer ihre eigenen Dateien aus Backups wiederherstellen können. (Gemäß dem ursprünglichen RSnapshot-HowTo:http://rsnapshot.org/rsnapshot/docs/docbook/rest.html#restoring-backups)
Wenn ich jedoch keine Standard-ACL (setfacl -mg:MYDOM\Domain\ Users:rx) festlege, die die neuen Snapshots erben, kann ich den Inhalt der freigegebenen Snapshots einfach nicht durchsuchen.
RSnapshot Übersicht
Es erstellt stündliche/tägliche/wöchentliche/monatliche Snapshots und bewahrt die standardmäßigen und erweiterten Linux-ACLs korrekt auf. Die Snapshots werden im folgenden Verzeichnis gespeichert:
/share/CACHEDEV1_DATA/Local Backups
Um Änderungen an den Berechtigungen zu verhindern, habe ich die Standard-ACLs dieses Verzeichnisses gelöscht und einfach die Standardberechtigungen festgelegt. Die Berechtigungen sind:
# ls -al
drwxrwxrwx 4 admin administ 4096 Nov 22 17:00 Local Backups/
# getfacl Local\ Backups/
# file: Local Backups/
# owner: admin
# group: administrators
user::rwx
user:admin:rwx
user:guest:---
group::rwx
group:MYDOM\domain\040users:r-x
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx
Dies bedeutet, dass die Standardberechtigungen der Snapshot-Unterverzeichnisse (hourly.0, hourly.1 usw.) wie folgt aussehen:
# cd hourly.0
# ls -al
drwxrwxrwx 3 admin administ 4096 Nov 22 16:02 ./
# getfacl .
# file: .
# owner: admin
# group: administrators
user::rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx
An diesem Punkt ist RSnapshot vollständig getestet und funktioniert wie erwartet. (Die Berechtigungen sind ziemlich großzügig, um herauszufinden, ob die FS-Berechtigungen oder Samba das Problem sind.)
Samba Übersicht
Ich habe über die WebGUI eine Freigabe namens LocalBackups erstellt und würde beim Überprüfen der Datei smb.conf erwarten, dass sie ohne Änderungen funktioniert. Obwohl ich problemlos auf das Verzeichnis LocalBackups zugreifen kann, erhalte ich jedes Mal, wenn ich versuche, auf eines der Backups zuzugreifen, d. h. hour.0, hourly.1 usw., die Fehlermeldung „Sie haben keine Berechtigung, auf \192.168.1.20\LocalBackups\hourly.0 zuzugreifen.“
In der Datei smb.conf lautet der Abschnitt [global]:
[global]
# Add this, apparently Windows 7 Bug.
# acl allow execute always = yes
log level = 3
passdb backend = smbpasswd
workgroup = MYDOM
security = ADS
server string =
encrypt passwords = Yes
username level = 0
#map to guest = Bad User
null passwords = yes
max log size = 10
socket options = TCP_NODELAY SO_KEEPALIVE
os level = 20
preferred master = no
dns proxy = No
smb passwd file=/etc/config/smbpasswd
username map = /etc/config/smbusers
guest account = guest
directory mask = 0777
create mask = 0777
oplocks = yes
locking = yes
disable spoolss = no
load printers = yes
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.@upload_cache/.qsync/.qsync_sn/.@qsys/.streams/.digest/
delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
server role = auto
use sendfile = yes
unix extensions = no
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = no
wide links = yes
#force unknown acl user = yes
force unknown acl user = yes
template homedir = /share/homes/DOMAIN=%D/%U
inherit acls = yes
domain logons = no
min receivefile size = 256
case sensitive = auto
domain master = auto
local master = no
enhance acl v1 = yes
remove everyone = yes
conn log = no
kernel oplocks = no
max protocol = SMB2_10
smb2 leases = yes
durable handles = yes
kernel share modes = no
posix locking = no
lock directory = /share/CACHEDEV1_DATA/.samba/lock
state directory = /share/CACHEDEV1_DATA/.samba/state
cache directory = /share/CACHEDEV1_DATA/.samba/cache
printcap cache time = 0
acl allow execute always = yes
server signing = disabled
aio read size = 1
aio write size = 0
streams_depot:delete_lost = yes
streams_depot:check_valid = no
fruit:nfs_aces = no
fruit:veto_appledouble = no
winbind expand groups = 1
pid directory = /var/lock
printcap name = /etc/printcap
printing = cups
show add printer wizard = no
realm = mydom.local
ldap timeout = 5
password server = mydc001.mydom.local
pam password change = yes
winbind enum users = Yes
winbind enum groups = Yes
winbind cache time = 3600
idmap config * : backend = tdb
idmap config * : range = 400001-500000
idmap config MYDOM : backend = rid
idmap config MYDOM : range = 10000001-20000000
host msdfs = yes
vfs objects = shadow_copy2 acl_xattr catia fruit qnap_macea streams_depot aio_pthread
Der Abschnitt [LocalBackups] lautet:
[LocalBackups]
comment =
path = /share/CACHEDEV1_DATA/Local Backups
browsable = yes
oplocks = yes
ftp write only = no
recycle bin = no
recycle bin administrators only = no
qbox = no
public = yes
#invalid users = "guest"
#read list = @"MYDOM\Domain Users"
#write list = "admin"
#valid users = "root","admin",@"MYDOM\Domain Users"
guest ok = yes
read only = yes
inherit permissions = no
shadow:snapdir = /share/CACHEDEV1_DATA/_.share/LocalBackups/.snapshot
shadow:basedir = /share/CACHEDEV1_DATA/Local Backups
shadow:sort = desc
shadow:format = @GMT-%Y.%m.%d-%H:%M:%S
smb encrypt = disabled
strict allocate = yes
streams_depot:check_valid = yes
mangled names = yes
admin users =
admin only = "admin"
#nt acl support = no
Mit dieser Konfiguration kann ich das Verzeichnis „LocalBackupds“ aufrufen, aber keines der Snapshot-Unterverzeichnisse, also „hourly.0“, „hourly.1“ usw.
Ich habe versucht, die auskommentierten Zeilen auszublenden, um zu sehen, ob sie einen Unterschied machen, aber das Verhalten war mit oder ohne auskommentierte Zeilen konsistent.
Wenn ich die ACL in einem der Snapshot-Verzeichnisse (also hourly.0) ändere, um die MYDOM\Domain-Benutzer einzuschließen, darf ich dieses Verzeichnis (also hourly.0) über Samba betreten. Die Berechtigungen des Verzeichnisses lauten dann:
# cd hourly.0
# ls -al
drwxrwxrwx 3 admin administ 4096 Nov 22 18:00 ./
# getfacl .
# file: .
# owner: admin
# group: administrators
user::rwx
group::rwx
group:MYDOM\domain\040users:rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx
Bisher konnte ich noch nicht herausfinden, wie ich die ordnungsgemäße Protokollierung auf dem QNAP aktivieren kann. Anhand der grundlegenden WebUI-Protokollierungsinformationen kann ich erkennen, dass die SMB-Verbindungsanforderung mit meinem Benutzernamen usw. weitergeleitet wird. Ich neige dazu, dass die Samba-Konfiguration strenger ist als die FS-Berechtigungen, aber das ist nur eine Vermutung.
An diesem Punkt bin ich mir nicht sicher, ob mir meine Kenntnisse über ACLs, Samba oder beides nicht genügen. Irgendwelche Ideen?
Antwort1
Anstatt zu versuchen, dies über Samba zu lösen, habe ich die Samba-Konfiguration auf die Standardeinstellungen zurückgesetzt, die QNAP erstellt hat. (D. h. ich habe die auskommentierten Zeilen auskommentiert. Dies scheint auf lange Sicht auch sicherer, da die Web-GUI die optimierte smb.confDatei möglicherweise überschreiben kann, wenn ich oder andere Administratoren neue Freigaben usw. erstellen.)
Anschließend ändere ich die Dateisystemberechtigungen, um die erweiterte ACL für die MYDOM\Domain UsersGruppe mit Leseberechtigung r+xfür die Verzeichnisse hinzuzufügen:
/share
/share/CACHEDEV1_DATA
/share/CACHEDEV1_DATA/homes
Auf diese Weise können die Domänenbenutzer beim Sichern der Dateien bis zum homesVerzeichnis navigieren. Da es jedoch keine Standard-ACL gibt, die vom Snapshot-Verzeichnis ( /share/CACHEDEV1_DATA/Local Backups) übernommen wird, und keine Änderungen an den Home-Verzeichnissen der Benutzer vorgenommen werden, können nur die ursprünglichen Benutzer auf ihre eigenen Home-Verzeichnisse zugreifen.
RSnapshot-Änderungen
Ich dachte, dass die erweiterten ACLs erhalten blieben. Das war nicht der Fall. Es sah nur richtig aus, weil die Standard-ACLs der Home-Verzeichnisse mit einem Domänenbenutzer und einer Domänengruppe eingerichtet waren. Die Standard-ACLs blieben also erhalten, die erweiterten jedoch nicht. Um dies zu beheben, habe ich das rsnapshot-Skript bearbeitet und das -AFlag zu rsync hinzugefügt, indem ich Folgendes geändert habe:
my $default_rsync_short_args = '-a';
Zu
my $default_rsync_short_args = '-aA';
Um den Zugriff auf die Snapshot-Verzeichnisse (z. B. hourly.0 usw.) zu reparieren, habe ich der Funktion auch eine Berechtigungsänderung hinzugefügt, create_backup_point_dirindem ich ganz unten in der Funktion Folgendes hinzugefügt habe:
system("setfacl -m g:MYDOM\\\\Domain\\ Users:rx \"$destpath\"");
Es funktioniert jetzt wie erwartet und Benutzer können ihre eigenen privaten Dateien aus Backups wiederherstellen. :)
Ich werde versuchen, dies in einen Patch für rsnapshot zu integrieren, sobald ich weitere Tests durchgeführt habe.