Основная проблема заключается в том, что у меня есть подключенный к домену QNAP, и я хочу публиковать снимки RSnapshot через Samba, чтобы пользователи могли восстанавливать свои файлы из резервных копий. (Согласно оригинальному руководству по RSnapshot:http://rsnapshot.org/rsnapshot/docs/docbook/rest.html#restoring-backups)
Однако, если я не установлю ACL по умолчанию (setfacl -mg:MYDOM\Domain\ Users:rx), который будут наследовать новые снимки, я просто не смогу просматривать содержимое общих снимков.
Обзор RSnapshot
Он создает ежечасные / ежедневные / еженедельные / ежемесячные снимки и правильно сохраняет стандартные и расширенные списки контроля доступа Linux. Снимки хранятся в следующем каталоге:
/share/CACHEDEV1_DATA/Local Backups
Чтобы предотвратить изменение разрешений, я очистил ACL по умолчанию для этого каталога и просто установил разрешения по умолчанию. Разрешения следующие:
# 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
Это означает, что разрешения по умолчанию для подкаталогов моментальных снимков (hourly.0, hourly.1 и т. д.) выглядят следующим образом:
# 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
На этом этапе RSnapshot полностью протестирован и работает так, как и ожидалось. (Разрешения довольно либеральны, чтобы определить, является ли проблема проблемой разрешений FS или Samba.)
Обзор Самбы
Я создал общий ресурс через WebGUI под названием LocalBackups и, просматривая файл smb.conf, я ожидал, что он будет работать без изменений. Хотя я могу нормально получить доступ к каталогу LocalBackups, каждый раз, когда я пытаюсь получить доступ к одной из резервных копий, например hour.0, hourly.1 и т. д., я получаю сообщение об ошибке «У вас нет прав доступа к \192.168.1.20\LocalBackups\hourly.0.
В smb.conf раздел [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
Раздел [LocalBackups]:
[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
Используя эту конфигурацию, я могу войти в каталог LocalBackupds, но не могу войти ни в один из подкаталогов моментальных снимков, например hourly.0, hourly.1 и т. д.
Закомментированные строки — это то, что я пытался проверить, имеет ли это значение, но поведение было одинаковым как с закомментированными строками, так и без них.
Если я изменю ACL в одном из каталогов снимков (например, hourly.0), включив в него пользователей MYDOM\Domain, мне будет разрешено войти в этот каталог (например, hourly.0) через Samba. Разрешения для каталога будут следующими:
# 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
На данный момент я не смог разобраться, как включить правильное ведение журнала на QNAP. Из базовой информации о журнале WebUI я вижу, что запрос на подключение SMB проходит с моим именем пользователя и т. д. Я склоняюсь к тому, что конфигурация Samba более строгая, чем разрешения FS, но я предполагаю.
На данном этапе я не уверен, подводят ли меня мои знания ACL, Samba или и того, и другого. Есть идеи?
решение1
Вместо того чтобы пытаться решить эту проблему через Samba, я сбросил конфигурацию Samba до значения по умолчанию, созданного QNAP. (Т.е. раскомментировал закомментированные строки. Это также кажется безопаснее в долгосрочной перспективе, поскольку веб-интерфейс может потенциально перезаписать настроенный файл, smb.confесли я или другие администраторы создадут новые общие ресурсы и т.п.)
Затем я изменяю разрешения файловой системы, чтобы добавить расширенный ACL для MYDOM\Domain Usersгруппы с правом чтения r+xдля каталогов:
/share
/share/CACHEDEV1_DATA
/share/CACHEDEV1_DATA/homes
Таким образом, когда файлы резервируются, пользователи домена могут перемещаться по всему пути к каталогу homes. Однако, поскольку нет ACL по умолчанию, который наследуется от каталога снимков ( /share/CACHEDEV1_DATA/Local Backups), и нет изменений в домашних каталогах пользователей, только исходные пользователи могут получить доступ к своим собственным домашним каталогам.
Изменения RSnapshot
Я думал, что расширенные ACL были сохранены. Это не так, это только выглядело правильно, потому что стандартные ACL домашних каталогов были настроены с доменным пользователем и группой. Так что стандартные ACL были сохранены, но не расширенные. Чтобы исправить это, я отредактировал скрипт rsnapshot и добавил флаг -Aв rsync, изменив:
my $default_rsync_short_args = '-a';
к
my $default_rsync_short_args = '-aA';
Чтобы исправить доступ к каталогам снимков (например, hourly.0 и т. д.), я также добавил изменение прав доступа к create_backup_point_dirфункции, добавив в самом низу функции:
system("setfacl -m g:MYDOM\\\\Domain\\ Users:rx \"$destpath\"");
Теперь все работает так, как и ожидалось, и пользователи могут восстанавливать свои личные файлы из резервных копий. :)
Я попробую включить это в патч для rsnapshot, как только проведу еще несколько тестов.