ZFS acltype: POSIX vs NFSv4 ACL без плутанини

December 16, 2025 • February 3, 2026 • Читання: 6 хв • Views: 10

Було корисно?

Якщо ви досить довго експлуатуєте ZFS у продакшені, ви бачили, як права доступу перетворюються на соціальний експеримент: один адміністратор «виправляє» доступ за допомогою chmod -R, користувач Windows змінює ACL у Провіднику, клієнт NFS щось «корисно» кешує, і раптом служба підтримки плавиться, а команда збереження наполягає, що «ZFS в порядку». Зазвичай ZFS справді в порядку. Наша ментальна модель — ось що ламається.

Ця стаття — відновлена ментальна модель для людей, що працюють у продакшені: що насправді означає acltype, чим POSIX ACL відрізняються від NFSv4 ACL в суттєвих речах, як поводяться SMB і NFS, що налаштувати на нових датасетах і як діагностувати неминуче «Permission denied» за хвилини, а не години.

Рішення, яке ви насправді приймаєте

В ZFS acltype — це не косметичний вибір. Це декларація того, якою мовою прав доступу датасет буде розмовляти нативно і які семантики ZFS буде зберігати, коли ви робите такі дії як chmod, chown та створюєте нові файли всередині директорій із спадкованими ACL.

Простими словами:

POSIX ACL розширюють класичні UNIX-біти режиму та користувачів/групи знайомою моделлю. Вони чудово підходять для Linux/Unix робочих процесів, автоматизації і для ситуацій «те, що ви бачите в ls -l, — це в основному історія». Але маска, дефолтні ACL і обмежені правила спадкування регулярно дивують людей.
NFSv4 ACL багатші, ближчі до семантики Windows ACL і мають явні прапорці спадкування. Вони краще відображаються в SMB, змішаних середовищах та для очікувань «справжнього корпоративного файлового сервера». Водночас вони дають більше способів нашкодити — більша виразність означає більше неправильних комбінацій.

Найкращий спосіб вибору — не «що мені подобається?», а «яке клієнтське середовище має бути джерелом істини?» Якщо SMB/Windows є вашим контрольним шаром, NFSv4 ACLs зменшують імпеданс. Якщо Linux-автоматизація і простота бітів режиму — ваш контрольний шар, POSIX ACLs зроблять ваш on-call спокійнішим.

Жарт один, бо ми це заслужили: POSIX ACL — як кишеньковий ніж: простий, корисний, і зрештою ви поріжетеся, якщо забудеєте про існування маски.

Факти та історія, що пояснюють сучасний безлад

Права доступу — це політична історія, закодована в ядрах. Кілька контекстних моментів допомагають пояснити, чому ZFS тут почувається «містично».

Класичні UNIX-права передували мережам. Біти власник/група/інші були розроблені для мультикористувацького таймшерингу, а не для крос-доменної ідентичності чи GUI-редакторів ACL.
POSIX ACL — прагматичне виправлення. Вони розширили модель бітів режиму, не замінюючи її, тому й існує маска: вона зберігає ідею, що біти режиму все ще мають значення.
NFSv4 ACL створювали з урахуванням мережевих файлових систем. Вони включають іменованих користувачів/групи, багатші allow/deny семантики і прапорці спадкування, що ведуть себе більш подібно до Windows.
Windows ACL вплинули на дизайн NFSv4 ACL. Не ідентичні, але достатньо схожі, щоб відображення було реальним — важливо для SMB-серверів поверх ZFS.
«Deny» ACE — не UNIX-традиція. В NFSv4 записи deny можуть коротко замикати allow-правила залежно від порядку й моделі оцінки; у POSIX ACL еквівалента немає.
SMB завжди піклувався про достовірність ACL. Клієнти Windows очікують спадкування, явні прапорці «нагороджено» проти «успадковано» і стабільну семантику при зміні дозволів через GUI.
ZFS спочатку орієнтувався на Solaris enterprise навантаження. Очікування було змішаними клієнтами, централізованим збереженням та потужними метаданими — включно з підтримкою ACL, що не була доповненням.
Інструменти Linux росли навколо POSIX ACL. getfacl/setfacl стали повсюдними, і люди очікують, що вони працюватимуть скрізь, навіть якщо файлову систему фактично «говорить» NFSv4 ACL.
Відображення ідентичності — окремий фронт бойових дій. ACL можуть бути ідеальними; якщо ваші UID/GID/SID відображені неправильно, права все одно не працюватимуть. Багато «помилок ACL в ZFS» насправді — проблеми служби каталогів.

Властивості ZFS, що контролюють реальність ACL

acltype — лише одна ручка. Комбінація властивостей ACL визначає, як ZFS зберігає ACL, як він обробляє chmod/chown і як застосовується спадкування.

acltype

Що це: Модель ACL, що використовується для датасету. Поширені значення залежать від платформи:

POSIX: часто позначається як posixacl в Linux-реалізаціях ZFS.
NFSv4: часто позначається як nfsv4.

Що змінює: Як інтерпретуються ACL і які інструменти/семантики поводяться нативно. Це також впливає на те, як SMB-сервери можуть представляти і зберігати ACL.

aclmode

Що це: Що робить ZFS, коли ви запускаєте chmod на файлі, який має ACL. Це номер один джерело «chmod не зробив того, що я думаю».

Типові поведінки (імена змінюються по платформах, але семантика лишається):

discard: викинути записи ACL, що не вписуються в новий режим. Небезпечно для середовищ з багатими ACL.
groupmask: зберігати ACL, але трактувати групові права консервативно на основі бітів режиму (поширений дефолт у деяких середовищах).
passthrough: дозволити chmod змінювати біти режиму без спроб «виправити» ACL. Часто найкраще, якщо ви явно керуєте ACL і не хочете, щоб chmod їх переписував.
restricted: забороняти chmod робити ACL більш відкритими, ніж вони були. Добре для безпеки; дивує в сценаріях «я root, чому я не можу?».

aclinherit

Що це: Як ACL на директоріях спадкуються новими файлами/директоріями, створеними всередині них.

Тут NFSv4 ACL вирізняються: вони мають явні прапорці спадкування, тож ви можете отримати передбачувану поведінку «ця папка поводиться як Windows-шаєр». POSIX може використовувати дефолтні ACL, але це менш виразно і легше застосувати неправильно.

xattr та sa

ACL зазвичай живуть у розширених атрибутах. ZFS може зберігати xattr у «системних атрибутах» (SA) для продуктивності (xattr=sa на багатьох системах). Це може дати справжній виграш у продуктивності для метаданозалежних навантажень — але це не робить права доступу простішими і може вплинути на думки про реплікацію та сумісність.

чутливість до регістру і нормалізація

Це не властивість ACL, але якщо ви змішуєте Windows і Unix клієнтів, casesensitivity і Unicode-нормалізація можуть викликати плутанину в шляху доступу, що виглядає як проблема прав доступу. Ви клянетеся, що користувач «має доступ», але він потрапляє на інший шлях, ніж той, який ви аудитували.

POSIX vs NFSv4 ACL: практичні відмінності

Ментальна модель: що означає «дозвіл»

POSIX ACL відповідають: «З урахуванням власника, групи, бітів режиму та опціональних додаткових записів користувачів/груп, чи дозволена ця операція?» Маска POSIX ACL фактично обмежує права іменованих користувачів/груп і групового класу. Якщо ви забудете про маску, ви неправильно проаудитите доступ.

NFSv4 ACL відповідають: «За списком впорядкованих записів контролю доступу (ACE) з allow/deny і багатими правами, плюс правила спадкування — чи дозволена ця операція?» Це більше схоже на набір правил брандмауера для файлів. Порядок важить більше. Існує «deny». Спадкування — це перший клас.

Спадкування: дефолтні ACL проти явних прапорців

POSIX використовує «дефолтні ACL» у директоріях. Коли створюється новий файл, ці дефолтні записи можуть стати access ACL записами в дочірньому елементі, з урахуванням umask і поведінки маски. Це працює, але не так виразно, як спадкування у стилі Windows.

NFSv4 має прапорці спадкування безпосередньо на ACE: застосовувати до файлів, до директорій, лише до дітей тощо. Саме тому налаштування Windows-на-ZFS зазвичай віддають перевагу NFSv4 ACL: ментальна модель збігається з тим, що робить Провідник.

Виразність: гранулярність прав

POSIX права грубі: читання/запис/виконання плюс деякі спеціальні біти. POSIX ACL здебільшого відображають це: вони розширюють «хто», а не «що».

NFSv4 дробить «що» на низку окремих прав: read data, write data, append, delete, read attributes, write attributes, read ACL, write ACL, take ownership та інші. Це потужно і небезпечно: ви можете створити файл, який хтось може записувати, але не видаляти, або може читати, але не перераховувати вміст директорії, залежно від призначених прав.

Інструменти: чим адміністратори фактично користуватимуться

POSIX перемагає в повсякденних CLI-інструментах. Більшість Linux-адмінів можуть мислити в термінах chmod, chown, getfacl, setfacl. Пастка в тому, що вони використовують ці інструменти на датасеті, де не повинні, і все працює напівправильно.

NFSv4 інструменти різняться. Деякі середовища використовують nfs4_getfacl/nfs4_setfacl. SMB-середовища часто керують ACL через Windows-інструменти. Це нормально — поки доброзичливий Linux-адмін не виконає chmod -R і не «очистить» ретельно створений порядок ACE.

Жарт №2 (і це все, що ви отримаєте)

NFSv4 ACL — як програмований термостат: неймовірно здатний, і якось офіс все одно мерзне, бо хтось відкрив «перекриття розкладу».

SMB, NFS і «в мене на клієнті працювало»

Більшість інцидентів з ACL відбуваються на межі протоколів. ZFS зберігає щось; SMB і NFS представляють щось; ваші адміністратори щось змінюють; і логіка відображення намагається зробити максимум.

SMB на ZFS: де зазвичай має сенс NFSv4 ACL

Якщо ваш датасет підкріплює SMB-шаєр і користувачі Windows керують правами, вам потрібні семантики ACL, які нагадують Windows. NFSv4 ACL зазвичай відображаються чистіше у спадкування й правах у стилі Windows. Вам все одно потрібне узгоджене відображення ідентичності (SID у Unix ID, залежно від стеку), але «форма» ACL відповідає очікуванням клієнта.

Що зазвичай ламається — не «ACL не працюють», а «ACL працюють інакше, ніж біти режиму». Адміни Windows очікують, що видалення «Запис» забере можливість створювати файли, змінювати атрибути, видаляти тощо. Якщо ваше відображення зводить кілька прав в один біт, ви отримаєте дивні краєвими випадки: можна писати, але не можна перейменувати; можна створювати, але не можна видаляти; можна проходити, але не можна перелічувати.

NFS на ZFS: оберіть семантику, яку розуміють ваші клієнти

Клієнти NFSv3 здебільшого живуть у всесвіті бітів режиму. Клієнти NFSv4 можуть працювати з NFSv4 ACL, але чи підтримує ваше клієнтське ПЗ і практики адміністрування це — інше питання. Якщо ви запускаєте NFS для Linux application server-ів, POSIX ACL часто є найменш дивовижним варіантом — за умови що ви налаштуєте aclmode і aclinherit відповідно до вашої операційної реальності.

Суміш SMB + NFS: вирішіть, хто авторитетний

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

Windows авторитетний: NFSv4 ACLs, редагування через SMB, клієнти NFS переважно споживають. Linux-адмінів навчають не «виправляти» chmod.
Unix авторитетний: POSIX ACLs, редагування через CLI і конфігураційний менеджмент; SMB (якщо є) розглядається як сумісний вигляд з обмеженими очікуваннями.

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

Три корпоративні міні-історії

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

Налаштування виглядало стандартно: датасет ZFS для SMB-шаєра фінансової команди, плюс NFS-маунти для батч-джобу, що генерував щовночні звіти. Хтось створив нову папку «Reports», скопіював структуру попереднього року — і все здавалося в порядку. Потім, одразу після закриття місяця, батч-джоб почав падати з «Permission denied» при записі файлів — лише в одній підпапці.

Дежурний адмін зробив те, що багато хто робить о 2-ій ночі: chmod -R g+rwX на дереві папок. Це «попрацювало» для Linux-джобу, але наступного ранку користувачі Windows повідомили, що вже не можуть змінювати дозволи, а деякі успадковані дозволи зникли. Тепер у інциденту був другий акт.

Хибне припущення полягало в тому, що біти режиму — це джерело істини. Датасет мав NFSv4 ACLs, налаштовані під Windows-спадкування. chmod не просто змінював режим — він викликав поведінку aclmode, яка фактично переписала частини ACL, щоб відповідати новому режиму. Linux-джоб було врятовано випадково; структура Windows ACL постраждала як побічний ефект.

Виправлення було нудним і точним: відновити ACL зі snapshot для ураженого піддерева, налаштувати окремий сервісний принципал для батч-джобу і надати явні права через модель NFSv4 ACL (або через SMB з узгодженим відображенням ідентичності). Довгострокове виправлення було культурним: «chmod — не редактор ACL» стало правилом у ранбуку для цього сховища.

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

Платформна команда хотіла швидших операцій з метаданими в пулі домашніх директорій: багато дрібних файлів, постійні перевірки ACL і скарги користувачів на повільні списки директорій. Хтось запропонував увімкнути SA-based xattrs (класичне «зберігайте xattr більш ефективно») і зробити ACL «більш сумісними», переключивши обробку ACL і дефолтні налаштування спадкування так, щоб вони відповідали стороні SMB.

Продуктивність покращилась — ненадовго. Справжній відкат стався через кілька тижнів під час тесту реплікації і відпрацювання відновлення. Частина відновлених датасетів показала трохи іншу поведінку ACL: деякі директорії почали спадкувати дозволи інакше, ніж раніше, і кілька сервісних акаунтів втратили можливість проходити шляхи, які вони щодня використовували. Ніхто не помітив цього у staging, бо тестові дані не включали дивні крайові випадки: глибокі дерева директорій зі змішаними явними і успадкованими ACE.

Корінь проблеми не в тому, що SA «поганий». Справа в тому, що команда змінила кілька ручок одночасно (зберігання xattr, поведінка спадкування ACL і робочі процеси адміністрування) і перевірила тільки «швидко» та «здається доступним». Іншими словами: вони оптимізували легку метрику і пропустили складну — семантичну еквівалентність.

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

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

Одна команда зберігання керувала мультиорендовою платформою ZFS для внутрішніх застосунків: NFS для Linux сервісів, SMB для кількох легасі-команд. У них було одне немодне правило: кожен датасет мав «мітку наміру», задокументовану у властивостях датасету і відображену в іменуванні — щось на кшталт apps-posix проти shares-nfsv4. У них також був CI-чек в інфраструктурі як коду, що відмовлявся створювати датасет без явних налаштувань acltype, aclmode і aclinherit.

Одної п’ятниці проект попросив «лише швидкий шейр» для вендорського дропбоксу. Добросердний інженер клонував існуючий датасет і експортував його через SMB. Вендори могли завантажувати, але внутрішні користувачі не могли прочитати файли після цього. Запахнуло відображенням ідентичності, але команда не пішла на полювання за привидами.

Вони спочатку перевірили мітку наміру датасету. Це був POSIX-орієнтований датасет, клонований з експорту застосунку. SMB-шаєр був архітектурною помилкою, а не проблемою з правами. Вони створили новий NFSv4-орієнтований датасет для дропбоксу, перемістили дані і припинили намагатися змусити один датасет задовольнити конфліктні семантики.

Жодних героїчних дій, жодних вихідних на розкопки ACL. «Нудна» практика — явний намір і примусове задання властивостей — перетворила потенційний збій на невелику оборотну зміну.

Практичні завдання (команди + інтерпретація)

Команди нижче припускають Linux-систему з встановленими утилітами ZFS. Деякі середовища трохи відрізняються в назвах властивостей і доступних інструментах, але операційна логіка загалом однакова. Кожне завдання включає, що ви шукаєте і як це інтерпретувати.

Завдання 1: Визначити модель ACL датасету і пов’язані властивості

cr0x@server:~$ sudo zfs get -r acltype,aclmode,aclinherit,xattr pool/share
NAME        PROPERTY    VALUE        SOURCE
pool/share  acltype     nfsv4        local
pool/share  aclmode     restricted   local
pool/share  aclinherit  passthrough  local
pool/share  xattr       sa           local

Інтерпретація: Цей датасет нативно використовує NFSv4 ACL. aclmode=restricted означає, що chmod буде обмеженим; aclinherit=passthrough свідчить, що поведінка спадкування налаштована на збереження наміру ACE. xattr=sa означає, що xattr (часто включаючи ACL) зберігаються ефективно в SA, що може допомогти при навантаженнях з великою кількістю метаданих.

Завдання 2: Підтвердити, чи файли мають ACL понад біти режиму

cr0x@server:~$ ls -l /pool/share/project
total 4
drwxrwx---+  5 root finance 5 Dec 24 09:10 Reports
-rw-r-----+  1 root finance 0 Dec 24 09:10 readme.txt

Інтерпретація: + вказує, що існує ACL. Самі біти режиму не розкажуть усю історію.

Завдання 3: Прочитати POSIX ACL за допомогою getfacl (POSIX датасети)

cr0x@server:~$ getfacl -p /pool/posixdata/team
# file: /pool/posixdata/team
# owner: root
# group: team
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:other::---

Інтерпретація: Існують дефолтні ACL, тож нові діти успадковують ці записи як відправну точку. Якщо є запис mask::, пам’ятайте, що він обмежує ефективні дозволи для іменованих користувачів/груп і групового класу.

Завдання 4: Показати ефект маски (класичний сюрприз POSIX ACL)

cr0x@server:~$ setfacl -m u:alice:rwx /pool/posixdata/team
cr0x@server:~$ getfacl -p /pool/posixdata/team | sed -n '1,12p'
# file: /pool/posixdata/team
# owner: root
# group: team
user::rwx
user:alice:rwx
group::r-x
mask::r-x
other::---

Інтерпретація: Alice має rwx у записі ACL, але ефективні права обмежені mask::r-x. Якщо Alice не може записувати, маска — перший підозрюваний.

Завдання 5: Виправити маску свідомо (не випадково)

cr0x@server:~$ setfacl -m m::rwx /pool/posixdata/team
cr0x@server:~$ getfacl -p /pool/posixdata/team | grep -E 'user:alice|mask::'
user:alice:rwx
mask::rwx

Інтерпретація: Ви розширили стелю ефективних дозволів. Робіть це свідомо; маски існують, щоб зберегти обмеження у стилі бітів режиму.

Завдання 6: Переглянути NFSv4 ACL (NFSv4 датасети)

cr0x@server:~$ nfs4_getfacl /pool/share/project/Reports
A::OWNER@:rwatTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:tncy

Інтерпретація: Ви дивитесь на ACE. Літери представляють права; точні набори варіюються. Зверніть увагу, чи права призначені OWNER@, GROUP@ або іменованим принципалам, і чи є deny-записи (вони зазвичай позначаються з D у багатьох виводах).

Завдання 7: Перевірити, чи спадкування ACL налаштовано на рівні датасету

cr0x@server:~$ sudo zfs get aclinherit pool/share
NAME       PROPERTY    VALUE        SOURCE
pool/share aclinherit  passthrough  local

Інтерпретація: passthrough загалом означає, що ZFS намагатиметься не «спростити» успадковані ACE. Якщо ви бачите, що спадкування видаляється або змінюється, ця властивість — частина пояснення.

Завдання 8: Подивитися, що робить chmod на файлі з ACL (і чому це дивує)

cr0x@server:~$ sudo zfs get aclmode pool/share
NAME       PROPERTY  VALUE       SOURCE
pool/share aclmode   restricted  local

cr0x@server:~$ chmod 777 /pool/share/project/readme.txt
chmod: changing permissions of '/pool/share/project/readme.txt': Operation not permitted

Інтерпретація: З aclmode=restricted chmod може бути заборонено робити файл більш відкритим, ніж його ACL дозволяє. Це функція безпеки, але також підказка для діагностики: якщо chmod не вдається або «ніяк не впливає», перевірте aclmode і сам ACL.

Завдання 9: Підтвердити, кого ZFS вважає власником файлу і групою (перевірка ідентичності)

cr0x@server:~$ stat -c '%n owner=%U(%u) group=%G(%g) mode=%a' /pool/share/project/Reports
/pool/share/project/Reports owner=root(0) group=finance(10025) mode=770

Інтерпретація: Якщо ви бачите числові ID там, де очікували імена (або неправильні імена), ймовірно у вас проблема з відображенням ідентичності, а не з ACL. Виправте ідентичність перш ніж застосовувати ACL, інакше ви застосуєте права для не тих принципалів.

Завдання 10: Прослідкувати відмову доступу з перспективи клієнта

cr0x@server:~$ sudo -u alice bash -lc 'cd /pool/share/project/Reports && touch testfile'
touch: cannot touch 'testfile': Permission denied

Інтерпретація: Відтворення від імені користувача знімає здогадки. Якщо Alice не може створити файл, ви налагоджуєте права на запис/створення директорії (не права на файл). З NFSv4 ACL вам можуть знадобитися специфічні права типу «add file»; з POSIX потрібні write+execute на директорію.

Завдання 11: Зробіть snapshot перед операціями над ACL (дешевий страховий поліс)

cr0x@server:~$ sudo zfs snapshot pool/share@before-acl-fix
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation | grep 'pool/share@before-acl-fix'
pool/share@before-acl-fix  Wed Dec 24 09:35 2025

Інтерпретація: Робота з ACL оборотна, якщо ви зробили snapshot перед цим. Це різниця між «ми швидко виправимо» і «ми тут цілу ніч».

Завдання 12: Порівняти ACL між двома директоріями, щоб помітити дрейф

cr0x@server:~$ getfacl -p /pool/posixdata/team > /tmp/team.acl
cr0x@server:~$ getfacl -p /pool/posixdata/team-archive > /tmp/team-archive.acl
cr0x@server:~$ diff -u /tmp/team.acl /tmp/team-archive.acl | sed -n '1,80p'
--- /tmp/team.acl
+++ /tmp/team-archive.acl
@@
 group::r-x
-mask::rwx
+mask::r-x

Інтерпретація: Одна різниця в масці може пояснити, чому «в одній папці працює, а в іншій ні». Це швидкий спосіб впіймати тонкі зміни після «швидких фіксів».

Завдання 13: Аудитувати mountpoint датасету і переконатися, що ви редагуєте правильний шлях

cr0x@server:~$ sudo zfs get mountpoint pool/share
NAME       PROPERTY    VALUE         SOURCE
pool/share mountpoint  /pool/share   local

cr0x@server:~$ mount | grep '/pool/share'
pool/share on /pool/share type zfs (rw,xattr,noacl)

Інтерпретація: Підтвердьте, що датасет, який ви думаєте змінюєте, дійсно змонтований там, де ви думаєте. Редагування прив’язаної точки bind або іншого датасету — класичне самопідставляння. (Примітка: опції mount можуть відрізнятися по платформах.)

Завдання 14: Перевірити, чи спадкування в директорії робить те, що ви очікуєте

cr0x@server:~$ mkdir -p /pool/posixdata/team/newdir
cr0x@server:~$ touch /pool/posixdata/team/newdir/newfile
cr0x@server:~$ getfacl -p /pool/posixdata/team/newdir | sed -n '1,25p'
# file: /pool/posixdata/team/newdir
# owner: root
# group: team
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:other::---

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

Плейбук швидкої діагностики

Ось потік триажу, який я використовую, коли в чергу SRE/збереження потрапляє «права зламались». Мета — швидко знайти реальне вузьке місце: невідповідність семантик, невідповідність ідентичності або невідповідність властивостей/інструментів.

Перше: підтвердьте, у якій моделі прав ви знаходитеся

Перевірте властивості датасету: acltype, aclmode, aclinherit, xattr.
Підтвердьте, що об’єкт має ACL (+ у ls -l), і отримайте ACL за допомогою правильного інструменту (getfacl для POSIX; nfs4_getfacl для NFSv4, якщо доступно).

Якщо ви пропустите це і одразу перейдете до chmod/chown, ви будете робити діагностику всліпу.

Друге: відтворіть від імені користувача і визначте операцію

Відтворіть через sudo -u user локально (або еквівалент) щоб підтвердити, що це не кеш клієнта чи баг застосунку.
Визначте операцію, яка не вдається: обхід директорії, список, створення, перейменування, видалення, читання, запис, зміна атрибутів.

Різні операції мапляться на різні права. «Може записати файл, але не може перейменувати» — це проблема з правами директорії, а не файла.

Третє: валідуйте відображення ідентичності перед переписуванням ACL

Перевірте власність через stat і підтвердьте очікуване розв’язання UID/GID.
У змішаних середовищах переконайтесь, що користувач представлений послідовно через SMB/NFS/Linux. Якщо «alice» має UID 1001 на Linux, але відображається інакше через служби каталогів, ваші зміни ACL можуть спрямовуватися не тому принципалу.

Четверте: перевірте, чи властивості на рівні датасету не переписують ваш намір

Якщо chmod здається «не вдається» або «не зберігається», перевірте aclmode.
Якщо нові файли не успадковують очікувані права, перевірте aclinherit і чи батьківська директорія має дефолтні ACL (POSIX) або успадковані ACE (NFSv4).

П’яте: лише потім змінюйте права — мінімально і відкатно

Спочатку зробіть snapshot.
Змініть найменший обсяг, який виправляє проблему.
Перевірте з кожного релевантного типу клієнта, якщо у вас змішане середовище.

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

Помилка 1: Вважати chmod редактором ACL на NFSv4 датасетах

Симптоми: Спадкування Windows ламається; ACL «спрощуються»; права зсуваються після chmod з боку Linux; chmod видає помилку «Operation not permitted».

Виправлення: Перестаньте використовувати chmod для змін політик на NFSv4 датасетах. Використовуйте інструменти NFSv4 ACL або керування ACL через SMB/Windows послідовно. Перегляньте aclmode; розгляньте поведінку passthrough, якщо ваше середовище вимагає, щоб chmod не переписував ACL, але лише якщо ви розумієте наслідки для безпеки.

Помилка 2: Забути, що маска POSIX ACL існує

Симптоми: getfacl показує user:alice:rwx, але Alice не може записувати; «виглядає як rwx, але працює як r-x».

Виправлення: Перевірте mask::. Налаштуйте її свідомо за допомогою setfacl -m m::rwx (або найменш привілейованої маски, що відповідає вимогам). Навчіть операторів: маска обмежує ефективні права.

Помилка 3: Припускати, що «груповий запис» означає «може видаляти файли»

Симптоми: Користувач може створювати файли, але не може видаляти/перейменовувати, або навпаки, залежно від прав директорії та поведінки sticky bit; в NFSv4 права не завжди мапляться прямо в «write».

Виправлення: Налагоджуйте права директорії окремо від прав на файли. На POSIX: директорія потребує write+execute для створення/видалення/перейменування; sticky bit змінює семантику видалення. В NFSv4: переконайтесь, що ACE директорії включають права, потрібні для операцій delete/rename/add-file.

Помилка 4: Змішувати редагування ACL через SMB і setfacl на одному і тому ж датасеті

Симптоми: Права коливаються; прапорці успадкування зникають; Windows показує «дивні» записи; Linux показує ACL, що не відповідають Windows-інтенціям.

Виправлення: Визначте авторитетний шлях редагування. Якщо SMB авторитетний — керуйте ACL через SMB/Windows інструменти і тримайте зміни з боку Linux мінімальними та процедурними. Якщо Linux авторитетний — обмежте очікування SMB і задокументуйте їх.

Помилка 5: Застосовувати рекурсивні зміни прав без snapshot

Симптоми: Широкі відключення; ви «поправили» один сервіс і зламали десять інших; відкат робиться вручну і довго.

Виправлення: Завжди робіть snapshot перед рекурсією. Якщо мусите робити рекурсивні зміни, спочатку тестуйте на невеликому піддереві, валідуйте клієнтів, потім застосовуйте.

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

Симптоми: ACL виглядають правильними, але доступ заборонений; імена розв’язуються непослідовно; файли показують числових власників; SMB-користувачі видаються як несподівані ID на сервері.

Виправлення: Перевірте відображення UID/GID/SID. Забезпечте послідовну конфігурацію служби каталогів. Правильність ACL марна, якщо принципали не мапляться на очікувані ідентичності.

Помилка 7: Плутати «traverse» з «list» у директоріях

Симптоми: Користувач може отримати доступ до відомого файлу, але не може перелічити директорію; або навпаки, може перерахувати, але не може зайти.

Виправлення: На POSIX: execute на директорії — це traverse; read — це list. В NFSv4: переконайтеся, що ACE включають відповідні права для переліку та проходження.

Чеклісти / покрокові плани

Чекліст: вибір acltype для нового датасету

Визначте головний клієнтський протокол: SMB-перший чи NFS/Linux-перший.
Вирішіть авторитетного редактора ACL: інструменти Windows чи CLI/IaC Linux.
Оберіть acltype: NFSv4 для SMB-перших; POSIX для Linux-перших.
Явно задайте aclmode: якщо ви хочете, щоб chmod був обмежений, використайте поведінку на кшталт restricted; якщо хочете, щоб chmod не переписував ACL, оберіть passthrough-подібну поведінку (з обережністю).
Явно задайте aclinherit: виберіть режим, що зберігає семантику спадкування, які ви дійсно хочете.
Визначте зберігання xattr: розгляньте xattr=sa для навантажень з великою кількістю метаданих; перевірте сумісність у вашому середовищі.
Задокументуйте намір: включіть його в іменування датасету або властивості, щоб оператори знали, які правила застосовуються.

Покроково: створити POSIX-ACL орієнтований датасет для Linux-застосунків

cr0x@server:~$ sudo zfs create -o acltype=posixacl -o xattr=sa pool/apps
cr0x@server:~$ sudo zfs set aclmode=groupmask pool/apps
cr0x@server:~$ sudo zfs set aclinherit=passthrough pool/apps
cr0x@server:~$ sudo zfs get acltype,aclmode,aclinherit,xattr pool/apps
NAME      PROPERTY    VALUE        SOURCE
pool/apps acltype     posixacl     local
pool/apps aclmode     groupmask    local
pool/apps aclinherit  passthrough  local
pool/apps xattr       sa           local

Інтерпретація: Це розумна базова конфігурація для Linux-середовищ, що використовують POSIX ACL. Ви можете обрати інші aclmode/aclinherit залежно від політики, але головна ідея — встановити їх явно, а не спадкувати за замовчуванням.

Покроково: створити NFSv4-ACL орієнтований датасет для SMB-шаїв

cr0x@server:~$ sudo zfs create -o acltype=nfsv4 -o xattr=sa pool/shares
cr0x@server:~$ sudo zfs set aclmode=restricted pool/shares
cr0x@server:~$ sudo zfs set aclinherit=passthrough pool/shares
cr0x@server:~$ sudo zfs get acltype,aclmode,aclinherit,xattr pool/shares
NAME        PROPERTY    VALUE        SOURCE
pool/shares acltype     nfsv4        local
pool/shares aclmode     restricted   local
pool/shares aclinherit  passthrough  local
pool/shares xattr       sa           local

Інтерпретація: Це узгоджується з моделлю «SMB/Windows авторитетний». Це знижує ризик того, що chmod на хості випадково розширить доступ. Це не замінює потребу у послідовному відображенні ідентичності.

Покроково: реакція на інцидент з правами (безпечна процедура)

Зробіть snapshot ураженого датасету або принаймні найменшу границю датасету, що містить уражений шлях.
Збережіть поточні ACL з кількох репрезентативних шляхів у текстові файли.
Відтворіть помилку від імені користувача і визначте невдалу операцію.
Спочатку виправте проблеми з відображенням ідентичності, якщо вони є.
Застосуйте мінімальні зміни ACL, використовуючи правильну модель/інструмент.
Перевірте з кожного релевантного типу клієнта (SMB і/або NFS) і з локального шелу.
Документуйте, що змінили і чому; дрейф ACL без документації — це повторюваний інцидент.

FAQ

1) Що саме змінює `acltype` в ZFS?

Воно обирає семантику ACL, яку ZFS буде використовувати для цього датасету: POSIX ACL поведінку (маска, дефолтні ACL) проти NFSv4 ACL поведінки (списки ACE з прапорцями спадкування і багатими правами). Воно впливає на те, як ACL зберігаються і як операції, що змінюють дозволи, взаємодіють із наявними ACL.

2) Якщо я використовую NFSv4 ACL, чи можу я все ще користуватися `chmod` та `chown`?

Можете, але потрібно розуміти aclmode. У багатьох налаштуваннях chmod буде обмежений або заборонений робити зміни, що конфліктують з політикою ACL. Якщо в організації очікують, що «chmod все виправляє», датасети NFSv4 будуть породжувати тікети, якщо ви не перенавчите робочі процеси.

3) Чому `ls -l` показує права, що не відповідають реальності?

Тому що біти режиму — лише частина історії, коли існують ACL. У POSIX ACL маска може обмежувати ефективні права. У NFSv4 ACL біти режиму часто є підсумковим видом і не повністю представляють права на видалення, перейменування або write-ACL.

4) Чи слід використовувати POSIX ACL для NFS-шаєрів?

Часто так для середовищ з великою кількістю NFSv3 і Linux-клієнтів, бо операційна модель збігається. Для NFSv4 клієнтів, що дійсно використовують NFSv4 ACL енд-ту-енд, NFSv4 ACL можуть бути хорошим вибором — але лише якщо ваше клієнтське ПЗ і практики адміністрування відповідають цьому світу.

5) Чи слід використовувати NFSv4 ACL для SMB-шаєрів?

У більшості змішаних Windows-середовищ — так. NFSv4 ACL зазвичай краще зберігають Windows-подібні семантики спадкування і уникнуть втрат при відображенні. Зауваження — відображення ідентичності: якщо ваші користувачі/групи не мапляться послідовно, навіть найкраща модель ACL не врятує вас.

6) Чи можна переключити `acltype` на існуючому датасеті безпечно?

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

7) Чому деякі користувачі мають «write», але не можуть видаляти файли?

На POSIX видалення контролюється правами директорії (і правилами sticky bit), а не бітами запису файла. В NFSv4 права на delete/rename можуть бути окремими від прав на запис даних. Діагностуйте ACL/права директорії, а не лише файлу.

8) Який найшвидший спосіб відлагодити «Permission denied»?

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

9) Чи змінює `xattr=sa` поведінку ACL?

Воно переважно змінює місце зберігання xattr для продуктивності, а не семантику. Але зміни продуктивності можуть виявити приховані проблеми (наприклад, застосунки роблять більше операцій над метаданими, ніж ви думали), і операційно слід перевірити сумісність реплікації/відновлення і інструментів у вашому середовищі.

10) Якщо я повинен підтримувати і SMB, і NFS, яка найменш болюча стратегія?

Оберіть одну авторитетну модель прав доступу на датасет і застосовуйте її. Використовуйте окремі датасети для SMB-перших і NFS-перших робочих навантажень. Змішані авторитети редагування ACL в одному і тому ж датасеті — джерело довготривалого дивного поводження з правами.

Висновок

acltype — це менше про внутрішні механізми ZFS і більше про операційну істину: хто має право визначати політику доступу і які клієнтські семантики ви зобов’язуєтесь зберегти. POSIX ACL — природне продовження Unix-бітів режиму і зазвичай найменш болісний шлях для Linux-перших середовищ — за умови поваги до маски і правил дефолтних ACL. NFSv4 ACL — правильний інструмент, коли семантика Windows/SMB і спадкування має залишитися недоторканою — за умови, що ви припините вважати chmod універсальним розчином.

Справжня перемога — це послідовність. Визначте ідентичність датасету і владу над дозволами заздалегідь, задайте властивості явно, робіть snapshot перед рекурсивними змінами і діагностуйте відображення ідентичності перед переписуванням ACL. Робіть так, і права ZFS перестануть бути будинком із привидами і стануть системою, про яку ви зможете мислити — на виклику, під тиском, з дорослими очікуваннями доступності.