SMB: спільні ресурси Windows для Linux — контрольний список сумісності

February 6, 2026 • February 6, 2026 • Читання: 5 хв • Views: 0

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

Деякі відмови не виглядають як відмови. Вони виглядають як «випадкова» зупинка Linux-застосунку при читанні файлу зі спільного ресурсу Windows або як нічне завдання, яке раптово триває три години через зміну параметра монтування.

SMB працює аж до того моменту, коли перестає. Тоді доводиться перекладати між ACL Windows, очікуваннями Linux щодо UID/GID, узгодженням діалекту SMB та політиками безпеки, які писалися в іншу епоху. Цей контрольний список допоможе припинити здогадки й почати доводити.

Модель сумісності: що може зламатися (і чому це завжди три речі)

Коли Linux-клієнт використовує Windows SMB-шар, сумісність — це не один перемикач. Це стек:

Транспорт і узгодження: Чи можуть клієнт і сервер домовитися про діалект SMB (SMB2/SMB3), і чи можуть вони автентифікуватися (NTLM/Kerberos) по мережевому шляху, який у вас фактично є?
Авторизація й ідентичність: Після автентифікації чи дозволено вам виконувати операцію? Тут стикаються права спільного ресурсу Windows, NTFS ACL і очікування Linux щодо UID/GID.
Семантика й продуктивність: SMB — це не POSIX. Блокування файлів, кешування, семантика перейменування, чутливість до регістру та поведінка метаданих відрізняються. Ваш застосунок може бути «правильним», але все одно здивуватися.

Якщо ви примусите себе класифікувати кожну проблему як (1) узгодження/автентифікація, (2) авторизація або (3) семантика/продуктивність, ви перестанете метушитися. Більшість інцидентів — комбо.

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

Жарт №1: SMB схожий на конференц-дзвінок — всі кажуть, що все добре, поки хтось не спробує поділитися екраном.

Що означає «сумісний» насправді

Ваш діалект SMB явно обраний або принаймні зафіксований і прийнятий (SMB3 бажаний; SMB1 має бути в минулому).
Ваш метод автентифікації свідомо обраний (Kerberos для доменних середовищ, NTLM тільки якщо крайня необхідність, ніколи не «те, що працювало минулого разу»).
Ваші параметри монтування відповідають робочому навантаженню: переважно читання або інтенсивні записи, багато метаданих чи потокова передача, один клієнт чи кілька записувачів.
Ваша модель прав документована: чи відображаєте ви Windows ACL, чи використовуєте грубу маску з виділеним сервісним акаунтом?
Ваш режим відмови відомий: якщо сервер перезавантажиться, чи зависне клієнт? Ви хочете «hard» монти або «soft» поведінку? Який ваш бюджет таймаутів?

Факти й історія, що пояснюють сьогоднішню дивність

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

SMB спочатку не був «тільки для Windows». SMB походить із IBM/Microsoft спадщини й став повсюдним через мережеві рішення Windows; пізніше Samba зробила його кросплатформеним стандартом на практиці.
SMB1 (CIFS) — старий і за замовчуванням небезпечний. Він багатослівний, неефективний, і його екосистема повна припущень, що не витримують сучасних загроз.
SMB2 був основним переробленням. Він суттєво зменшив проблему «одна файлова операція = багато мережевих запитів», яка робила SMB1 повільним на зв’язках з високою затримкою.
SMB3 додав серйозні корпоративні можливості. Шифрування, кращий підпис, multichannel і вдосконалене відновлення вивели його в протокол для центрів обробки даних.
Права Windows спираються на ACL. Windows побудований навколо багатих ACL; Linux виріс із POSIX-бітами режиму. Міст між ними завжди переклад, ніколи ідеальне відображення.
Opportunistic locks (oplocks) еволюціонували в leases. Клієнтське кешування змінювалося з часом, і взаємодія між кешуванням та записами з кількох клієнтів все ще породжує помилки узгодженості.
DFS namespace ускладнює питання «з яким сервером я спілкуюся?» Шлях може бути перенаправленням, а не безпосереднім сервером. Linux-клієнти можуть слідувати за DFS referral, але поведінка відрізняється залежно від клієнта й конфігурації.
Чутливість до регістру — філософська суперечка з наслідками. Windows традиційно нечутливий до регістру; Linux — чутливий. SMB мусить емулювати одне на іншому, і краєві випадки з’являються в системах збірки й сховищах артефактів.
Підпис SMB став частішим через стандарти безпеки. Багато організацій тепер вимагають підпису; це покращує цілісність, але може зменшувати пропускну здатність і навантажувати CPU на старих серверах або маленьких клієнтах.

Це не музейні факти. Вони прямо мапуються на «чому цей монтування повільне», «чому перейменування не вдається» і «чому зміна політики вивела з ладу половину парку».

План швидкої діагностики (знайдіть вузьке місце за хвилини)

Це порядок, що працює в продакшні: починайте з найменш неоднозначних сигналів, потім заглиблюйтесь. Не починайте з зміни параметрів монтування. Спочатку спостерігайте.

Спочатку: встановіть, з чим ви фактично з’єднані

Підтвердьте цільовий сервер і шлях до шару (уважайте на DFS).
Підтвердьте узгоджений діалект SMB і режим безпеки (підпис/шифрування).
Підтвердьте, чи використовується Kerberos, чи ви тихо впали на NTLM.

Друге: розділіть проблему на мережу, сервер і клієнт

Мережа: затримка, втрата пакетів, невідповідний MTU, асиметрична маршрутизація.
Сервер: CPU (крипто/підпис), вузьке місце диска, антивірусне сканування, VSS snapshots, ліміти SMB-сервера.
Клієнт: параметри монтування (cache/actimeo), прострочені облікові дані, DNS, поведінка модуля ядра cifs.

Третє: відтворіть мінімальним навантаженням

Перелік великого каталогу (інтенсивність метаданих).
Один великий послідовний чит/запис (пропускна здатність).
Багато дрібних створень файлів (метадані + блокування).

Четверте: вирішіть, що змінювати

Якщо узгодження/автентифікація неправильні: виправте DNS/SPN/Kerberos або примусьте діалект.
Якщо авторизація неправильна: виправте права спільного ресурсу/NTFS ACL або використайте модель сервісного акаунта.
Якщо семантика/продуктивність неправильні: налаштуйте кешування/leases, перегляньте очікування застосунку або перемістіть навантаження з SMB.

Парафразована ідея від Werner Vogels (надійність): Проєктуйте на відмову; припускайте, що щось зламається, і будуйте системи, які продовжують працювати.

Контрольні списки / покроковий план (побудуйте правильно, підтримуйте правильно)

Контрольний список A: Передумови на боці сервера (Windows)

SMB1 вимкнений — якщо тільки ви не підтримуєте застарілі пристрої в ізоляції.
SMB2/SMB3 увімкнені (за замовчуванням на сучасних Windows Server, але перевірте політики).
Права спільного ресурсу налаштовані свідомо (не залишайте «Everyone: Full Control» і не вважайте, що тільки NTFS ACL врятує вас).
NTFS ACL вирівняні з обраною моделлю сервісної ідентичності.
Політики підпису/шифрування відомі: обов’язкові/необов’язкові, і звідки брати CPU.
Винятки антивірусного сканування розглянуті для директорій з високим пулом створень (з прийняттям ризику).
Синхронізація часу правильна (Kerberos ненавидить подорожі в часі).

Контрольний список B: Передумови на боці клієнта (Linux)

cifs-utils встановлено і ядро підтримує необхідні можливості SMB3.
DNS працює і зворотне розв’язування не зламане, якщо використовується Kerberos.
Годинник синхронізований (chrony/systemd-timesyncd), щоб уникнути помилок Kerberos.
Обробка облікових даних визначена: keytab, файл облікових даних або інтеграція з менеджером секретів.
Параметри монтування задокументовані і впроваджені послідовно (systemd mount units або fstab, керований конфігураційним менеджментом).
Інструменти спостереження: знайте, куди йдуть журнали ядра; маєте стандартний набір команд «SMB debug bundle».

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

Чи припускає ваш застосунок POSIX? Якщо він залежить від атомарного перейменування між каталогами, жорстких посилань або суворої семантики блокувань, протестуйте це. Не теоретизуйте.
Модель конкуренції зрозуміла: один записувач/декілька читачів чи кілька записувачів.
Масштаб каталогу: SMB справляється з великими каталогами, але операції, що інтенсивно використовують метадані, можуть бути болючими, коли кешування консервативне або підпис обов’язковий.
Правила імен файлів: Windows забороняє деякі символи; Linux їх ігнорує. Пізніше ваш пайплайн може від цього постраждати.

Покроковий план розгортання (суб’єктивно)

Виберіть модель автентифікації: Kerberos з AD для продакшну, або виділений локальний/шар акаунт лише для ізольованих випадків.
Виберіть діалект: SMB3, якщо немає вагомої причини ні.
Виберіть стратегію прав:
- Стратегія 1 (сервісний акаунт): найпростіша; використовуйте виділений AD акаунт, грубі дозволи й розглядайте шар як залежність застосунку.
- Стратегія 2 (кожен користувач окремо): складніше; вимагає відображення ідентичностей, Kerberos і грамотних ACL.
Виберіть поведінку монтування: віддавайте перевагу hard для критичних даних; використовуйте таймаути свідомо.
Тестуйте навантаження з реальним профілем: обхід директорій, шторми з дрібними файлами, паралельні збірки — те, що робить ваш застосунок.
Інструментуйте і документуйте: як виглядає «добре» (діалект, підпис, типова пропускна здатність, типова затримка).
Заблокуйте параметри монтування і впровадьте через автоматизацію. Дрейф — тихий вбивця.

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

Нижче — практичні завдання, які ви можете виконати на Linux-клієнті. Кожне включає: команду, приклад виводу, що це означає, і рішення, яке треба прийняти.

Завдання 1: Підтвердження базової досяжності мережі (щоб уникнути налагодження SMB через недоступний маршрут)

cr0x@server:~$ ping -c 3 fs01.corp.example
PING fs01.corp.example (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=127 time=1.12 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=127 time=1.08 ms
64 bytes from 10.20.30.40: icmp_seq=3 ttl=127 time=1.05 ms

--- fs01.corp.example ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 1.05/1.08/1.12/0.03 ms

Значення: Низька затримка, без втрат. Можна продовжувати.

Рішення: Якщо затримка велика або є втрата пакетів, зупиніться тут і виправте мережу перед налаштуванням SMB.

Завдання 2: Перевірте TCP-з’єднання до SMB (порт 445)

cr0x@server:~$ nc -vz fs01.corp.example 445
Connection to fs01.corp.example 445 port [tcp/microsoft-ds] succeeded!

Значення: Ви можете дістатися до SMB-сервісу.

Рішення: Якщо не вдається, перевірте правила фаєрвола, Windows Defender Firewall, security groups або некоректне маршрутизування на балансувальнику.

Завдання 3: Перевірте розв’язування імен (Kerberos і SMB ненавидять неоднозначний DNS)

cr0x@server:~$ getent hosts fs01.corp.example
10.20.30.40     fs01.corp.example fs01

Значення: Ім’я резольвиться на одиночну IP. Передбачувано.

Рішення: Якщо повертається кілька IP несподівано, ви можете звертатися не до того сервера (особливо з DFS або кластерними ролями). Закріпіть правильне ім’я або виправте DNS.

Завдання 4: Знайдіть доступні шари (і чи заблоковано саме перелічення)

cr0x@server:~$ smbclient -L //fs01.corp.example -U 'CORP\buildsvc%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	builds          Disk      Build artifacts
	IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Значення: Шар існує; SMB1 вимкнено (добре). Облікові дані працюють.

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

Завдання 5: Підтвердіть узгодження діалекту SMB з боку клієнта (після монтування)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o username=buildsvc,domain=CORP,vers=3.1.1
cr0x@server:~$ cat /proc/fs/cifs/DebugData | sed -n '1,40p'
=== CIFS DebugData ===
Number of CIFS mounts: 1
...
SMB3.11 dialect
Security Mode: Signing enabled
...

Значення: Ви підключені по SMB 3.1.1 і підпис увімкнено.

Рішення: Якщо узгоджується SMB2.0 або старіший несподівано, дослідіть політику сервера, клієнтське ядро або проміжні пристрої. Якщо підпис/шифрування вимагається, закладіть CPU у планування.

Завдання 6: Перевірте статус Kerberos-квитків (якщо використовується AD)

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: buildsvc@CORP.EXAMPLE

Valid starting       Expires              Service principal
02/05/2026 08:10:02  02/05/2026 18:10:02  krbtgt/CORP.EXAMPLE@CORP.EXAMPLE

Значення: У вас є дійсний TGT; Kerberos повинен працювати, якщо SPN і DNS адекватні.

Рішення: Якщо немає квитка, не припускайте, що SMB «просто використає NTLM». В регульованих середовищах це часто неприйнятно.

Завдання 7: Змонтуйте явно з Kerberos (щоб зменшити тихі відкатні сюрпризи)

cr0x@server:~$ sudo umount /mnt/builds
cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o sec=krb5,vers=3.1.1,cruid=$(id -u)
cr0x@server:~$ mount | grep /mnt/builds
//fs01.corp.example/builds on /mnt/builds type cifs (rw,relatime,vers=3.1.1,sec=krb5,cache=strict,username=buildsvc,domain=CORP,uid=0,noforceuid,gid=0,noforcegid,addr=10.20.30.40)

Значення: Монтування використовує Kerberos (sec=krb5).

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

Завдання 8: Перевірте чит/запис і спостерігайте затримку при операціях інтенсивних у метадані

cr0x@server:~$ time sh -c 'for i in $(seq 1 2000); do : > /mnt/builds/.meta_test_$i; done'
real	0m6.412s
user	0m0.102s
sys	0m0.580s
cr0x@server:~$ rm -f /mnt/builds/.meta_test_*

Значення: Це вимірює затримку створення під поточними параметрами монтування/безпеки.

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

Завдання 9: Виміряйте послідовну пропускну здатність (читання)

cr0x@server:~$ dd if=/mnt/builds/large.iso of=/dev/null bs=16M status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3 s, 357 MB/s
cr0x@server:~$ echo $?
0

Значення: Велика послідовна швидкість читання в нормі.

Рішення: Якщо пропускна здатність низька, але метадані в нормі, перевірте CPU для підпису/шифрування та відключення NIC offloads, а також продуктивність сховища на сервері.

Завдання 10: Перевірте наявність CIFS-помилок на боці клієнта в журналах ядра

cr0x@server:~$ dmesg -T | tail -n 12
[Wed Feb  5 08:31:22 2026] CIFS: VFS: \\fs01.corp.example Send error in SessSetup = -13
[Wed Feb  5 08:31:22 2026] CIFS: VFS: cifs_mount failed w/return code = -13
[Wed Feb  5 08:31:22 2026] CIFS: VFS: \\fs01.corp.example error -13 on ioctl to get interface list

Значення: -13 — це відмова в доступі. Це автентифікація або авторизація, а не «Linux якийсь дивний».

Рішення: Перейдіть до перевірки ідентичності/автентифікації: Kerberos-квиток, ім’я користувача/домену, права на боці сервера, NTFS ACL.

Завдання 11: Перегляньте поточні CIFS-сесії та статистику по шарах

cr0x@server:~$ cat /proc/fs/cifs/Stats
Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 2 Pool size: 2097152
SMB Small Req Buffer: 0 Pool size: 262144
Total vfs operations: 18243
Total oplock breaks: 3

Значення: Підтверджує активність; oplock breaks свідчать про події координації кешування.

Рішення: Якщо кількість oplock breaks зростає під мультизаписовими навантаженнями й продуктивність падає, перегляньте очікування щодо кешування/leases і поведінку застосунку.

Завдання 12: Підтвердьте вимогу сервера щодо підпису/шифрування (з боку клієнта)

cr0x@server:~$ sudo umount /mnt/builds
cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o username=buildsvc,domain=CORP,vers=3.1.1,seal
cr0x@server:~$ cat /proc/fs/cifs/DebugData | grep -E 'Security Mode|SMB3'
SMB3.11 dialect
Security Mode: Signing enabled

Значення: seal запитує шифрування. Деякі налаштування показують статус шифрування по-іншому, але невдача монтування, коли шифрування обов’язкове — підказка.

Рішення: Якщо монтування не вдається без seal, але вдається з ним (або навпаки), у вас невідповідність політик: сервер вимагає шифрування або відкидає його для цього шару.

Завдання 13: Виявіть, чи потрапляєте ви на DFS referrals (поширена пастка «не той сервер»)

cr0x@server:~$ smbclient -k -c 'ls' //corp.example/dfsroot
  .                                   D        0  Wed Feb  5 08:40:01 2026
  ..                                  D        0  Wed Feb  5 08:40:01 2026
  builds                              D        0  Wed Feb  5 08:40:01 2026

cr0x@server:~$ smbclient -k -c 'cd builds; ls' //corp.example/dfsroot
cd \builds\
Domain=[CORP] OS=[Windows Server 2022 Standard] Server=[Windows Server 2022 Standard]
  .                                   D        0  Wed Feb  5 08:40:05 2026
  ..                                  D        0  Wed Feb  5 08:40:05 2026

Значення: Ви використовуєте DFS namespace і направляєтесь на бекенд-сервер.

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

Завдання 14: Швидко перевірте синхронізацію часу (Kerberos ненавидить зсув більше 5 хвилин)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-02-05 08:42:10 UTC
           Universal time: Wed 2026-02-05 08:42:10 UTC
                 RTC time: Wed 2026-02-05 08:42:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований. Добре.

Рішення: Якщо не синхронізований, виправте час перед тим, як звинувачувати Samba, CIFS або AD. Kerberos нещадний за дизайном.

Завдання 15: Підтвердіть поведінку блокувань файлів (швидкий санітарний тест для мультизаписових застосунків)

cr0x@server:~$ python3 - << 'PY'
import fcntl, time
f=open("/mnt/builds/locktest.txt","w")
fcntl.flock(f, fcntl.LOCK_EX|fcntl.LOCK_NB)
print("locked")
time.sleep(2)
print("done")
PY
locked
done

Значення: Це тестує погляд клієнта на блокування; це не повне доказ розподіленого блокування, але виявляє очевидні проблеми.

Рішення: Якщо ваш застосунок потребує суворих advisory lock між декількома клієнтами, проведіть реальний тест з кількох хостів; семантика SMB може відрізнятися від локальної файлової системи.

Права й відображення ідентичностей: звідки починаються більшість «вчора працювало» історій

Linux хоче UID, GID і бітову маску режиму. Windows хоче ACL з успадкуванням, deny ACE і вкладеними групами, що іноді читаються як юридичні документи. SMB опиняється посередині й переклад — це місце, де люди вводять міфи.

Оберіть стратегію прав і дотримуйтеся її

Стратегія 1: сервісний акаунт + грубе відображення (рекомендовано для застосунків)

Використовуйте виділений AD-акаунт (або gMSA, де доречно) для Linux-споживача.
Надайте цій ідентичності явні права NTFS на бекенд-папку та мінімальні права на рівні шару.
Монтуйте з цією ідентичністю; відображайте все на фіксований UID/GID на Linux через параметри монтування, якщо застосунок очікує прав власності.
Прийміть, що Linux-користувачі не є «реальними» користувачами цього шару; застосунок є.

Стратегія 2: доступ на користувача через Kerberos + відображення ідентичностей (рекомендовано для інтерактивних багатокористувацьких робочих процесів)

Kerberos-автентифікація на користувача та, можливо, multiuser монтування.
Потребує послідовних імен принципалів, кешів облікових даних і уважного управління життєвим циклом.
Потребує розуміння, що означає «chmod» для Windows ACL (часто: не те, що ви хочете).

Права спільного ресурсу vs NTFS ACL: припиніть сперечатися, використовуйте обидва

Правильна операційна позиція:

Права спільного ресурсу як груба перевірка (хто взагалі може зайти).
NTFS ACL як реальна авторизація (що можна робити всередині).

Занадто широкі права спільного ресурсу не катастрофа, якщо NTFS ACL коректні, але вони розширюють площу ураження і ускладнюють реагування на інциденти. Занадто суворі права спільного ресурсу створюють плутанину «працює в Explorer, не працює на Linux», бо різні шляхи доступу й членства груп оцінюються по-різному.

Власність при монтуванні на Linux: вирішіть, чи хочете ви правду чи зручність

При монтуванні через CIFS Linux відображатиме власність і права на основі параметрів монтування й метаданих від сервера. Багато команд обирають зручність:

uid= і gid= для фіксації власника для користувача застосунку
file_mode= і dir_mode= щоб уникнути «permission denied» всередині контейнера/рантайму

Це може бути нормально. Це також може приховувати реальні проблеми авторизації, поки застосунок не спробує операцію, яку Windows ACL забороняє. Якщо ви прив’язуєте все до 0777, ви не вирішили проблему прав; ви її приховали.

Чутливість до регістру й правила імен: повільна відмова

Windows зазвичай трактує Foo.txt і foo.txt як те саме. Linux — ні. Системи збірки, сховища артефактів і інструменти часто припускають семантику Linux. Розміщення їх на SMB, що базується на Windows, може призвести до:

Дубльованих записів, які здаються різними, але конфліктують під час checkout/розпакування
Неповторюваних збірок залежно від порядку операцій клієнта
Інструментів, які «виправляють» регістр і ламають споживачів

Для CI і зберігання артефактів віддавайте перевагу правилам найменування, стабільним щодо регістру, і уникайте символів, заборонених Windows. Це звучить нудно. Так і є. Але це рятує ночі в Slack.

Безпека: підпис, шифрування, Kerberos і як політики впливають на затримку

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

Підпис: цілісність ціною

Підпис SMB захищає від підроблення. Багато базових політик Windows вимагають його. Компроміси:

Витрати CPU на обох кінцях; чим менша машина, тим болючіше навантаження.
Чутливість до затримки: операції, що інтенсивно працюють з метаданими, можуть підсилити накладні витрати.
Сюрпризи при налагодженні: клієнти можуть домовлятися про підпис як увімкнений, хоча він не обов’язковий; обов’язкові політики можуть ламати старі клієнти.

Операційна порада: якщо підпис обов’язковий, виміряйте CPU на файловому сервері Windows під піком. Якщо CPU зростає разом зі зниженням пропускної здатності SMB, ви знайшли вузьке місце.

Шифрування («seal»): конфіденційність з різкими краями

Шифрування SMB3 відмінне, коли потрібно. Але воно не безкоштовне і змінює режими відмов:

CPU і іноді обмеження NIC offload можуть обмежити пропускну здатність.
Неправильно налаштовані політики викликають «працює на одному сервері, не працює на іншому» залежно від вимог шифрування на рівні шару.
Налагодження ускладнюється, бо аналіз мережевих пакетів менш інформативний.

Kerberos: прекрасно, коли працює; безжально, коли ні

Kerberos — правильна відповідь у доменних середовищах. Він дає сильну автентифікацію, взаємну довіру і менше проблем із обробкою паролів. Але є три класичні фактори відмови:

Зсув часу (спочатку виправте NTP, завжди)
Несумісність DNS/SPN (ім’я, яке ви монтуєте, має відповідати service principal)
Життєвий цикл облікових даних (квитки спливають; keytab’и «дрейфують»; сервіси перезапускаються в найгірший момент)

NTLM: «потім вирішимо», що стає постійною архітектурою

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

Складніше забезпечувати сучасні вимоги безпеки.
Часто спирається на файли з паролями на диску.
Більш крихкий при зміні політик (деякі організації обмежують або блокують NTLM).

Прийміть рішення: або ви Kerberos-перший, або ви підпишетеся на операційний борг NTLM. Обидва — вибір. Тільки один масштабується чемно.

Продуктивність і надійність: кешування, oplocks/leases, multichannel та нудні деталі

Проблеми продуктивності SMB зазвичай не про «пропускну спроможність». Вони про невідповідність форми навантаження й поведінки протоколу, посиленої накладними витратами безпеки і затримками метаданих.

Метадані — прихований податок

Перерахування каталогів, stat файлів, перевірка часових міток і створення дрібних файлів — це інтенсивні операції з метаданими. SMB може з цим працювати, але кожна операція може потребувати мережевого кругового поїздку та оцінки прав на сервері.

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

Режими кешування: «cache=none» — це не відвага, це рішення про навантаження

Linux CIFS-монти підтримують різні стратегії кешування. Правильний вибір залежить від того, скільки клієнтів записує одночасно і наскільки вам важлива сувора когерентність.

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

У продакшні віддавайте перевагу коректності для спільних мутабельних даних. Для архівів з більшим обсягом читання можна дозволити більше кешування.

Oplocks/leases: друг продуктивності, ворог наївних мультизаписових налаштувань

Oplocks (і новіші leases) дозволяють клієнтам кешувати дані й метадані. Чудово для продуктивності. Але коли кілька клієнтів пишуть, сервер має ламати oplocks і координуватися. Якщо ваш застосунок багато відкриває/закриває файли, ви можете бачити треш.

Слідкуйте за oplock breaks у CIFS-статистиці і корелюйте з скаргами користувачів. Якщо збігається, можливо, треба переробити робочий процес або відрегулювати очікування щодо кешування.

Multichannel: потенційно корисно, часто неправильно зрозуміле

SMB multichannel може використовувати декілька мережевих шляхів/NIC для пропускної і надійності. Але він має підтримуватися й правильно конфігуруватись на обох кінцях, а мережа повинна вести себе передбачувано. Якщо у вас різні MTU або асиметричні шляхи, multichannel може перетворити «швидко» на «ненадійно».

Надійність при перезавантаженні сервера: ваші прапори монтування визначають досвід користувача

Якщо файловий сервер Windows перезавантажиться, що має зробити Linux?

Hard поведінка монтування може призвести до зависання процесів, поки шар відновлюється. Іноді це правильно (щоб не пошкодити записи), але може виглядати як відмова.
Soft-поведінка може призвести до помилок I/O, які застосунок має обробляти. Багато застосунків цього не роблять.

Вирішіть це залежно від здатності вашого застосунку терпіти помилки. Потім задокументуйте, щоб наступний на виклику не «виправив» випадково.

Жарт №2: Якщо хочете пригод, налаштовуйте продуктивність у п’ятницю. Якщо хочете спати — не робіть цього.

Три корпоративні міні-історії (анонімізовані, болісно правдоподібні)

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

У них був Linux-парк, який монтував Windows-шар з конфігураційними пакетами. Нічого особливого: читати файл при старті, інколи перезавантажувати при зміні. Працювало місяцями, що і передбачає болючий наступний розділ.

Проєкт жорсткого укріплення Windows пройшов і «стандартизував» налаштування SMB. Команда вважала це безпечним, бо Windows-клієнти й досі підключалися нормально. Linux-почав логувати періодичні помилки доступу, але лише на деяких хостах.

Неправильне припущення: «Якщо облікові дані спрацювали один раз, монтування стабільне». Насправді деякі клієнти тихо відкотилися з Kerberos на NTLM залежно від DNS і розв’язання SPN. Після жорсткого укріплення NTLM жорсткіше обмежили. Хости з чистим Kerberos-шляхом продовжували працювати; ті, що монтувалися через псевдонім або з некоректним DNS, впали.

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

Виправлення було непоказним і рішучим: стандартизували ціль монтування на правильний FQDN сервера, виправили записи DNS, примусили sec=krb5 і налаштували монтування так, щоб воно голосно відмовлялося, коли Kerberos недоступний. Інцидент закінчився не «зробити SMB більш ліберальним», а усуненням неоднозначності.

Міні-історія 2: Оптимізація, що відкотилася назад

Група з обробки даних мала повільні стартапи завдань, бо їхній пайплайн перелічував дерево директорій з дрібними довідковими файлами на SMB-шарі. Хтось помітив велику витрату часу на операції з метаданими й вирішив «прискорити» шляхом пом’якшення контролю кешування.

Вони змінили параметри монтування, щоб зменшити частоту перевірки атрибутів. Старт прискорився. Усі святкували. Через два тижні нижчі обробники іноді почали використовувати застарілі довідкові дані після оновлень. Не завжди. Достатньо, щоб підірвати довіру.

Відкат не в тому, що кешування — погано. Він у тому, що застосували клієнтське рішення продуктивності до робочого процесу, який припускав глобальну негайну когерентність між читачами. Windows оновлювала файли на місці; Linux-клієнти інколи не бачили зміни швидко через послаблене атрибутне кешування.

Відновилися шляхом зміни шаблону публікації: публікувати довідкові дані через атомарну заміну директорії (нова версія в новому каталозі, потім оновити вказівний файл), або використовувати версійовані шляхи. Агресивне кешування для спільного «current» вказівника відкотили, але залишили оптимізації для незмінних версійних директорій.

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

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

Платформна команда керувала SMB-монтуваннями для мішаного Windows/Linux середовища: домашні директорії розробників, спільні інструменти і артефакти CI. Нічого гламурного. Система, про яку всі скаржаться і ніхто не хоче брати на себе.

У них було правило: кожне монтування декларується в конфігураційному менеджменті, включає явні vers= і sec=, і супроводжується невеликим скриптом перевірки, що запускається при старті і повідомляє, якщо узгоджений діалект або режим безпеки змінюються відносно базової конфігурації. Ніяких «за замовчуванням». Ніякого «побачимо».

Одного вівторка оновлення ОС змінило поведінку клієнтів на частині хостів (оновлення ядра + модуль cifs може таке зробити). Скрипт перевірки помітив, що переговори підпису змінилися відносно бази. Ще не зламалось, але відрізнялося.

Вони призупинили розгортання, протестували вплив на продуктивність під вимогою підпису і координували з Windows-командою, щоб підтвердити політики. Коли решта організації потім глобально ввімкнула вимогу підпису, їхній парк не впав; його вже протестували, запланували потужності й задокументували.

Ось як виглядає нудна робота, коли її роблять правильно: ви помічаєте дрейф до того, як він перетвориться на інцидент, і можете спати.

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

1) Симптом: «Permission denied» при монтуванні, але smbclient працює

Корінна причина: Різні шляхи автентифікації (Kerberos vs NTLM), або smbclient використовує явні облікові дані, а mount — приховану/фолбекову поведінку.

Виправлення: Монтуйте з явним sec=krb5 (або з явним username/domain), перевірте klist і dmesg на помилки SessSetup.

2) Симптом: Перерахунки директорій повільні; великі читання файлів — в нормі

Корінна причина: Затримка метаданих, підсилена підписом/шифруванням, антивірусним скануванням або консервативним атрибутним кешуванням.

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

3) Симптом: «Stale file handle» або дивні затримки видимості між клієнтами

Корінна причина: Кешування і oplocks/leases взаємодіють з мультизаписовими записами; застосунки припускають POSIX-кохерентність.

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

4) Симптом: Монтування періодично не вдається після зміни пароля

Корінна причина: Пароль збережений у файлі облікових даних; відбулася ротація; монти не оновилися; systemd retries створює «thundering herd».

Виправлення: Віддавайте перевагу Kerberos keytabs або керованим секретам; додайте контрольовану стратегію повторних спроб; налаштуйте оповіщення про помилки автентифікації до накопичення черги задач.

5) Симптом: Працює по IP, не працює по імені (особливо Kerberos)

Корінна причина: SPN прив’язаний до імені; використання IP порушує зіставлення імен Kerberos; DNS-аліас не зареєстрований у SPN.

Виправлення: Використовуйте канонічний FQDN; переконайтеся, що для псевдонімів існують правильні SPN; підтримуйте пряме/зворотне DNS у порядку.

6) Симптом: Пропускна здатність падає після ввімкнення підпису або шифрування

Корінна причина: CPU обмеження через крипто/підпис на сервері або клієнті; старе обладнання або обмеження віртуальної машини.

Виправлення: Виміряйте CPU під час передачі; масштабируйте CPU файлохосту, розподіліть навантаження або застосовуйте шифрування вибірково на рівні шару де це необхідно.

7) Симптом: Випадкові помилки застосунку під час перейменування або заміни файлу

Корінна причина: Семантика перейменування/блокування SMB і оцінка NTFS ACL відрізняються від очікувань локальної POSIX FS; деякі шаблони мають гонки при мультиклієнтній роботі.

Виправлення: Змініть логіку застосунку (запис у тимчасовий файл + fsync-еквівалент + перейменування в межах тієї самої директорії), уникайте атомарних припущень між каталогами, тестуйте при конкуренції.

8) Симптом: Монтування вдається, але файли в Linux показують неправильного власника/режими

Корінна причина: Використання опцій uid/gid та file_mode/dir_mode, які маскують або замінюють очікувані метадані; або відсутнє правильне відображення ідентичностей.

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

FAQ

1) Чи варто колись використовувати SMB1/CIFS з Linux до Windows?

Практично ніколи. Якщо вам потрібен SMB1 для застарілого пристрою, ізолюйте його і розглядайте як виняток ризику. Для сумісності Windows–Linux орієнтуйтеся на SMB3.

2) Який версію SMB варто вказувати в Linux-монтуванні?

Віддавайте перевагу vers=3.1.1, коли обидві сторони його підтримують. Якщо бачите дивне узгодження або старіший сервер, свідомо зменшіть до vers=3.0 або vers=2.1. Не залишайте в продакшні не вказаним; імпліцитне узгодження змінюється з оновленнями клієнта.

3) Kerberos-монтування не вдається, але username/password працює. Чому?

Kerberos суворий щодо імен і часу. Перевірте синхронізацію часу, DNS і чи відповідає SPN імені сервера, який ви монтуєте. Парольна автентифікація, що працює, зазвичай означає, що сервер доступний і шар існує; це не перевіряє коректність Kerberos.

4) Чому мій Linux-застосунок бачить «permission denied», хоча Windows ACL дозволяє?

Або ви автентифікувалися під іншою ідентичністю, ніж думаєте (фолбек автентифікації), або права спільного ресурсу блокують вас, навіть якщо NTFS ACL дозволяє, або ви звертаєтеся до іншого бекенду через DFS referral.

5) Чи безпечно використовувати агресивне кешування клієнта для швидкості?

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

6) Чому операції з директоріями повільніші порівняно з NFS або локальними дисками?

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

7) Як безпечно обробляти облікові дані на Linux?

У доменних середовищах: Kerberos з keytab для сервісів або кеші Kerberos для інтерактивних користувачів. Уникайте статичних паролів у файлах, коли це можливо. Якщо потрібно — захистіть дозволи файлу і автоматизуйте ротацію.

8) Чи можна використовувати SMB для робочих просторів CI?

Можна, але навряд чи варто для активних робочих просторів збірки. CI генерує дрібні файли, блокування і метаданичні шторми. Використовуйте локальні диски для робочих просторів і публікуйте артефакти в SMB (якщо це чит-орієнтований інтеграційний пункт).

9) Який найчистіший спосіб уникнути проблем «не той сервер»?

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

10) Чому монтування зависає під час перезавантаження сервера?

Часто це поведінка hard монтування в поєднанні зі стратегією повторних спроб у CIFS-клієнта. Це зберігає коректність даних, але може заморозити процеси. Якщо ваш застосунок може обробляти I/O-помилки, можна обрати іншу поведінку, але робіть це свідомо й тестуйте.

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

Перелік своїх монтувань: зафіксуйте ім’я сервера, ім’я шару, параметри монтування і чи використовується Kerberos.
Приберіть неоднозначність: примусьте явну версію SMB (vers=) і режим безпеки (sec=krb5, де доречно).
Програйте план швидкої діагностики на одному відомо хорошому хості і на одному проблемному. Порівняйте узгоджені діалект і підпис/шифрування.
Виберіть стратегію прав (сервісний акаунт vs по-користувачу) і зробіть її стандартом, а не командним винаходом.
Бенчмаркуйте форму вашого навантаження (метадані проти пропускної здатності). Оптимізуйте правильне, а не те, що найголосніше скаржиться.
Автоматизуйте й моніторте дрейф: визначення монтувань у конфігураційному менеджменті; сповіщення при зміні діалекту/режиму безпеки.

Якщо ви зробите лише дві речі: зафіксуйте Kerberos (або свідомо вирішіть, що не будете його використовувати), і стандартизуйте параметри монтування. Більшість історій «SMB ненадійний» насправді про «наш набір припущень ненадійний».