Відображення ACL ZFS для SMB: як уникнути кошмарів з правами

Ментальна модель, яка зупиняє кровотечу

Ви керуєте трьома різними «мовами» прав доступу:
ACL Windows (клієнти SMB), інтерпретація Samba і модель ACL на диску в ZFS. Якщо вони не погоджуються, користувачам не прийде ввічливе попередження; вони отримають
Access denied, і ваша черга заявок перетвориться на місце злочину.

Ось розумна ментальна модель:

• ZFS зберігає ACL у стилі NFSv4 (також звані «NFS4 ACLs») коли встановлено acltype=nfsv4. Вони можуть представляти ACE у стилі Windows:
  allow/deny, прапорці наслідування та докладні дозволи. Це найкраще відповідність для SMB.
• POSIX-режими все ще існують (rwxrwxrwx), але в залежності від властивостей як aclmode та aclinherit
  вони або є значущим шлюзом, або декоративною наліпкою.
• Samba відображає SID у UNIX ID. Якщо це відображення змінюється, записи ACL все ще вказують на стару ідентичність. ACL не «зламався»;
  ваш шар ідентичностей змінився.
• «Дозволи на шарі шарингу» vs «дозволи на файловій системі»: Samba має обмеження на рівні шарів і ACL на рівні файлової системи. Ефективний доступ —
  це перетин. Ви можете бути щедрим на одному рівні і суворим на іншому, але якщо суворість є в обох — ви винайдете нові страждання.

Ставтеся до вашого середовища як до системи ідентичностей перш за все, системи ACL — другорядно, і системи зберігання — третьою. Такий порядок — не філософія,
а послідовність відмов, які ви побачите в продакшені.

Парафраз ідеї В. Едвардса Демінга застосовний: «погана система переможе хороших людей щоразу». В роботі з правами «система» — це ваш шар відображення і стратегія наслідування.

Цікаві факти та історичний контекст

Трохи контексту допомагає, бо половина сьогоднішнього болю — це вчорашні компроміси.

1. Windows NT впровадив ACL на початку 1990-х з allow/deny семантикою та наслідуванням. Модель старша за сучасні розгортання Samba на кілька десятиліть,
   тому клієнти Windows мають сильні очікування.
2. POSIX-режими старіші і простіші: користувач/група/інші з rwx. Вони не можуть виразити «deny», не можуть виразити винятки для окремих користувачів,
   і наслідування не є нативним.
3. NFSv4 ACL були спроєктовані як багатші за POSIX і ближчі до семантики Windows, тому ZFS опирається на них для дружніх до SMB ACL.
4. Samba давно використовує підключні VFS-модулі; модулі, орієнтовані на ZFS, існують, бо загальна обробка POSIX ACL не може повністю відтворити NFSv4 ACL
   ZFS без трансляції.
5. ZFS епохи Solaris мав NFSv4 ACL як першокласну функцію. Це проектне рішення відлунює в OpenZFS сьогодні: модель ACL не є додатком.
6. «Багаті ACL» не безкоштовні: вони збільшують обсяг метаданих, і операції на кшталт рекурсивного виправлення наслідування можуть бути дорогими.
   Коли проблеми з правами виникають у масштабі, рідко це один файл — частіше це мільйон файлів у дереві.
7. Відображення ідентичностей — прихована залежність: SMB говорить SID; UNIX — UID/GID. Шар SID→UID — саме те місце, де народжується «вчора працювало».
8. ZFS має властивості, що впливають на поведінку ACL (aclmode, aclinherit, xattr). Вони не косметичні налаштування.
   Вони змінюють, що робить chmod і чи поводиться наслідування так, як очікує Windows.

Як ACL ZFS відображаються в SMB (і де це йде не так)

1) Два великі варіанти сумісності: POSIX ACL проти NFSv4 ACL

Якщо ви обслуговуєте SMB для клієнтів Windows і хочете редагувати ACL у стилі Windows — вам потрібно acltype=nfsv4 на датасеті. Це дає ZFS словник ACL,
який може представити концепти Windows: прапорці наслідування, записи «deny» та тонкі дозволи.

POSIX ACL (acltype=posixacl) може підходити для середовищ, орієнтованих на Linux, але відображення в семантику Windows стає «наближеним». «Наближено» —
ввічливе слово. Це як вимірювати дата-центр рулеткою, надрукованою з пам’яті.

2) Завдання Samba: транслювати дескриптори безпеки Windows у файлові ACL

Клієнт Windows надсилає дескриптор безпеки (під капотом щось на кшталт SDDL). Samba оцінює, чи дозволено клієнту його встановити, потім транслює його в
записи ACL файлової системи. З ZFS NFSv4 ACL ця трансляція може бути майже прямою.

Коли трансляція втрачає інформацію — бо файловій системі бракує певного прапорця Windows — Samba робить усе можливе, і вийде «працює здебільшого», поки ви не натрапите
на крайові випадки: успадковані deny, семантика CREATOR OWNER або дивні оцінки членства в групах.

3) Властивості ZFS, що вирішують, чи ви будете прокидатися вночі

• aclmode: контролює, як chmod взаємодіє з ACL. В SMB-середовищах часто хочуть, щоб chmod не стирав наміри ACL.
• aclinherit: контролює, як ACL наслідуються і чи переписуються вони. Якщо це не відповідає очікуванням Windows,
  ви побачите «нові файли не збігаються з правами папки».
• xattr: контролює, як зберігаються розширені атрибути (on, sa). Це може вплинути на продуктивність і поведінку
  для навантажень з інтенсивним використанням ACL, оскільки ACL та метадані SMB використовують xattr.
• casesensitivity: Windows за замовчуванням нечутливий до регістру. Невідповідності тут спричиняють «привидні дублі» або заплутані перевірки доступу.

4) Шар ідентичності: SIDs, UIDs і мистецтво їх не змінювати

Windows використовує SID. ZFS на UNIX-подібній системі врешті-решт застосовує доступ, використовуючи UID/GID. Samba з’єднує це через idmap. Якщо ваша конфігурація idmap
зміниться (або зміниться довіра між доменами), той самий SID може відображатися в інший UID або не відображатися взагалі. Ваші записи ACL все ще посилатимуться на
ідентичності, але вони більше не співпадатимуть із користувачем на проводі.

Саме тут народжується «права раптом зламалися». Нічого випадкового не сталося. Ви змінили лінійку.

Жарт №1: Баги з правами — як блискітки: потрапивши в організацію, ви будете знаходити їх у місцях, яких ніхто не пам’ятає.

5) Записи «deny» і порядок: чому адміністратори Windows можуть миттєво вивести доступ з ладу

Оцінювання ACL у Windows включає явну семантику deny. NFSv4 ACL також можуть виразити deny-записи. Але треба бути обережним із успадкованими deny
і правилами «хто власник файлу». Якщо папка має deny для широкої групи, наслідування може доставити цей deny до файлів у несподіваний спосіб для тих, хто звик
до «ми просто додамо allow».

Навчіть своїх адміністраторів: уникайте deny, якщо ви не блокуєте щось навмисно і не можете пояснити порядок оцінки. Більшість deny-записів — це політика, яка
виражена як саботаж.

Виберіть стратегію управління правами (і дотримуйтеся її)

Стратегія A: Орієнтація на Windows (рекомендується для середовищ з інтенсивним SMB)

Використовуйте ZFS acltype=nfsv4. Керуйте правами з Windows (Провідник, icacls) і дозвольте Samba записувати ACL. Утримайтесь від змін chmod/chown
з боку Linux на датасетах, що «належать Windows», або принаймні обмежте їх контрольованою автоматизацією, яка поважає властивості ACL.

Вам все одно потрібен UNIX-власник/група для сумісності з POSIX, але розглядайте бітові режими як уявлення сумісності, а не як джерело істини.

Стратегія B: Орієнтація на UNIX з доступом по SMB (працює, але матиме трансляції)

Якщо більшість адміністрування відбувається на Linux, а Windows-клієнти — лише споживачі, POSIX ACL можуть бути прийнятні. Але ви повинні прийняти: редагування прав у Windows UI може поводитись неінтуїтивно.
Ви будете більше вести розмов на кшталт «чому я не можу встановити цей дозвіл».

Стратегія C: Змішане адміністрування з обох боків (уникати)

Ось як виникає дрейф дозволів. Адмін Windows встановлює складний успадкований ACL. Адмін Linux запускає рекурсивний chmod, бо «це виглядало неправильно».
Тепер у вас датасет, повний напівзбереженого наміру і багато нових заявок.

Покроковий план швидкої діагностики

Коли хтось повідомляє «SMB permission denied» або «доступ змінився», не починайте з кліків у Провіднику. Почніть з короткої послідовності, що ізолює,
де саме відмова: ідентичність, обмеження шару шарингу, ACL файлової системи або дрейф наслідування.

Спочатку: ідентичність і відображення (найбільш поширена, найкатастрофічніша)

1. Підтвердіть, що SID користувача відображається в очікуваний UID/GID на сервері.
2. Підтвердіть, що членство в групі видно для Samba (токен має потрібні групи).
3. Підтвердіть, що backend idmap і діапазони не змінювалися.

Друге: обмеження шару SMB

1. Перевірте конфігурацію шарингу: valid users, read only, write list, inherit permissions, veto файли тощо.
2. Перевірте, чи клієнт підключається з очікуваним обліковим записом (кешовані облікові дані — класика).

Третє: ACL файлової системи + властивості ZFS

1. Перевірте властивості датасету ZFS: acltype, aclmode, aclinherit, xattr, casesensitivity.
2. Перевірте ACL файлу/каталогу з сервера, а не лише з Windows.
3. Перевірте наявність явних deny-записів і пошкоджених прапорців наслідування.

Четверте: розслідування «хтось запустив chmod»

1. Шукайте недавні зміни: диф зі знімків, журнали аудиту, якщо ввімкнено, ZFS snapshot-и або шаблони mtime у файловій системі.
2. Визначте, чи ACL були зняті або переписані командою chmod/chown або інструментом міграції.

Практичні завдання: команди, виводи, рішення

Ось завдання, які я реально виконую при відлагодженні відображення ACL ZFS + SMB. Кожне завдання включає реалістичну команду, приклад того, як «добре» або «погано»
виглядає, і рішення, яке ви приймаєте далі.

Завдання 1: Визначити датасет і mountpoint

cr0x@server:~$ zfs list -o name,mountpoint,acltype,aclmode,aclinherit,xattr,casesensitivity tank/share
NAME        MOUNTPOINT    ACLTYPE  ACLMODE    ACLINHERIT  XATTR  CASESENSITIVITY
tank/share  /tank/share   nfsv4    restricted passthrough sa     insensitive

Що це означає: У вас NFSv4 ACL, chmod обмежений від руйнування ACL, наслідування передається, xattr збережені в SA, поведінка нечутлива до регістру.

Рішення: Цей датасет імовірно налаштований для SMB-перших ACL. Перейдіть до перевірки ідентичностей та ефективних ACL замість зміни властивостей.

Завдання 2: Підтвердити, що визначення шару Samba вказує сюди

cr0x@server:~$ testparm -s | sed -n '/^\[share\]/,/^\[/{p}'
[share]
	path = /tank/share
	read only = No
	vfs objects = zfsacl streams_xattr
	inherit acls = Yes
	store dos attributes = Yes

Що це означає: Шлях шару збігається з mountpoint датасету. Активовано VFS-модуль, що розуміє ZFS ACL. DOS-атрибути зберігаються як xattr.

Рішення: Якщо vfs objects не містить zfsacl (або еквіваленту вашої платформи), відображення може бути деградувальним. Виправте конфіг Samba перед зміною ACL.

Завдання 3: Побачити, ким Samba вважає користувача (і його групи)

cr0x@server:~$ wbinfo --user-sid 'EXAMPLE\alice'
S-1-5-21-111111111-222222222-333333333-1107

Що це означає: Доменно-користувач резолюється у SID. Якщо це не вдається, у вас не проблема ACL — у вас проблема з директорією сервісів.

Рішення: Якщо це не вдається, зупиніться і виправте приєднання до домену / winbind / довіру перед будь-якими іншими діями.

Завдання 4: Відобразити SID у UNIX ID і перевірити стабільність

cr0x@server:~$ wbinfo --sid-to-uid S-1-5-21-111111111-222222222-333333333-1107
2001107

Що це означає: Samba відображає SID у UID 2001107. Саме цей UID цікавить механізм застосування прав файлової системи.

Рішення: Якщо відображення змінилося нещодавно, записи ACL, що посилалися на старий UID, більше не будуть співпадати. Розслідуйте backend idmap/діапазони і чи інший сервер не видає різних відображень.

Завдання 5: Перевірити конфіг idmap з перспективи Samba

cr0x@server:~$ testparm -s | grep -E '^idmap config|^security|^realm'
security = ADS
realm = EXAMPLE.COM
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config EXAMPLE : backend = rid
idmap config EXAMPLE : range = 2000000-2999999

Що це означає: Домен EXAMPLE використовує RID-відображення в певний діапазон UID. Це зазвичай стабільно, якщо діапазон узгоджений між серверами.

Рішення: Переконайтесь, що всі SMB-сервери, які торкаються одного датасету ZFS, використовують однаковий backend і діапазони idmap. Інакше ви гарантовано отримаєте невідповідності в ідентичностях на диску.

Завдання 6: Переконатися, що токен користувача містить очікувані групи

cr0x@server:~$ wbinfo --user-groups 'EXAMPLE\alice' | head
S-1-5-21-111111111-222222222-333333333-513
S-1-5-21-111111111-222222222-333333333-2201
S-1-5-21-111111111-222222222-333333333-2209

Що це означає: Це SID груп у списку членств користувача.

Рішення: Якщо право повинно надаватися через групу, але SID групи відсутній, проблема пов’язана з директорією груп, оновленням токену, видимістю вкладених груп або кешуванням winbind — а не з ZFS.

Завдання 7: Подивитися ACL каталогу з боку сервера (у стилі NFSv4)

cr0x@server:~$ ls -V /tank/share/Projects
drwxrwx---+  15 root  domain_users  15 Dec 26 10:12 /tank/share/Projects
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
             everyone@:------a-R-c--s:fd-----:allow

Що це означає: + вказує на ACL, що виходить за межі бітів режиму. Прапорці наслідування (f, d) присутні для файлів/каталогів. Це виглядає як контрольована базова конфігурація.

Рішення: Якщо ви не бачите прапорців наслідування в каталогах, де очікували б їх — ймовірно проблема з конфігурацією наслідування або ACL були скинуті.

Завдання 8: Підтвердити, що вигляд у Windows співпадає (за допомогою інструментів Samba)

cr0x@server:~$ smbcacls //localhost/share Projects -U 'EXAMPLE\alice'
REVISION:1
CONTROL:SR|DP
OWNER:EXAMPLE\Administrator
GROUP:EXAMPLE\Domain Users
ACL:EXAMPLE\Domain Admins:ALLOWED/0x0/FULL
ACL:EXAMPLE\Project Team:ALLOWED/0x0/CHANGE
ACL:EXAMPLE\Domain Users:ALLOWED/0x0/READ

Що це означає: Samba здатна показати узгоджений Windows-ACL клієнтам.

Рішення: Якщо це значно відрізняється від ls -V, відображення може бути деградоване, або ви дивитесь на інший об’єкт (не той шлях), або ваш VFS-модуль не активний.

Завдання 9: Перевірити ефективний доступ для конкретної ідентичності (з боку сервера)

cr0x@server:~$ id EXAMPLE\\alice
uid=2001107(alice) gid=2000513(domain_users) groups=2000513(domain_users),2002201(project_team)

cr0x@server:~$ sudo -u '#2001107' test -w /tank/share/Projects && echo WRITABLE || echo NOT_WRITABLE
WRITABLE

Що це означає: Сервер вважає, що Alice може писати. Це ізолює «файлова система каже так» від «SMB каже ні».

Рішення: Якщо файлова система говорить WRITABLE, але SMB-клієнти отримують відмову, дивіться на обмеження шару шарингу, конфіг Samba, oplocks, veto-файли або автентифікацію клієнта/кешовані креденшіали.

Завдання 10: Виявити, чи режимні біти POSIX використовуються як шлюз

cr0x@server:~$ stat -c '%A %a %U %G %n' /tank/share/Projects
drwxrwx--- 770 root domain_users /tank/share/Projects

Що це означає: Біти режиму 770. Якщо ваш ACL передбачає ширший доступ, але «other» дорівнює 0, деякі інструменти все ще можуть бути обмежені в залежності від налаштувань ACL і шляху оцінки.

Рішення: Якщо користувачі Windows відмовляють у доступі і біт режиму занадто обмежує, перевірте aclmode і aclinherit та впевніться, що ACL містить потрібні allow-записи. Не робіть сліпо chmod 777.

Завдання 11: Перевірити важливі властивості датасету, про які люди забувають

cr0x@server:~$ zfs get -H -o property,value acltype,aclmode,aclinherit,xattr tank/share
acltype	nfsv4
aclmode	restricted
aclinherit	passthrough
xattr	sa

Що це означає: Ця комбінація зазвичай зберігає намір Windows. restricted перешкоджає chmod стирати ACL. passthrough зберігає ACE без змін при наслідуванні.

Рішення: Якщо ви бачите aclmode=discard або aclinherit=discard на SMB-датасеті — це часовий бомба. Виправте властивості, потім відновіть ACL.

Завдання 12: Знайти явні deny-записи, що блокують все

cr0x@server:~$ ls -V /tank/share/Projects/Quarterly
drwxrwx---+  10 root  domain_users  10 Dec 26 10:18 /tank/share/Projects/Quarterly
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
        project_team@:------a-R-c--s:fd-----:deny

Що це означає: Є явний deny для project_team@. Якщо ваші дописувачі у цій групі, вони заблоковані незалежно від інших allow-записів.

Рішення: Видаліть або звузьте deny-запис. В більшості корпоративних дерев deny застосовують як «політику», але політика має належати членству в групах, а не успадкованому deny-гренаці.

Завдання 13: Довести, чи відбувається наслідування для нових файлів

cr0x@server:~$ sudo -u '#2001107' touch /tank/share/Projects/inheritance_test.txt

cr0x@server:~$ ls -V /tank/share/Projects/inheritance_test.txt
-rw-rw----+  1 alice  domain_users  0 Dec 26 10:20 /tank/share/Projects/inheritance_test.txt
                owner@:rw-p--aARWcCos:------:allow
                group@:rw-p--aARWcCos:------:allow
             everyone@:------a-R-c--s:------:allow

Що це означає: Файл успадкував розумний шаблон ACL. Якби ні — ви б побачили відсутні записи або інші прапорці.

Рішення: Якщо нові файли мають «неправильні» ACL, перевірте aclinherit, налаштування Samba inherit acls і чи Windows застосовує інший батьківський ACL, ніж ви думаєте.

Завдання 14: Виявити режим збереження xattr і чи платите ви «податок на метадані»

cr0x@server:~$ zfs get -H -o property,value xattr tank/share
xattr	sa

Що це означає: xattr=sa зберігає невеликі xattr у області dnode «system attributes», зменшуючи окремі I/O для метаданих у навантаженнях SMB з великою кількістю метаданих.

Рішення: Якщо ви бачите погану продуктивність метаданих і xattr=on, розгляньте перехід на sa для нових датасетів (зміна на існуючих може мати наслідки; плануйте обережно).

Завдання 15: Перевірити, що Samba бачить підвантажений модуль ZFS ACL

cr0x@server:~$ smbstatus -b | head -n 15
Samba version 4.19.5
PID     Username     Group        Machine
-------------------------------------------------------------------
4123    alice        domain_users  10.20.30.40 (ipv4:10.20.30.40:52514)

Service      pid     Machine       Connected at
-------------------------------------------------------
share        4123    10.20.30.40    Wed Dec 26 10:21:14 2025

Locked files:
No locked files

Що це означає: Є жива SMB-сесія; ви можете зіставити поведінку клієнта з логами сервера і перевірками файлової системи.

Рішення: Якщо сесій немає, ваша проблема може бути з автентифікацією/підключенням, а не з правами файлів. Не «виправляйте» ACL для проблеми входу.

Завдання 16: Зіставити відмову клієнта з логами Samba (точне логування)

cr0x@server:~$ sudo smbcontrol all debug 3

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2025/12/26 10:22:03.114820,  3] smbd/open.c:5963(open_file)
  open_file: unable to open file Projects/Quarterly/report.xlsx. Error was NT_STATUS_ACCESS_DENIED

Що це означає: Samba відмовляє при відкритті. Це підштовхує вас до оцінки ACL файлової системи або обмежень шару шарингу.

Рішення: Якщо відмова стійка для одного шляху, перевірте ACL цього шляху на явні deny або проблеми з власністю, і підтвердіть групи у токені користувача.

Три корпоративні історії з окопів прав доступу

Міні-історія №1: Інцидент через хибне припущення

Середня компанія мігрувала з Windows-файлового сервера на блискучий кластер SMB на ZFS. План звучав просто: копіювати дані, зберегти дозволи, переключити сервіс.
Менеджер проєкту задав одне питання: «Чи збережуться ACL Windows?» Відповідь була «Так, здебільшого».

В день переключення служба підтримки була завалена запитами. Деякі команди могли читати, але не писати. Інші могли писати, але не перейменовувати. Декілька керівників виявили себе
«власниками» випадкових папок, яких вони не впізнавали — чудовий спосіб налякати людей щодо неочікуваного аудиту.

Коренева причина не в ZFS. Це було припущення, що відображення ідентичностей є універсальним по всіх серверах. Старий Windows-сервер мав стабільні SID.
Нова налаштування Samba використовувала інший idmap backend на одній ноді, ніж на інших. Той самий домен, ті самі користувачі, але різні UID/GID залежно від того,
до якої ноди підключався клієнт.

Підсумок: ACL на диску були «правильними» з точки зору ноди, яка їх записала. Але для іншої ноди вони були нісенітницею.
Це виглядало як випадковий збій прав, бо все залежало від того, куди потрапив з’єднання.

Виправили це стандартизацією backend і діапазонів idmap по кластеру, а потім переписали власників ACL, щоб узгодити відображення. Простої було на кілька годин.
Прибирання тривало тижнями, бо довіра стала справжньою жертвою.

Міні-історія №2: Оптимізація, що повернулася бумерангом

Інша організація мала скаргу на продуктивність: перелік директорій по SMB був повільним у пікові години. Хтось подивився графіки, побачив тиск на метадані і вирішив «спростити» дозволи.
Ідея: зменшити складність ACL, об’єднавши багато ACE у широкі групи, прибрати «шум» наслідування і встановити aclinherit=discard, щоб уникнути запису зайвих успадкованих записів.

Приблизно два дні — все було чудово. Нові файли створювались швидше. Переліки каталогів стали шустріші. Той, хто запропонував це, отримав тихе схвалення керівництва.

Потім проектні команди помітили: нові файли не успадковували очікуваних доступів для крос-функціональних груп. Люди почали надсилати документи електронною поштою,
бо «шаринг зламався». Це сигнал, що ви втрачаєте — коли користувачі вигадують обхід, який також руйнує керування.

Відкат був неефектний: вони повернули наслідування в passthrough, встановили чистий базовий ACL у корені та покращили продуктивність за рахунок правильного вирішення метаданих
(стратегія xattr, вибір recordsize) і припинили робити рекурсивні операції ACL о 9 ранку.

Міні-історія №3: Нудна, але правильна практика, що врятувала

Велика компанія десятиліттями керувала SMB-сервісом на ZFS з мінімальними драмами. Їх секрет не в магічній конфігурації. Він був у дисципліні: один «ACL root»
на шар, стандартизоване найменування груп і правило, що лише інструменти Windows змінюють ACL у продакшн-шарах. Автоматизація Linux могла створювати директорії, але
рекурсивний chmod був під забороною. Назавжди.

Одного дня сталася реорганізація домену: нові групи, застарілі групи, зміни вкладеного членства. Це зміни, які зазвичай перетворюють файлові шари на абстрактне мистецтво.
Вони чекали заявок.

Заявок не було. Чому? У них щоденне завдання перевіряло узгодженість відображення ідентичностей і позначало «невідомі SID» ще до того, як люди помітили.
Вони також агресивно створювали snapshot-и і могли робити diff змін ACL, коли щось пахло невірно.

Під час реорганізації моніторинг показав, що частина SID груп перестала резолюватися на одній SMB-ноді. Вони відключили з’єднання з тієї ноди,
виправили winbind-підключення і повернули її в кластер. Більшість користувачів цього навіть не відчула.

Це була нудна праця. Найкращий тип роботи. Коли хтось запитав, навіщо вони проводять «перевірки здоров’я прав», відповідь була проста: бо альтернатива —
дізнаватися про ACL під час аварії, а це як вчитися плавати під час повені.

Жарт №2: Єдина річ, що пручається довше за застаріле відображення SID, — це людина, яка наполягає «права прості», бо одного разу запустила chmod -R.

Типові помилки: симптом → причина → виправлення

1) Симптом: «Працює на одній SMB-ноді, не працює на іншій»

Коренева причина: Невідповідність idmap backend/діапазонів між нодами; SID→UID різні на різних нодах.

Виправлення: Стандартизувати конфіг idmap на всіх нодах. Перевірити з wbinfo --sid-to-uid на кожній ноді. Лише потім розглядати ремонт ACL.

2) Симптом: «Нові файли не наслідують права папки»

Коренева причина: aclinherit=discard/restricted невідповідність, або вимкнено наслідування в Samba, або у батьківського ACL відсутні прапорці наслідування.

Виправлення: Використовуйте aclinherit=passthrough (або обрану політику), увімкніть inherit acls = yes, і скиньте батьківський ACL, щоб включити правильні прапорці наслідування.

3) Симптом: «Linux chmod виправив… а потім все зламалося пізніше»

Коренева причина: chmod/chown взаємодіяв з ACL через aclmode і стер або переписав записи. Або змінив власність і анульовував цілеспрямований ACE.

Виправлення: Встановіть aclmode=restricted для датасетів, орієнтованих на SMB. Припиніть використовувати рекурсивний chmod на продакшн шарах. Відновіть ACL із відомого доброго шаблону.

4) Симптом: «Усім дозволено читання, але дописувачі не можуть перейменувати/видалити»

Коренева причина: Відсутні права на директорію, як-от delete/rename (або їхні еквіваленти у NFSv4). У Windows семантика видалення пов’язана з батьківською директорією.

Виправлення: Переконайтесь, що група дописувачів має права змін/modify на директорії, а не лише право запису у файли. Перевірте створення, перейменування та видалення з SMB і серверної сторони.

5) Симптом: «Власник показаний як невідомий SID у Windows»

Коренева причина: SID більше не резолюється (групу видалено/перейменовано без збереження SID), або сервер не може зв’язатися з контролерами домену, або кеш idmap зіпсований.

Виправлення: Відновіть підключення до служби каталогів, акуратно очистіть/оновіть кеш winbind, і не переписуйте ACL, поки ідентичності не почнуть резолюватися знову.

6) Симптом: «Частина користувачів отримує Access Denied після змін у домені»

Коренева причина: Зміни членства в групах не відобразилися через кеш токенів, обмеження оцінки вкладених груп, або winbind не бачить оновлене членство.

Виправлення: Перевірте SID груп у токені за допомогою wbinfo --user-groups. Налаштуйте директорію/Samba для вкладених груп за потреби; попросіть користувачів перепідключитись/вийти та зайти знову, щоб оновити токен.

7) Симптом: «Windows каже Full Control, але все одно відмовляє»

Коренева причина: Обмеження на рівні шару шарингу (valid users, write list), або невірний шлях файлової системи (symlink-и, bind mount-и), або явний deny вище в дереві.

Виправлення: Перевірте конфіг шару з testparm. Підтвердіть точний шлях. Перегляньте ACL батьківських директорій і шукайте deny-записи.

8) Симптом: «Після міграції даних права виглядають вирівняними/спрощеними»

Коренева причина: Інструмент міграції не зберіг ACL (або транслював у POSIX-режими), або копіювали як root без збереження xattr/ACL.

Виправлення: Переміграція з методом, що зберігає ACL, відповідним для платформи, або відновлення зі знімка. Потім зафіксуйте стратегію, щоб це не повторилось.

Контрольні списки / поетапний план

Контрольний список 1: Створити новий SMB-шар на ZFS без майбутніх жалів

1. Створіть відокремлений датасет на кожен шар. Не кидайте все в один датасет і не надiйтесь на краще.
2. Встановіть властивості датасету явно: acltype=nfsv4, продуманий aclmode, продуманий aclinherit, і вибір чутливості до регістру, узгоджений з клієнтами Windows.
3. Виберіть стратегію idmap і стандартизуйте її на кожній SMB-ноді, що доступна до даних.
4. Налаштуйте Samba з VFS-модулями, що знають про ZFS ACL, і увімкніть поведінку наслідування ACL, якої ви дійсно хочете.
5. Визначте один кореневий ACL у Windows, перевірте наслідування створюючи тестові файли з різних клієнтських застосунків.
6. Зробіть snapshot перед передачею реальним користувачам. Вам потрібен шлях відкотитися перед тим, як почнуться «креативні дозволи».

Контрольний список 2: Реакція на інцидент з правами (30–60 хвилин)

1. Визначте точний шлях і одного враженого користувача. Не «багато людей» — один об’єкт, одна ідентичність.
2. Підтвердіть, що SID→UID відображення коректне на SMB-ноді, що обробляє сесію.
3. Перевірте обмеження шару шарингу в Samba і підтвердіть, що користувач підключається з очікуваним обліковим записом.
4. Огляньте серверний ACL на директорії і файлі; шукайте явні deny і відсутні прапорці наслідування.
5. Перевірте ефективний запис на сервері за допомогою sudo -u '#UID' test -w.
6. За потреби підвищіть рівень логування Samba короткочасно і зіставте подію NT_STATUS_ACCESS_DENIED з шляхом.
7. Виправте найменшу річ, що повертає коректність (часто відображення ідентичності або один поганий ACE), потім вимкніть нудне логування.

Контрольний список 3: Запобігання дрейфу прав (постійно)

1. Оголосіть одне джерело істини для змін ACL (інструменти Windows для SMB-перших датасетів).
2. Забороніть рекурсивний chmod на продакшн шарах; забезпечте це автоматичними запобіжниками і код-рев’ю.
3. Стандартизуйте backend/діапазони idmap по нодах; ставтесь до змін як до проєкту міграції, а не як до правки.
4. Режимно знімайте snapshot-и; зберігайте принаймні один знімок «відомо доброго ACL» для швидкого відкату/дифу.
5. Моніторьте непереведенi SID і невдалі трансляції SID→UID; сигналізуйте раніше.

Питання та відповіді

1) Чи слід використовувати acltype=nfsv4 для SMB-шарів?

Так, для SMB-шарів, орієнтованих на Windows. Це набагато краще відповідає семантиці Windows ACL, ніж POSIX ACL, і зменшує «сюрпризи» при трансляції.

2) Чому я бачу біти режиму (770), якщо ACL — справжній контроль?

Тому що UNIX все ще має поле режиму, і багато інструментів його відображають. Залежно від aclmode, chmod може або не може переписувати ACL, щоб відповідати режимам.
Розглядайте біт режиму як сумісницький метадані, якщо ви навмисно не обрали політику, орієнтовану на режими.

3) У чому різниця між aclmode=restricted та aclmode=discard?

restricted прагне зберегти намір ACL, коли використовується chmod. discard може видаляти ACL при зміні бітів режиму. Для SMB-датасетів
discard — це шлях до випадкового перетворення тонкої моделі прав у руїни.

4) Чому права змінюються залежно від того, на який SMB-сервер я потрапляю?

Майже завжди причина — невідповідність конфігурації idmap. Той самий SID відображається в різні UID на різних нодах, тож записи ACL на диску співпадають на одній ноді, але ні на іншій.

5) Чи можна безпечно запускати chown -R на SMB-датасеті?

«Безпечно» — це багато робить. Рекурсивні зміни власників можуть анулювати семантику ACL (особливо записи owner@ та group@) і здивувати Windows.
Якщо мусите — зробіть snapshot перед, тестуйте на клоне і розумійте модель ACL.

6) Чи потрібен мені vfs_zfsacl (або еквівалент) у Samba?

Якщо ви хочете коректної поведінки NFSv4/ZFS ACL, експонованої клієнтам Windows — так. Без нього Samba може відкотитися до загальної обробки ACL і ви побачите відсутні прапорці,
зламане наслідування або дивну поведінку у Windows UI.

7) Чому користувач може створити файл, але не може його видалити?

Видалення часто контролюється правами на батьківську директорію (і семантика видалення у Windows тонка). Переконайтесь, що користувач/група має права modify на директорію, а не лише запис у файли.

8) Чому я бачу в ACL «unknown SID»?

Сервер не може резолювати цей SID у ім’я, зазвичай через проблеми з підключенням до служби каталогів, видалені принципали, проблеми з довірою або кеш idmap.
Виправте резолювання ідентичностей перед тим, як переписувати ACL, інакше ви зафіксуєте неправильні ідентичності.

9) Чи завжди xattr=sa кращий для SMB?

Часто краще для навантажень SMB, що інтенсивно використовують метадані, бо це зменшує окремі I/O для xattr. Але це архітектурний вибір — перевірте на вашій платформі і будьте обережні,
змінюючи його на існуючих датасетах без плану.

10) Що найпростіше допоможе тримати права в порядку?

Один датасет на шар, acltype=nfsv4, консистентний idmap на всіх нодах, керування ACL з Windows і уникнення chmod зі сторони Linux. Нудне — перемагає.

Наступні кроки, які можна зробити цього тижня

Якщо ваші SMB-на-ZFS права виглядають як населений привидами будинок, не ганяйтеся за примарами. Виберіть чисту модель, потім забезпечте її конфігурацією та звичками.

1. Перевірте інвентар ваших SMB-датасетів: зафіксуйте acltype, aclmode, aclinherit, xattr та чутливість до регістру. Виправте очевидні часові бомби в першу чергу.
2. Стандартизуйте idmap на кожній SMB-ноді, що торкається однакових даних. Розглядайте зміни як міграцію. «Просто підправити» — шлях, яким ACL перетворюються на історичну художню літературу.
3. Визначте базовий ACL у корені кожного шару, перевірте наслідування з реальними клієнтами і зробіть snapshot бази.
4. Покладіть покроковий план швидкої діагностики там, де ваш on-call може знайти його о 2-й ранку. Майбутнє-ви буде втомленим і не зацікавленим в повторному вивченні відображення ідентичностей.

Кошмари з правами не спричиняє один поганий прапорець. Їх спричиняє незгурований світогляд. Зробіть його послідовним — і ваш файловий сервер знову стане нудним. Оце й є мета.