ZFS sharenfs/sharesmb: зручність проти контролю в продуктивному середовищі

Що насправді роблять sharenfs/sharesmb (і чого не роблять)

sharenfs одним реченням

sharenfs — це властивість датасету ZFS, яка може наказати хосту експортувати датасет через NFS із використанням підсистеми
шейрингу платформи, зазвичай шляхом динамічної генерації правил експорту та виклику механізму шейрингу ОС (не якоюсь магією).

sharesmb одним реченням

sharesmb — це властивість датасету ZFS, яка може наказати хосту опублікувати датасет як SMB-шару через інтеграцію з SMB-сервісом
платформи (історично на illumos/Solaris; на Linux це залежить від ваших інструментів і дистрибутива).

Чому це важливо: ви обираєте рівень оркестрації

Сам ZFS не «говорить» NFS чи SMB. Він делегує. Ці властивості датасету фактично є невеликим оркестратором шейрингу, прикріпленим до метаданих
файлової системи. Це й привабливо, й ризиково: визначення шари подорожує з датасетом, може наслідуватись, клонуватись і реплікуватись — і потім
здивувати вас, бо воно досі там.

Неприємна правда: поведінка різниться за ОС та «віттям ZFS»

На системах похідних від illumos (і в старій лінії Solaris) властивості шейрингу — це повноцінні об’єкти: zfs share,
zfs unshare, інтеграція зі sharetab, SMB-шаринг через менеджер сервісів ОС — усе як належить. На Linux з OpenZFS властивості
існують, але активація шейрингу може реалізовуватися через хелпери, systemd-юніти або пакувальні налаштування. Деякі середовища трактують
sharenfs як «метадані, які можна опитати», і нічого більше, поки ви не встановите й не ввімкнете потрібні сервіси.

Питання контролю: ви хочете, щоб шари «декларувалися» на рівні ZFS (властивості датасету) чи «декларувалися» на рівні сервісу
(/etc/exports, конфіг Samba або система управління конфігурацією)? Якщо не можете відповісти чітко — ви це дізнаєтеся о 3-й ранку.

Чого ці властивості не роблять

• Вони не забезпечують мережевого рівня безпеки. Вони лише впливають на конфігурацію шейру/експорту.
• Вони не замінюють правильний дизайн ідентичностей і дозволів (відповідність UID/GID, ACL, SMB-ідентичності).
• Вони не гарантують однакову поведінку по всьому флоту, якщо інструменти ОС відрізняються.
• Вони не завадять комусь редагувати /etc/exports або конфіг Samba і відхилятися від наміру ZFS.

Властивість шейру — як написати на посилці «доставити до парадного»: допомагає. Це не дверний замок.

Зручність проти контролю: дослідження компромісу для продакшену

Коли властивості шейрингу — перевага

Використовуйте sharenfs/sharesmb, коли датасет має бути самоописним, особливо якщо ви:

• Часто створюєте й видаляєте датасети (CI-кеші, робочі простори проєктів, епhemeral аналітичні песочниці).
• Клонують датасети і хочете, щоб намір шейру йшов за клоновим (іноді це потрібно, часто — ні — запам’ятайте це).
• Використовуєте реплікацію ZFS і хочете, щоб прийомна сторона знала «цей датасет призначений для експорту», навіть якщо ви не автоекспортуєте його.
• Потребуєте погодженого, опитуваного стану: «Які датасети шаряться?» — одне zfs get і відповідь готова.

Коли властивості шейрингу стають тягарем

Уникайте покладатися на них як на ваш основний контрольний шар, коли ви:

• Потребуєте явного контролю змін для експорту/шейру (аудит, схвалення безпеки, розмежування обов’язків).
• Керуєте кількома стеками NFS/SMB або кількома джерелами конфігурації (ручні /etc/exports плюс автошейринг ZFS плюс система оркестрації).
• Реплікуєте датасети між середовищами (prod ↔ staging), де правила шейру не повинні слідувати за даними.
• Маєте змішану поведінку ОС по флоту (деякі вузли шанують властивості; інші ігнорують).

Справжній компроміс: локальність стану проти управління

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

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

Жарт №1: «Автошейринг — як автопродовження підписок: зручно, поки не помітиш, що це поновили в іншій країні.»

Прихований гострий край: наслідування

Властивості ZFS наслідуються вниз по дереву датасетів. Це зазвичай корисно. Для шейрингу це також пастка.
Встановіть sharenfs=on на батьківському датасеті — і ви можете випадково експортувати внутрішні адміністративні датасети, снапшоти,
змонтовані десь ще, або нові дочірні датасети, створені пізніше автоматизацією. Людям подобається наслідування, допоки воно не наслідує в невірному
напрямку.

Ще один гострий край: реплікація і «дрейф шейру»

Коли ви реплікуєте датасети, ви можете реплікувати й властивості. Залежно від прапорів і інструментів, приймач може отримати значення
sharenfs/sharesmb, які мали сенс на джерелі, але небезпечні на приймачі.
Режим відмови — не завжди «він відразу експортує». Іноді гірше: ця конфігурація лежить латентно, поки оновлення пакета або перезавантаження служби
раптом не почнуть її виконувати. Вітаємо, ви щойно відправили часову бомбу через реплікацію.

Контроль не означає ручне редагування всього

Альтернатива властивостям шейру — не «редагувати /etc/exports вручну й молитися». Контроль можна досягти за допомогою:

• Управління конфігурацією, яке генерує експорти і SMB-шари з інвентарю та політики.
• Обгортки, що читає властивості ZFS і генерує конфіг сервісів, але застосовує allowlist і проходить рев’ю.
• Розділення неймспейсу: один батьківський датасет, де шейринг дозволений, а всі інші за замовчуванням «вимкнені».

Ви хочете систему, де стан за замовчуванням — нудний і безпечний, а винятки — навмисні.

Перефразована ідея від Werner Vogels: «Ти побудував — ти експлуатуєш». В термінах зберігання: якщо ви встановили властивість,
ви несете відповідальність за радіус ураження.

Факти та історичний контекст, які дійсно важливі

1. Шейринг ZFS виник у світі Solaris/illumos. Тісна інтеграція із сервісами шейрингу системи не була випадковістю; це був очікуваний операторський досвід.
2. Конфігурація експорту NFS існувала задовго до ZFS. Конвенції /etc/exports створювалися для статичних файлових систем, а не для перемикачів по датасетах з наслідуванням.
3. SMB на Solaris пішов іншим шляхом, ніж Samba. illumos/Solaris історично мали вбудований у ядро SMB-сервер і сервісні інструменти; Linux зазвичай покладається на userland Samba.
4. Властивості ZFS спроектовані для наслідування, клонування й реплікації. Саме тому шейринг через властивості відчувається природним — і саме чому він може реплікувати сюрпризи разом з даними.
5. Існувала відстежувальна концепція «sharetab», щоб швидко відповісти «що експортується?». Оператори хотіли єдине джерело правди для живих шар ще до появи сучасного сервісного виявлення.
6. NFSv4 змінив ментальну модель. Псевдокорені та єдина точка експорту можуть приховувати або розкривати межі датасетів так, що це збиває з пантелику команди, які звикли до NFSv3.
7. Семантика ACL різниться між NFS і SMB. Навіть коли обидва протоколу працюють з тим самим датасетом, переклад моделі дозволів несиметричний і створює головоломки на кшталт «працює для SMB, ламається для NFS».
8. Idmapping завжди був тихим вбивцею. Шейр може бути ідеальним; проблеми з відповідністю UID/GID або SID зроблять його виглядати «непрацюючим».
9. Linux OpenZFS зберіг властивості заради сумісності. Але «властивість існує» ≠ «дистрибуція за замовчуванням вмикає автошейринг».

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

Задача 1: Перелік датасетів, які заявляють, що шаряться

cr0x@server:~$ zfs get -r -o name,property,value,source sharenfs,sharesmb tank
NAME                 PROPERTY  VALUE  SOURCE
tank                 sharenfs  off    default
tank                 sharesmb  off    default
tank/projects        sharenfs  on     local
tank/projects        sharesmb  off    inherited from tank
tank/projects/acme   sharenfs  on     inherited from tank/projects
tank/projects/acme   sharesmb  off    inherited from tank
tank/backups         sharenfs  off    local
tank/backups         sharesmb  off    default

Що це означає: Ви бачите і значення, і SOURCE. Наслідування шейру — перша річ, якої треба боятися.
Рішення: Якщо датасет шариться через наслідування ненавмисно, встановіть його явно:
zfs set sharenfs=off tank/projects/acme або виправте батьківський датасет.

Задача 2: Перевірити, що ОС вважає нині експортованим через NFS

cr0x@server:~$ exportfs -v
/tank/projects  10.20.0.0/16(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash)
/tank/backups   10.30.5.42(sync,wdelay,hide,no_subtree_check,sec=sys,ro,root_squash)

Що це означає: Це живий стіл експорту NFS (Linux NFS server). Він може не збігатися з властивостями ZFS.
Рішення: Якщо zfs get sharenfs показує «on», але exportfs не показує — ваш шлях автошейрингу неактивний. Якщо exportfs показує експорти, яких ви не хотіли — у вас дрейф конфігурації або надто «корисний» генератор.

Задача 3: Підтвердити, що сервіс шейрингу запущений (NFS)

cr0x@server:~$ systemctl status nfs-server --no-pager
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:12 UTC; 3h 1min ago
       Docs: man:rpc.nfsd(8)

Що це означає: NFS запущено на рівні сервісів. Якщо клієнти все ще не можуть монтувати, переходьте до експортів, фаєрволу та idmapping.
Рішення: Якщо сервіс неактивний — не дебагуйте властивості ZFS; запустіть сервіс і перевірте порти.

Задача 4: Перевірити, чи увімкнено інструментарій автошейрингу ZFS (приклад для Linux)

cr0x@server:~$ systemctl status zfs-share --no-pager
● zfs-share.service - ZFS dataset share service
     Loaded: loaded (/lib/systemd/system/zfs-share.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:10 UTC; 3h 1min ago

Що це означає: На багатьох Linux-настройках ця юніта намагається виконувати sharenfs/sharesmb.
Рішення: Якщо вона вимкнена або відсутня — ваші властивості, ймовірно, «паперові». Вирішіть, увімкнути її або перейти повністю до явних конфігів сервісів.

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

cr0x@server:~$ sudo zfs share -a
cannot share 'tank/backups': property 'sharenfs' is off
tank/projects shared

Що це означає: Команда share застосовує поточний стан властивостей. Деякі платформи роблять це автоматично при set; деякі
вимагають явного zfs share або перезапуску сервісу.
Рішення: Якщо шейринг не застосовується при зміні властивості, включіть «re-share» у ваші рукописи та автоматизацію.

Задача 6: Переглянути точний рядок опцій sharenfs (не лише on/off)

cr0x@server:~$ zfs get -o name,property,value sharenfs tank/projects
NAME           PROPERTY  VALUE
tank/projects  sharenfs  rw=@10.20.0.0/16,root_squash,sec=sys

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

Задача 7: Перевірити, що mountpoint датасету відповідає тому, що ви експортуєте

cr0x@server:~$ zfs get -o name,property,value mountpoint tank/projects tank/projects/acme
NAME                PROPERTY    VALUE
tank/projects       mountpoint  /tank/projects
tank/projects/acme  mountpoint  /tank/projects/acme

Що це означає: Експорти зазвичай використовують шляхи. Якщо mountpoint змінено, перейменовано або змонтовано за старою схемою,
ви можете експортувати неправильний шлях.
Рішення: Якщо mountpoint не відповідає схемі іменування експорту — виправте mountpoint або експортуйте явно за дизайном.

Задача 8: Підтвердити, що датасет дійсно змонтований там, де очікуєте

cr0x@server:~$ mount | grep -E '^tank/projects'
tank/projects on /tank/projects type zfs (rw,xattr,posixacl)
tank/projects/acme on /tank/projects/acme type zfs (rw,xattr,posixacl)

Що це означає: Якщо він не змонтований, NFS-експорт може існувати, але вказувати на порожню директорію (або падати).
Рішення: Якщо не змонтований — перевірте canmount, mountpoint і порядок запуску ZFS-монтування.

Задача 9: Перевірити властивості ZFS, які часто плутають із шейрингом

cr0x@server:~$ zfs get -o name,property,value -s local,inherited canmount,readonly,acltype,xattr tank/projects
NAME           PROPERTY  VALUE
tank/projects  canmount  on
tank/projects  readonly  off
tank/projects  acltype   posixacl
tank/projects  xattr     sa

Що це означає: Якщо readonly=on, записи провалюються і люди звинувачують NFS. Якщо налаштування ACL/xattr відрізняються,
поведінка SMB/NFS розходиться.
Рішення: Вирівняйте очікування щодо ACL/xattr під конкретні протоколи. Не «виправляйте» проблеми шейру випадковою зміною ACLtype.

Задача 10: З клієнта підтвердити, що сервер пропонує (NFS)

cr0x@server:~$ showmount -e nfs01
Export list for nfs01:
/tank/projects 10.20.0.0/16

Що це означає: Клієнт може опитати список експорту (переважно інструменти ери NFSv3, але все ще корисно).
Рішення: Якщо showmount нічого не повертає — підозрюйте фаєрвол/rpcbind/версії NFS або не застосований експорт на сервері.

Задача 11: Підтвердити версію NFS і опції монтування на клієнті

cr0x@server:~$ sudo mount -t nfs -o vers=4.1 nfs01:/tank/projects /mnt/projects
cr0x@server:~$ nfsstat -m | grep -A3 '/mnt/projects'
/mnt/projects from nfs01:/tank/projects
 Flags:	rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.4.18

Що це означає: Ви бачите узгоджену версію NFS і розміри. Якщо монтування негласно відкочується до v3 або використовує UDP — це підказка.
Рішення: Якщо продуктивність погана — переконайтеся, що ви на TCP і на сучасній версії NFS. Якщо дозволи дивні — перевірте sec=.

Задача 12: Раннє виявлення проблем idmapping і «nobody:nogroup»

cr0x@server:~$ getent passwd 1001
acmebuild:x:1001:1001:ACME Build User:/home/acmebuild:/usr/sbin/nologin
cr0x@server:~$ ls -ln /tank/projects/acme | head
total 3
drwxr-x---  5 1001 1001 5 Dec 26 09:11 build

Що це означає: Числове володіння відповідає ідентичності. Якщо клієнти бачать UID 1001, а сервер не знає такого — дозволи ламаються.
Рішення: Якщо getent не може розв’язати ідентифікатори на будь-якій стороні — виправте служби каталогів/SSSD/LDAP перед тим, як переписувати експорти.

Задача 13: Перевірити, чи існують SMB-шари на рівні сервісу (Samba)

cr0x@server:~$ testparm -s | sed -n '1,120p'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

[projects]
	path = /tank/projects
	read only = No
	browsable = Yes

Що це означає: На Linux SMB-шейри контролюються конфігом Samba. ZFS sharesmb може бути не підключена.
Рішення: Якщо ви очікували, що ZFS автоматично створить записи Samba, а їх тут немає — припиніть робити припущення. Оберіть один
контрольний шар і підключіть його явно.

Задача 14: Перевірити живі SMB-шари з погляду Samba

cr0x@server:~$ smbcontrol all reload-config
cr0x@server:~$ smbclient -L localhost -N | sed -n '1,80p'
	Sharename       Type      Comment
	---------       ----      -------
	projects        Disk
	IPC$            IPC       IPC Service (Samba Server)
SMB1 disabled -- no workgroup available

Що це означає: Ви бачите, чи шар фактично подається. «Налаштовано» і «живе» — різні стани.
Рішення: Якщо його немає — виправте конфіг Samba/сервіс; не продовжуйте перемикати sharesmb в надії, що це згенерує stanzas Samba.

Задача 15: Виявити сюрпризи реплікованих властивостей

cr0x@server:~$ zfs get -o name,property,value,source sharenfs,sharesmb -r tank/recv
NAME                 PROPERTY  VALUE  SOURCE
tank/recv            sharenfs  off    default
tank/recv            sharesmb  off    default
tank/recv/projects   sharenfs  on     received
tank/recv/projects   sharesmb  off    received

Що це означає: SOURCE=received — це яскрава неонова табличка: стан доставила реплікація.
Рішення: Якщо це непрохідний хост, встановіть політику: перезаписувати отримані властивості при надходженні або ніколи не виконувати їх автоматично.

Задача 16: Підтвердити, що датасет «шериться», але фактично недоступний (фаєрвол/порти)

cr0x@server:~$ sudo ss -lntp | grep -E '(:2049|:111)\s'
LISTEN 0      64          0.0.0.0:2049      0.0.0.0:*    users:(("rpc.nfsd",pid=1432,fd=6))
LISTEN 0      128         0.0.0.0:111       0.0.0.0:*    users:(("rpcbind",pid=812,fd=4))

Що це означає: NFS і rpcbind слухають порти. Якщо вони не слухають — «експортовано» не має значення.
Рішення: Якщо порти не слухають — виправте сервіси. Якщо слухають, але клієнти не можуть підключитися — перевірте мережеві ACL.

Швидкий план діагностики: що перевіряти спочатку/далі/потім

Це послідовність «припиніть гадати», коли хтось каже «NFS не працює» або «SMB-шару зникла» після зміни властивості.
Мета — ізолювати, чи маєте ви невідповідність контрольної площини, проблему рівня сервісу або
проблему з даними/дозволами.

Перше: чи датасет має бути шареним?

• Запустіть zfs get sharenfs,sharesmb -r для дерева датасетів.
• Подивіться на SOURCE: локальний, успадкований чи received.
• Підтвердьте mountpoint і canmount.

Якщо властивість успадкована і ви цього не очікували — це ваша помилка. Виправляйте ієрархію, а не симптом.

Друге: чи ОС дійсно експортує/подаватиме його?

• NFS: exportfs -v і ss -lntp | grep 2049.
• SMB: testparm -s, потім smbclient -L localhost -N.
• Якщо ви покладаєтеся на автошейринг ZFS: перевірте systemctl status zfs-share (або еквівалент на вашій платформі).

Якщо ZFS каже «шериться», а шар сервісів не погоджується — у вас проблема інтеграції, а не дозволів.

Третє: чи клієнт може погодитися і примонтувати?

• NFS: клієнтське монтування з явним vers=4.1 та перевірка nfsstat -m.
• SMB: спробуйте локальне loopback-з’єднання спочатку, потім віддалене, щоб розділити автентифікацію від мережі.

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

Четверте: чи продуктивність — це скарга, а не доступність?

• Перевірте узгоджені NFS rsize/wsize і протокол.
• Перевірте завантаження CPU на сервері (шифрування/підписування SMB може сильно навантажувати CPU).
• Перевірте здоров’я ZFS: стан пулу і затримки.

Не «тюньте NFS», поки не підтвердите, що ZFS не задихається через sync-записи, деградований vdev або вичерпаний ARC.

Три корпоративні міні-історії з «траншей» властивостей шейрингу

Міні-історія 1: Інцидент через неправильне припущення

Середня за розміром компанія мала два вузли зберігання: один для продакшену і один для тестів відновлення після аварії. Команда щодня реплікувала
датасети. Вони активно використовували властивості ZFS, бо це робило провіжнінг чистим: створити датасет, встановити квоту, встановити
sharenfs, готово.

Під час рутинного тесту DR розробник примонтував проектну шару з DR-вузла «щоб глянути артефакт збірки». Воно змонтувалося. Це був перший сюрприз.
Другий сюрприз — що запис також працював, бо опції експорту були успадковані й пом’якшені.

Ніхто не збирався, щоб DR-вузол експортував щось поза вузькою адмін-підмережею. Але репліковані датасети мали sharenfs як отриману
властивість. І DR-вузол нещодавно оновили, що увімкнуло юніту шейрингу, яка почала виконувати ці властивості при завантаженні. Ніхто не зв’язав
ці факти, бо зміна з’явилася на рівні ОС, а не на рівні ZFS.

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

Виправлення було буденним і ефективним: додали скрипт при завантаженні на DR-вузлі, який примусово ставив sharenfs=off і
sharesmb=off для всіх отриманих датасетів, а потім застосовував allowlist для небагатьох адміністративних експортів, які справді потрібні.
Не елегантно. Але правильно.

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

Інша організація хотіла «миттєвих шар» для внутрішньої аналітичної платформи. Їхня автоматизація створювала датасети на вимогу для команд.
Щоб не чіпати /etc/exports для кожної команди, вони стандартизували встановлення sharenfs під час створення датасету з
правилом, що базується на мережі, і ввімкнули автоматичну обробку шейрів.

Це гарно працювало місяцями. Потім з’явився новий батьківський датасет: tank/analytics. Хтось установив
sharenfs=rw=@10.50.0.0/16 на батьку, щоб зменшити шаблонність, очікуючи, що дочірні будуть жорсткішими при потребі.
Це та оптимізація: покластися на наслідування.

Через квартал аудит виявив, що кілька датасетів, які мали бути обмеженими підмережею, експортувалися ширше. Не тому, що хтось локально щось помилково
встановив, а тому, що ті дочірні датасети ніколи не перевизначили наслідувану властивість. Їхні творці думали «без явного sharenfs — не шариться».
У ZFS «без явного» часто означає «успадковано».

Усунення було брудним: аудит кожного датасету, явна установка sharenfs=off на обмежених деревах і рефакторинг автоматизації так, щоб
вимагати явного декларування шейру при створенні (навіть якщо це «off»). Урок не в тому, що наслідування погане. Урок у тому, що наслідування — гострий інструмент,
і його не слід давати кожному пайплайну без запобіжних заходів.

Жарт №2: «Наслідування чудове — аж поки ваші експорти не успадкують ту саму ентузіазм, що й стажисти.»

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

Велике підприємство мало змішані навантаження: Linux NFS для кластерів обчислень, SMB для офісних робочих процесів і випадкові команди додатків,
що потребували винятків. Вони обрали політику, яка звучала неефектно: властивості шейру в ZFS дозволені, але не є авторитетними.

Конкретно: кожен датасет міг мати sharenfs або sharesmb як метадані, але хости зберігання не застосовували їх автоматично.
Натомість невеликий внутрішній інструмент щодня і на вимогу читав ці властивості, перевіряв їх за allowlist і генерував експорти/фрагменти Samba.
Усі зміни проходили рев’ю як код.

Одного дня реплікація принесла дерево датасетів з партнера. Отримані властивості включали sharenfs=rw=@0.0.0.0/0 (так, справді).
Якби хости автошерили, це стало б інцидентом безпеки. Натомість генератор відзначив це як недійсне, відмовився застосувати і вислав оповіщення в чат команди.

Команда все ще отримала операційну зручність «намір шейру слідує за датасетом». Але вони зберегли політику застосування в одному місці.
Практика була нудною — і вона запобігла дуже цікавій ночі.

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

1) «Ми встановили sharenfs=on, але клієнти не можуть монтувати.»

• Симптом: zfs get sharenfs показує «on»; монтування клієнта падає з «access denied» або «no route to host».
• Коренева причина: Сервіс автошейрингу не увімкнено, або NFS-сервіс не запущено, або фаєрвол блокує 2049/111.
• Виправлення: Перевірте systemctl status zfs-share (або еквівалент) і systemctl status nfs-server.
  Підтвердіть порти за допомогою ss. Потім перевірте exportfs -v, що шлях справді в таблиці.

2) «Датасет, який має бути приватним, експортується.»

• Симптом: exportfs -v показує несподіваний експорт; zfs get показує наслідуваний шейринг.
• Коренева причина: sharenfs встановлено на батьківському датасеті; дитина успадкувала це непомітно.
• Виправлення: Встановіть sharenfs=off на батьку або явно на приватних дочірніх датасетах. Додайте аудиторську перевірку, щоб заборонити шейринг на батьківському рівні, якщо він не є навмисною межею експорту.

3) «Після реплікації шари поводяться інакше на приймачі.»

• Симптом: Приймач несподівано експортує, або не експортує, поки не відбулося оновлення/перезавантаження.
• Коренева причина: Отримані властивості включають налаштування шейру; приймач тепер їх шанує через зміни сервісів.
• Виправлення: Вирішіть політику реплікації: відкидати/перезаписувати властивості шейру при отриманні або ніколи не запускати автошейринг на приймачах. Використовуйте zfs get ... source, щоб знайти received.

4) «SMB працює, але дозволи для NFS неправильні (або навпаки).»

• Симптом: Той самий датасет, різні результати доступу по протоколах.
• Коренева причина: Невідповідність idmapping, різні очікування ACL, або неправильно зрозуміті опції експорту як root_squash.
• Виправлення: Перевірте UIDs/GIDs за допомогою getent на сервері й клієнті. Підтвердіть налаштування ACL/xattr на ZFS. Перегляньте опції експорту й VFS-модулі Samba, якщо використовуються.

5) «Ми вимкнули sharenfs, але він все ще експортується.»

• Симптом: Властивість показує off; exportfs -v все ще містить експорт.
• Коренева причина: Експорт існує в /etc/exports або в згенерованому конфігу поза ZFS; або unshare не було застосовано.
• Виправлення: Знайдіть авторитетне джерело. Видаліть експорт з явних конфігів, потім виконайте exportfs -ra. Якщо ZFS оркеструє — виконайте zfs unshare/zfs share -a як треба.

6) «Колізії імен шейрів або некрасиві шляхи в списку SMB.»

• Симптом: Дублікати імен шар, дивні імена шейрів або неправильні шляхи.
• Коренева причина: Автогенерація SMB-шарів з імен датасетів конфліктує з людськими конвенціями; кілька датасетів мапляться на схожі імена.
• Виправлення: Не автогенеруйте імена SMB зі шляхів датасетів, якщо ви не контролюєте номенклатуру строго. Віддавайте перевагу явним stanzas Samba з кураторними іменами і вважайте sharesmb лише метаданими.

7) «Продуктивність впала після «налаштування» опцій шейру.»

• Симптом: Піки затримок, таймаути клієнтів, підвищене завантаження CPU або злі журнали баз даних.
• Коренева причина: Включено синхронні важкі семантики без усвідомлення (або вимкнено їх без розуміння), витрати CPU на підпис/шифрування SMB або погана домовленість NFS rsize/wsize.
• Виправлення: Підтвердіть вимоги до надійності робочого навантаження. Заміряйте CPU сервера і затримки ZFS. Закріпіть версію NFS і транспорт, якщо потрібно. Не копіюйте опції монтування з інтернету без розуміння.

Операційні патерни: як це запускати без жалю

Патерн A: «Властивості як метадані, політика в іншому місці» (рекомендовано для більшості організацій)

Ви дозволяєте командам встановлювати sharenfs/sharesmb як властивості, але не застосовуєте їх автоматично. Контрольований процес
читає їх і генерує експорти/конфіг Samba після валідації:

• Датасет знаходиться в дозволеному піддереві (наприклад, tank/projects так, tank/system — ні).
• Опції з allowlist (жодних відкритих для світу експортів, жодних небажаних режимів безпеки).
• Зміни проходять рев’ю, аудиту і застосовуються передбачувано.

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

Патерн B: «Один хост, одна ціль, автошейринг прийнятний»

Якщо ви працюєте з єдиним апаратом зберігання або в строгому контрольованому середовищі, де ZFS є контрольним шаром шейрингу за замовчуванням
(поширено в appliance на illumos), автошейринг може бути нормальним вибором. Але все одно потрібні:

• Строгі межі ієрархії датасетів: лише одне піддерево дозволено для шейрингу.
• Явне встановлення off на чутливих батьках, щоб уникнути випадкових наслідувань.
• Аудит-завдання для виявлення несподіваних «on»-значень, особливо inherited/received.

Патерн C: «Тільки явні конфіги сервісів»

Це підхід максимального контролю: ігноруєте властивості шейру і керуєте NFS/SMB через конфіги сервісів і CM. Це життєздатно, але ви втрачаєте
частину корисної інспекції. Якщо обираєте цей шлях, принаймні використовуйте властивості як документацію: ставте їх у значення off по всьому і зберігайте намічені експорти в CMDB/інвентарі.

Де команди посміхаються втратою: змішування патернів

Найгірші налаштування — це гібриди без правил:

• Деякі експорти в /etc/exports, деякі через автошейринг ZFS.
• Шари створені вручну в Samba плюс властивості ZFS, які «інколи» створюють шари.
• Автоматизація, що встановлює властивості, але ніхто не знає, чи вони застосовуються.

Якщо ви запам’ятаєте одну річ: виберіть одну авторитетну контрольну площину для кожного протоколу. Все інше — метадані.

Ставлення до безпеки: припускайте, що властивості шейру — не контроль доступу

Трактуйте опції шейру як один зі шарів. Ваша справжня безпека — в сегментації мережі, фаєрволах хостів, управлінні ідентичностями і дозволах/ACL.
Якщо ви покладаєтеся на «ніхто не встановить sharenfs неправильно», ви вже програли.

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

Контрольний список 1: Безпечне введення sharenfs в існуюче середовище

1. Інвентар поточних експортів: зафіксуйте вивід exportfs -v й збережіть його.
2. Інвентар властивостей ZFS: zfs get -r sharenfs,sharesmb -o name,property,value,source.
3. Визначте межу шейру: оберіть один батьківський датасет, в межах якого дозволено шарити.
4. Встановіть безпечні значення за замовчуванням: встановіть sharenfs=off і sharesmb=off на батьках, які ніколи не повинні шаритися.
5. Вирішіть контрольну площину: автошейринг на хостах, генератор чи лише явні конфіги.
6. Реалізуйте аудит: оповіщення про sharenfs=on поза межею й оповіщення про source=received.
7. Протестуйте на одному датасеті: увімкніть шейр, підтвердьте появу на рівні сервісу, змонтуйте з тестового клієнта.
8. Розгортайте поступово: мігруйте експорти по одному; уникайте «вмикнути батька і молитися».

Контрольний список 2: Обробка реплікації в неавторитетне середовище (DR/staging)

1. На приймачі вимкніть автошейринг, якщо немає причин його вмикати.
2. Після кожного receive скануйте отримані властивості: zfs get -r -o name,property,value,source sharenfs,sharesmb.
3. Застосуйте політику: автоматично ставте sharenfs=off/sharesmb=off там, де шари не дозволені.
4. Документуйте винятки: небагато датасетів, які мають бути експортовані в DR (зазвичай жодного), повинні бути явними й під рев’ю.

Контрольний список 3: Дебаг повідомленого інциденту (NFS/SMB)

1. Підтвердіть намір: чи датасет має бути шареним? Перевірте властивість і наслідування.
2. Підтвердіть стан монтування: датасет змонтований, правильний mountpoint.
3. Підтвердіть рівень сервісу: exportfs -v або smbclient -L з сервера.
4. Підтвердіть мережеву доступність: слухаючі порти і правила фаєрволу.
5. Підтвердіть відображення ідентичностей: getent, володіння, поведінка ACL.
6. Тільки після цього налаштовуйте продуктивність або змінюйте складні опції.

FAQ

1) Чи варто використовувати sharenfs/sharesmb у продакшені?

Так, але лише якщо ви чітко визначили контрольну площину. Для багатовузлових середовищ використовуйте їх як метадані та застосовуйте політику через
контрольований генератор або allowlisted автоматизацію.

2) Чому «zfs set sharenfs=on» не експортує негайно на моєму Linux-хості?

Бо властивість — це не двигун експорту. Потрібен шар інтеграції (часто systemd-юніта на кшталт zfs-share) і запущений NFS-сервер.
Без цього це лише збережена властивість.

3) Чи можна виражати опції експорту NFS всередині sharenfs?

Часто так, залежно від інтеграції платформи. Але як тільки ви це зробите, ви створили другу мову експорту. Стандартизуйте рядки опцій або забороніть
вільні опції й дозволяйте лише «on/off» плюс централізовану політику.

4) Як визначити, чи властивість шейру успадкована або отримана?

Використайте zfs get -o name,property,value,source sharenfs,sharesmb. Якщо source — inherited або
received, ставтеся до цього як до підвищеного ризику і перевірте.

5) Чи гарантує вимкнення sharenfs, що датасет не експортується?

Ні. Це впливає лише на шлях експорту, керований ZFS. Датасет все ще може експортуватися через явний /etc/exports або інші інструменти.
Завжди перевіряйте exportfs -v.

6) Чи доцільний sharesmb на Linux з Samba?

Зазвичай не як авторитетний контрольний шар, бо Samba керується власними файлами і інструментами. Використовуйте sharesmb як підказку/метадані,
якщо у вас немає доказаної надійної інтеграції, яка генерує конфіг Samba безпечно.

7) Який найбільший ризик безпеки з властивостями шейру?

Наслідування і реплікація. Батьківська властивість або отримана властивість можуть експортувати більше, ніж планувалося, і це може активуватися пізніше,
коли сервіси зміняться. Аудитуйте успадковані/отримані шари і впровадьте межі.

8) Як запобігти випадковому шаруванню нових дочірніх датасетів?

Не встановлюйте шейр «on» на широкому батьку, якщо цей батько не є навмисною межею експорту. Віддавайте перевагу явному шейрингу для кожного датасету і
встановлюйте sharenfs=off на чутливих батьках як запобіжник.

9) Чому SMB-браузинг показує дивні шари, навіть коли користувачі не можуть їх відкрити?

Браузинг відображає рекламовану конфігурацію шарів, а не успішність доступу. Можливо, ви автоматично публікуєте шари без відповідних ACL/відповідності ідентичностей.
Виправте визначення шару і модель дозволів; не покладайтеся на «вони все одно не зможуть зайти».

10) Який найпростіший безпечний підхід для маленької команди?

Тримайте sharenfs/sharesmb вимкненими за замовчуванням і керуйте NFS/SMB явно. Якщо згодом впроваджуєте властивості, робіть це лише
в одному присвяченому піддереві і з аудит-роботою.

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

1. Аудит зараз: запустіть zfs get -r sharenfs,sharesmb -o name,property,value,source і знайдіть успадковані/отримані сюрпризи.
2. Підтвердіть істину: порівняйте намір ZFS з живим станом сервісів за допомогою exportfs -v і інструментів Samba.
3. Оберіть контрольну площину: або «автошейринг ZFS авторитетний» (рідко), або «конфіги сервісів авторитетні» (часто) або «властивості — метадані + генератор» (краще в масштабі).
4. Намалюйте межі: визначте, яке піддерево датасетів дозволено шарити, і зафіксуйте інші явно.
5. Напишіть рукопис: включіть кроки швидкої діагностики і дії з повторного шейрингу/перезавантаження, які потрібні вашій платформі.

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