Ubuntu 24.04: монтування CIFS повертає «Permission denied» — точні опції для виправлення

November 27, 2025 • February 3, 2026 • Читання: 7 хв • Views: 10

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

Ви ввели mount-команду, яку вже виконували сотні разів. Вона працювала на Ubuntu 22.04. Вона працювала на тому старому jump host, який ніхто не наважується оновити. Тепер на Ubuntu 24.04 ви отримуєте класичний, марний підсумок: «Permission denied».

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

Швидкий план діагностики (перевірити в першу чергу)

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

1) Підтвердіть, що сервер підтримує версію SMB, яку ви вимагаєте

Більшість «Permission denied» на Ubuntu 24.04 — це фактично «зміни в узгодженні протоколу й очікуваннях аутентифікації». Почніть з діалекту SMB.

Якщо сервер старий або сильно обмежений: явно вкажіть vers=3.0 або vers=2.1.
Якщо це древній NAS: може знадобитися vers=1.0 (і тоді варто запланувати його заміну).

2) Підтвердіть механізм аутентифікації (`sec=`) відповідно до політики сервера

Windows і багато NAS-пристроїв дедалі частіше відкидають варіанти NTLM. Деякі середовища вимагають Kerberos. Деякі «затверджені» системи вимагають лише NTLMv2. Зробіть sec= явним і перестаньте гадати.

3) Перевірте журнал ядра за реальною причиною (не довіряйте однорядковому повідомленню mount)

mount.cifs любить підсумовувати все як «Permission denied». Журнал CIFS-клієнта в ядрі покаже, чи це неправильний пароль, невірний SPN, відсутній ключ, зсув годинника або помилка підписування.

4) Доведіть, що ваші облікові дані — саме ті, що ви думаєте

Неправильний домен, неправильний формат імені користувача, спеціальні символи в паролі або файл credentials з Windows-розривами рядків можуть усе це перетворити на «permission denied». Так, і в 2025 році таке трапляється.

5) Лише потім перевіряйте файлові права та ACL

POSIX-права часто не є першопричиною. На SMB ви можете аутентифікуватися успішно і все одно бути відхиленим правилами шарінгу або NTFS ACL. Але якщо ви не можете пройти аутентифікацію, перевірки прав — неактуальні.

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

Що насправді означає «Permission denied» для CIFS на Ubuntu 24.04

У Linux «Permission denied» на CIFS-монтажі зазвичай відповідає EACCES (помилка 13). Ця помилка виникає в кількох різних ситуаціях:

Помилка аутентифікації (невірний user/pass, неправильний домен, невірний метод аутентифікації).
Помилка авторизації (ви аутентифікувалися, але шар відмовляє у доступі).
Невідповідність при узгодженні (діалект SMB або підписування/шифрування не збігаються й іноді проявляються як відмова в доступі).
Проблеми з Kerberos (немає квитка, неправильний SPN, зсув годин, невідповідний keytab).
Непогоджена політика машини (сервер відкидає гостя, відкидає NTLM, вимагає підписування або шифрування).
Плутанина зі сторони клієнта (монтаж пройшов, але операції відмовляються пізніше; додатки повідомляють «permission denied»).

Ubuntu 24.04 не «ламала CIFS» злими намірами. Вона постачається з новішими ядрами, новішими інструментами Samba-клієнта і суворішими налаштуваннями за замовчуванням у середовищах, які прагнуть позбутися небезпечних SMB/NTLM-конфігурацій. Це добре для безпеки. Просто погано для вашого сну.

Парафразована ідея (віднесено): Werner Vogels радив будувати системи, передбачаючи, що відмова — нормальна, і проектувати відновлення. Монтування CIFS — ідеальний приклад: припускайте, що узгодження й аутентифікація підуть не так, і створіть повторюваний шлях діагностики.

Точні опції монтування, що виправляють проблему (копіюйте/вставляйте, а потім налаштовуйте)

Нижче наведені набори опцій монтування, які найчастіше перетворюють Ubuntu 24.04 «Permission denied» на чистий монтаж. Почніть з набору, що відповідає вашому середовищу. Не імпровізуйте.

Випадок A: Сучасний Windows / Samba-сервер, локальні облікові дані (найпоширеніший)

Якщо ви монтуєте шар із username/password (не Kerberos) і не хочете сюрпризів:

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,x-systemd.automount

Чому це працює:

vers=3.0: робить узгодження явним; уникає «допоміжного» поведінки відкату, яка відрізняється залежно від сервера.
sec=ntlmssp: поширений для Windows, коли Kerberos не використовується.
sign: задовольняє сервери, що вимагають підписування; якщо сервер не вимагає — підписування зазвичай не зашкодить.
seal: вмикає шифрування SMB3 там, де підтримується; якщо сервер вимагає шифрування — це запобіжить відмові.
uid/gid + file_mode/dir_mode: забезпечують консистентне відображення власності й режимів для Linux-процесів.
x-systemd.automount: запобігає зависанню під час завантаження і робить монтування більш стійким.

Випадок B: Windows-сервер вимагає підписування, але шифрування не ввімкнене

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

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Випадок C: Старий NAS або стара Samba, які не підтримують SMB3

Тут «Permission denied» часто ховає відмову діалекту. Спробуйте SMB2.1 спочатку:

cr0x@server:~$ sudo mount -t cifs //nas01/Archive /mnt/archive \
  -o credentials=/etc/cifs/archive.cred,vers=2.1,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0775,file_mode=0664

Якщо пристрій справді давній, може допомогти vers=1.0. Це також вагома причина подати запит на заміну з дуже спокійною темою листа.

Випадок D: Active Directory з Kerberos (спеціальний випадок «працює на одній машині»)

Для AD-інтегрованих середовищ Kerberos — правильний довгостроковий вибір. Він також ламається цікавішими способами.

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
  -o vers=3.0,sec=krb5,cruid=1000,multiuser,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Примітки: cruid= прив’язує кеш облікових даних монтування до правильного локального користувача. multiuser дозволяє використовувати кілька Kerberos-кредитів на одному монтуванні (зручно на загальних хостах, небезпечно, якщо ви цього не розумієте).

Випадок E: Користувач домену з NTLMSSP, але формат домену — причина

Тут «permission denied» — просто ваш логін не розбирається так, як ви думаєте. Використайте одну з форм:

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o username='EXAMPLE\jdoe',password='REDACTED',vers=3.0,sec=ntlmssp

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o username='jdoe',domain='EXAMPLE',password='REDACTED',vers=3.0,sec=ntlmssp

Випадок F: Шар дозволяє гостя, але Ubuntu більше не вгадує «guest»

Доступ гостя дедалі частіше блокується (з вагомих причин). Але якщо у вас справді публічний тільки для читання шар:

cr0x@server:~$ sudo mount -t cifs //nas01/Public /mnt/public \
  -o guest,vers=3.0,sec=none,ro,uid=1000,gid=1000,dir_mode=0555,file_mode=0444

Будьте явними. Якщо сервер відкидає гостя — це все одно зазнає невдачі, але тепер ви знаєте, що випадково не надсилаєте ім’я користувача, якого не мали наміру відправляти.

Жарт №1: SMB — єдиний протокол, який може бути одночасно «зворотно сумісним» і «вже не підтримує те, чим ви користуєтесь 12 років».

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

Це частина, яку ви використовуєте під час інцидентів. Кожне завдання має: команду, що означає вивід, і яке рішення ухвалити далі.

Завдання 1: Підтвердіть версію ядра й cifs-utils (базова інформація важлива)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | grep -E '^ii\s+cifs-utils'
ii  cifs-utils  2:7.0-2ubuntu2  amd64  Common utilities for SMB/CIFS mounts

Значення: У вас новіша CIFS-клієнтська стек; поведінка за замовчуванням і можливості безпеки відрізняються від старих хостів.

Рішення: Перестаньте порівнювати поведінку з Ubuntu 20.04/22.04, якщо ви одночасно не порівнюєте sec, vers і вимоги до підписування/шифрування.

Завдання 2: Перевірте розв’язування імен (помилки доступу можуть маскувати «не той сервер»)

cr0x@server:~$ getent hosts filesrv01.example.com
10.20.30.40  filesrv01.example.com

Значення: DNS відповідає IP. Якщо він повертає інший IP, ніж очікувано (VIP перемістився, split DNS, застарілий /etc/hosts), ви можете аутентифікуватися не на ту машину.

Рішення: Якщо IP несподіваний, виправте DNS/hosts перед тим, як торкатися опцій монтування.

Завдання 3: Підтвердіть, що TCP-порт доступний (фаєрволи мовчки брешуть)

cr0x@server:~$ nc -vz filesrv01.example.com 445
Connection to filesrv01.example.com (10.20.30.40) 445 port [tcp/microsoft-ds] succeeded!

Значення: Порт 445 доступний. Якщо ні — це не проблема автентифікації, а мережева.

Рішення: Якщо заблоковано, зупиніться. Ескалуюйте в мережу/безпеку; не «фіксуйте» CIFS-опції.

Завдання 4: Перелічіть шари за допомогою smbclient (перевірка облікових даних)

cr0x@server:~$ smbclient -L //filesrv01.example.com -U 'EXAMPLE\jdoe'
Password for [EXAMPLE\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance         Disk      Finance Share
        Engineering     Disk      Engineering Share
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Значення: Облікові дані приймаються і узгодження SMB працює. Це вже половина битви.

Рішення: Якщо smbclient повертає NT_STATUS_ACCESS_DENIED, зосередьтеся на username/password/domain/sec. Якщо він працює, а монтаж — ні, зосередьтеся на опціях монтування (підписування/шифрування, vers, Kerberos, idmap).

Завдання 5: Перевірка доступу до конкретного шару (ACL шару проти помилки монтування)

cr0x@server:~$ smbclient //filesrv01.example.com/Finance -U 'EXAMPLE\jdoe' -c 'ls'
Password for [EXAMPLE\jdoe]:
  .                                   D        0  Mon Dec  9 12:01:00 2025
  ..                                  D        0  Mon Dec  9 12:01:00 2025
  budgets                             D        0  Mon Dec  9 12:01:00 2025

                104857600 blocks of size 1024. 51372800 blocks available

Значення: Ви можете аутентифікуватись і переглядати вміст шару. Якщо монтаж досі каже «permission denied», проблема майже напевне в узгодженні/параметрах безпеки, а не в NTFS/ACL.

Рішення: Спробуйте явно вказати vers= і sec=, потім підписування/шифрування.

Завдання 6: Запустіть mount з verbose-виводом (підказки з простору користувача)

cr0x@server:~$ sudo mount -vvv -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign
mount.cifs kernel mount options: ip=10.20.30.40,unc=\\filesrv01.example.com\Finance,vers=3.0,sec=ntlmssp,sign
mount error(13): Permission denied

Значення: Все ще неоднозначно. Саме тому перевіряємо журнали ядра далі.

Рішення: Перейдіть до dmesg і шукайте CIFS-повідомлення з реальною причиною.

Завдання 7: Читайте повідомлення ядра для CIFS (істина тут)

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 29 10:15:22 2025] CIFS: VFS: \\filesrv01.example.com Send error in SessSetup = -13
[Mon Dec 29 10:15:22 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Значення: Сесійне налаштування не вдалося (автентифікація/узгодження). Іноді ви побачите більш конкретні рядки на кшталт «Server requires packet signing» або «Krb5 authentication failed».

Рішення: Якщо в логах згадується підписування/шифрування — додайте sign і/або seal. Якщо згадується Kerberos — переходьте до діагностики Kerberos.

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

cr0x@server:~$ modinfo cifs | grep -E 'parm:|version' | head
version:        2.45
parm:           CIFSMaxBufSize:Network buffer size (int)
parm:           SecurityFlags:SecurityFlags, comma separated (int)

Значення: Модуль CIFS ядра присутній і сучасний. Ви не «виправите» це перевстановленням cifs-utils.

Рішення: Зосередьтеся на конфігурації та невідповідності політик сервера, а не на оновленні пакетів.

Завдання 9: Перевірте файл credentials на форматні проблеми (права й CRLF)

cr0x@server:~$ sudo ls -l /etc/cifs/finance.cred
-rw------- 1 root root 58 Dec 29 10:01 /etc/cifs/finance.cred
cr0x@server:~$ sudo sed -n '1,5p' /etc/cifs/finance.cred
username=jdoe
password=REDACTED
domain=EXAMPLE

Значення: Файл читає root лише для запису (добре). Якщо файл доступний усім, ви створили витік облікових даних.

Рішення: Якщо файл прийшов із Windows-інструментів, перевірте CRLF. CRLF може зробити пароль неправильним у спосіб, який ви не помітите візуально.

cr0x@server:~$ sudo cat -A /etc/cifs/finance.cred
username=jdoe$
password=REDACTED$
domain=EXAMPLE$

Значення: $ у кінці рядка означає LF. Якщо ви бачите ^M$, конвертуйте (dos2unix) і повторіть спробу.

Рішення: Виправте кінці рядків перш ніж звинувачувати сервер.

Завдання 10: Спробуйте інший діалект SMB (швидко, оборотно)

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.1.1,sec=ntlmssp,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign

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

Рішення: Зафіксуйте робочий vers явно в /etc/fstab і задокументуйте причину.

Завдання 11: Спробуйте явний режим безпеки (`sec=`) замість покладання на за замовчуванням

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmv2,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign

Значення: Деякі сервери приймають ntlmssp, але відкидають ntlmv2 (або навпаки). В AD-контекстах може очікуватися використання Kerberos замість NTLM.

Рішення: Якщо ntlmssp не працює, а політика каже «лише Kerberos», припиніть наполягати на NTLM і переходьте до налаштування Kerberos.

Завдання 12: Переконайтесь, що монтаж використовує ті опції, які ви вважали

cr0x@server:~$ mount | grep /mnt/finance
//filesrv01.example.com/Finance on /mnt/finance type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=jdoe,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino,mapposix,nofail)

Значення: Запущений монтаж показує погоджені налаштування. Це виявляє класичну проблему, коли ви редагували /etc/fstab, але не перемонтували, або дивитеся не на той mountpoint.

Рішення: Якщо відображений vers або sec не відповідає вашим намірам — ви тестуєте не те.

Завдання 13: Переконайтесь, що файлові операції дійсно працюють (успішний монтаж може ховати проблеми з правами)

cr0x@server:~$ touch /mnt/finance/.cifs-write-test
touch: cannot touch '/mnt/finance/.cifs-write-test': Permission denied

Значення: Ви змонтували шар, але вам заборонено записувати. Це проблема авторизації/ACL, а не узгодження монтування.

Рішення: Перевірте права шару та NTFS ACL для користувача. Не міняйте без потреби sec і vers; автентифікація вже відбулася.

Завдання 14: Перевірте поведінку ACL з боку Linux (виявити плутанину відображення)

cr0x@server:~$ ls -ld /mnt/finance
drwxrwx--- 2 cr0x cr0x 0 Dec 29 10:20 /mnt/finance
cr0x@server:~$ ls -l /mnt/finance | head
total 0
drwxrwx--- 2 cr0x cr0x 0 Dec  9 12:01 budgets

Значення: Локальна власність/режими — це презентація на клієнті, а не обов’язково NTFS-реальність на сервері (якщо тільки ви не використовуєте SMB POSIX-розширення повністю).

Рішення: Якщо Linux-додатки покладаються на POSIX-семантику, вирішіть, чи потрібен вам Samba на сервері з належним POSIX-відображенням, або SMB лише як транспорт для «тупого» доступу до файлів.

Active Directory / Kerberos випадки (де «permission denied» вводить в оману)

Якщо в організації є AD, ймовірно хтось ввімкнув «NTLM: disabled» або «SMB signing required» через політику. Це не баг. Це операційне обмеження. CIFS-клієнт має відповідати політиці сервера щодо аутентифікації та цілісності.

Передумови Kerberos, які не можна проігнорувати

Синхронізація часу має бути правильною. Kerberos не любить зсувів годин.
DNS має бути коректним. Kerberos використовує SPN, які залежать від імен.
Кеш квитків має існувати для користувача, який виконує монтаж (або слід використовувати keytab і правильний режим монтування).

Завдання 15: Перевірте синхронізацію часу (Kerberos дуже чутливий)

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-29 10:22:11 UTC
           Universal time: Mon 2025-12-29 10:22:11 UTC
                 RTC time: Mon 2025-12-29 10:22:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Час синхронізований. Якщо ні — Kerberos може падати як «permission denied», бо ви фактично не аутентифікувалися.

Рішення: Якщо час не синхронізований — налаштуйте NTP/chrony перед будь-якими CIFS-правками.

Завдання 16: Перевірте наявність квитків Kerberos (перевірка в просторі користувача)

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

Valid starting     Expires            Service principal
12/29/25 10:00:01  12/29/25 20:00:01  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Значення: У вас є TGT. Якщо немає — монтаж з sec=krb5 зазнає невдачі.

Рішення: Отримайте квиток через kinit, або використайте системний keytab, якщо потрібен безінтерактивний режим.

Завдання 17: Спробуйте Kerberos-монтаж з явним `cruid` (уникнути неправильного кешу)

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
  -o vers=3.0,sec=krb5,cruid=1000,sign,seal

Значення: Якщо це працює, а та сама команда без cruid — ні, ви використовували неправильний кеш облікових даних (часто трапляється при sudo).

Рішення: Стандартизувати Kerberos-монтажі з cruid і systemd automount-юнітами, а не ad-hoc sudo-сесіями.

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

UID/GID відображення і чому ваші файли «працюють», але додатки — ні

Це тихіша форма відмови. Монтаж вдається. Списки директорій працюють. Потім ваш додаток не може створити lock-файли, CI не може зробити chmod, або контейнер не може записати.

Є два широкі підходи:

«Презентаційне відображення», де ви примусово встановлюєте власника за допомогою uid=, gid= і режимів. Це поширено і часто достатньо.
Справжнє відображення ідентичностей, де SID перетворюються на POSIX ID. Це складніше і зазвичай вибір підприємства, а не просте налаштування на клієнті Linux.

Що робити на клієнтах Ubuntu (прагматичний підхід за замовчуванням)

Якщо у вас немає повного AD→POSIX дизайну ідентичностей, не прикидайтеся. Використовуйте просте відображення:

uid=, gid= — щоб зробити власність передбачуваною для сервісного акаунта.
file_mode=, dir_mode= — щоб відповідати очікуванням Linux-процесу.
Розгляньте noperm, якщо сервер контролює ACL і ви не хочете, щоб клієнт повторно перевіряв доступ (це може бути корисно, але й небезпечне).

Завдання 18: Виявлення сценарію, де потрібен `noperm`

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
cr0x@server:~$ sudo -u '#1000' ls /mnt/finance
ls: cannot open directory '/mnt/finance': Permission denied

Значення: Локальна перевірка прав клієнта відмовляє локальному UID, хоча сервер може дозволяти доступ на основі SMB-облікових даних.

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

cr0x@server:~$ sudo umount /mnt/finance
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,noperm,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Підписування, шифрування та корпоративний податок на безпеку

SMB-підписування і SMB-шифрування — два важелі політики, які найчастіше перетворюються на «Permission denied», коли клієнти не відповідають вимогам.

SMB підписування

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

На Linux CIFS-монтажах ви можете примусити його опцією sign. Якщо сервер вимагає підписування, а клієнт його не виконує, сервер може відмовити в налаштуванні сесії або в подальших операціях.

SMB шифрування (seal)

Шифрування захищає конфіденційність. Шифрування SMB3 узгоджується і може вимагатися на рівні шару в Windows. На Linux seal вмикає шифрування.

Шифрування може знижувати пропускну здатність і підвищувати навантаження на CPU. Іноді це прийнятно. Іноді це несподівана інцидент-продуктивності. Головне — робіть це явним і плануйте потужності.

Завдання 19: Знайти помилки, пов’язані з підписуванням/шифруванням у журналах ядра

cr0x@server:~$ sudo dmesg -T | grep -i cifs | tail -n 10
[Mon Dec 29 10:30:10 2025] CIFS: VFS: Server requires packet signing to be enabled
[Mon Dec 29 10:30:10 2025] CIFS: VFS: cifs_mount failed w/return code = -13

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

Рішення: Додайте sign і повторіть спробу. Якщо ви вже вказали sign і все ще бачите це, можливо ви узгоджуєте старіший діалект — зафіксуйте vers=3.0 або вище.

Три міні-історії з реального життя

1) Інцидент через хибне припущення: «Permission denied означає, що пароль неправильний»

У них був інтеграційний процес payroll на невеликому флоті Ubuntu. Шари були на Windows. Рутинне оновлення ОС перемістило два вузли додатків на Ubuntu 24.04. Монтаж не пройшов при завантаженні. Команда припустила, що паролі були змінені, бо зазвичай саме це означає «permission denied».

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

Зрештою хтось перевірив dmesg і знайшов, що сервер вимагає підписування. Старі вузли неявно узгоджували інший діалект і поведінку підписування; нові — ні. Додавання vers=3.0,sign виправило проблему миттєво.

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

2) Оптимізація, що зіграла проти: «Відключимо шифрування задля продуктивності»

Інша компанія тримала білди артефактів через SMB, бо «це просто мережевий диск». Після аудиту безпеки ввімкнули шифрування SMB3. Продуктивність впала. Розробники скаржилися. Керівництво почуло «повільні збірки» і вимагало дій.

ІнфраКоманда видалила seal з опцій монтування, щоб пришвидшити процес. Це спрацювало в одному середовищі. В іншому те саме зміна fstab викликала «permission denied». Не скрізь — лише для певних шарів.

Причина була тонкою, але логічною: шифрування вимагалося на рівні шару для деяких серверів. Ті, що хостили чутливі артефакти, вимагали шифрування. Видалення seal виявилося порушенням доступу, а не оптимізацією.

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

3) Нудна, але правильна практика, що врятувала: «systemd automount + nofail + зафіксовані опції»

Одна медична організація (так, там критичний рівень доступності) мала правило: мережеві монтування ніколи не мають блокувати завантаження. Кожен CIFS-монтаж використовував systemd automount, nofail і явні vers/sec, зафіксовані відповідно до підтримки командою серверу.

Одного ранку техобслуговування контролера домену створило тимчасові проблеми з Kerberos. Декілька хостів втратили можливість змонтувати AD-захищені шари при завантаженні. Але хости все одно піднялися, сервіси стартували, моніторинг лишився живим. Монти намагалися повторно при доступі і відновились, як тільки Kerberos став стабільним.

Наслідки були — деякі завдання додатків не могли читати вхідні дані деякий час. Але інфраструктура не скотилася в цикл завантаження або emergency mode. Це має велике значення.

Найкраще: нотатки інциденту були короткими, бо поведінка була очікуваною. «Монти на вимогу; перевірити тікети; перевірити доступність DC; чекати; перевірити перемонтування.» Нудно. Правильно. Рятує життя.

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

Цей розділ навмисно конкретний. CIFS падає у повторювані шаблони. Впізнайте шаблон, застосуйте виправлення, рухайтесь далі.

1) Симптом: mount error(13) одразу, smbclient працює

Причина: невідповідність підписування/шифрування або mount використовує інші дефолти, ніж smbclient.

Виправлення: зафіксуйте опції: vers=3.0,sec=ntlmssp,sign; додайте seal, якщо сервер вимагає шифрування. Перевірте mount | grep і dmesg.

2) Симптом: монтаж працює з IP, падає з hostname

Причина: невідповідність DNS/SPN (особливо з Kerberos) або ви потрапляєте на інший сервер за іменем.

Виправлення: використайте правильний DNS, перевірте getent hosts. Для Kerberos упевніться, що SPN відповідає імені, яке ви монтуєте.

3) Симптом: працює на одному Ubuntu-хості, падає на іншому з тією ж командою

Причина: різні дефолти ядра/клієнта, різний кеш облікових даних (Kerberos), різний DNS або відмінні криптополітики.

Виправлення: порівняйте uname -r, dpkg -l cifs-utils і виводи mount -vvv плюс dmesg. Зробіть явними vers і sec.

4) Симптом: монтаж успішний, але запис не вдається з «Permission denied»

Причина: ACL шару / NTFS ACL забороняє запис; або шар доступний лише для читання; або ви змонтували з ro.

Виправлення: підтвердіть через smbclient тест запису; перевірте права на сервері. Не чіпайте vers/sec; автентифікація вже в порядку.

5) Симптом: «Permission denied» тільки при запуску під systemd під час завантаження

Причина: мережа ще не готова, DNS не готовий, квиток Kerberos недоступний або монтаж виконаний до потрібних залежностей.

Виправлення: використайте x-systemd.automount, nofail і розгляньте _netdev. Для Kerberos забезпечте наявність квитків у контексті, що виконує доступ, або використайте keytab-підхід.

6) Симптом: «Permission denied» після ротації пароля, але файл credentials виглядає правильним

Причина: CRLF, проблеми з лапками або приховані символи в паролі.

Виправлення: перевірте через cat -A; конвертуйте в LF; введіть заново уважно; уникайте копіювання через інструменти з форматуванням.

7) Симптом: «mount error(13)» тільки для деяких шарів на тому ж сервері

Причина: політика на рівні шару (вимагається шифрування, інша модель ACL) або різні права шарів.

Виправлення: тестуйте кожен шар через smbclient //server/share. Додайте seal для чутливих шарів, якщо потрібно.

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

Використовуйте це, щоб ваше майбутнє «я» сказало вам спасибі.

Чекліст 1: Одноразове налаштування хоста (Ubuntu 24.04 CIFS-клієнт)

Встановіть інструменти: cifs-utils, smbclient і Kerberos-утиліти, якщо потрібно.
Створіть файл credentials у /etc/cifs/ з правами 0600, власник root.
Створіть точку монтування з коректною власністю й правами для сервісу, що використовує шар.
Визначте модель аутентифікації: NTLMSSP vs Kerberos. Не «пробуйте обидва» в продуктивних конфігураціях.
Зафіксуйте vers і sec. Додайте sign. Додайте seal, якщо потрібно або бажано.

Чекліст 2: Запис у fstab для продуктивності, що не зіпсує завантаження

Розумна базова лінія для запису в fstab для автентифікації по паролю:

cr0x@server:~$ sudo bash -lc "cat >> /etc/fstab <<'EOF'
//filesrv01.example.com/Finance  /mnt/finance  cifs  credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,seal,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,_netdev,x-systemd.automount,x-systemd.idle-timeout=600  0  0
EOF"

Потім перевірте без перезавантаження:

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo mount -a

Рішення: Якщо mount -a не працює — читайте dmesg. Не перезавантажуйтеся в надії, що «очистить» проблему. Це не стратегія; це забобон з зайвими кроками.

Чекліст 3: Послідовність реагування на інцидент (15 хвилин, дисципліновано)

Перевірте доступ до порту 445 (nc -vz host 445).
Перевірте DNS-відображення (getent hosts).
Провалідуйте облікові дані через smbclient -L і доступ до шару через smbclient //host/share.
Монтуйте з явними vers і sec (почніть з vers=3.0,sec=ntlmssp або sec=krb5).
Додайте sign; додайте seal, якщо логи вказують на вимогу шифрування.
Після кожної спроби читайте dmesg щодо CIFS-повідомлень.
Після монтажу виконайте тест запису (touch), щоб відрізнити проблему автентифікації від ACL.

Цікаві факти й контекст (бо SMB має історію)

SMB починався в IBM у 1980-х до того, як Microsoft зробив його відомим. Вік протоколу проявляється сьогодні як «сумісні» дивні нюанси.
«CIFS» фактично бренд епохи SMB1. Linux досі використовує термін «cifs» з історичних причин, навіть коли монтуєте SMB3.
Відключення SMB1 стало нормою. Багато серверів відкидають його; клієнти, які чекають відкату до SMB1, стикаються з плутаними помилками доступу.
NTLM уже довго в списку «будь ласка, припиніть». Багато підприємств активно вимикають NTLM на користь Kerberos.
Підписування SMB раніше було опціональним, а тепер часто вимагається. Це змінює старі дефолти у загартованих середовищах.
SMB3 додав шифрування, яке узгоджується і може вимагатися на рівні шару. Тому «деякі шари працюють» — реальний симптом.
Поведінка Linux CIFS-клієнта розділена між user-space і ядром. mount.cifs передає опції; ядро робить більшу частину роботи і логує реальні помилки.
Помилки Kerberos часто виглядають як помилки доступу, бо сервер не завжди може відрізнити «погана робота квитків» від «немає доступу» з дружнього для користувача повідомлення.
UID/GID на CIFS — переважно ілюзія на боці клієнта, якщо ви не розгорнете повне відображення ідентичностей і/або POSIX-розширення послідовно.

FAQ

1) Чому Ubuntu 24.04 показує «Permission denied», а Ubuntu 22.04 працював?

Тому що оновлення змінило поведінку клієнта: новіший код CIFS у ядрі, інші дефолти узгодження і суворіші очікування безпеки. Зафіксуйте vers і sec, щоб перестати покладатися на дефолти.

2) Яка найкраща «перша фікса» опція монтування?

vers=3.0. Вона усуває великий клас неоднозначностей узгодження. Поєднуйте з sec=ntlmssp для парольної автентифікації або з sec=krb5 для AD Kerberos.

3) Чи варто використовувати `sec=ntlm` або `vers=1.0`, щоб змусити працювати?

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

4) У чому різниця між `sign` і `seal`?

sign забезпечує цілісність (повідомлення не можна підмінити непоміченим). seal вмикає шифрування SMB (конфіденційність). Сервер може вимагати одне або обидва.

5) smbclient працює, монтаж падає. Як таке можливо?

smbclient і kernel CIFS-монтаж можуть узгоджуватися трохи по-різному і використовувати різні дефолти. Також монтаж може бути відхилений через вимоги підписування/шифрування, які ваш тест smbclient не викликав однаково. Використовуйте журнали ядра (dmesg), щоб дізнатися, чому монтаж відхилено.

6) Куди покласти облікові дані і як їх захистити?

Використовуйте файл credentials, наприклад /etc/cifs/share.cred, власник root з правами 0600. Не вставляйте паролі прямо в /etc/fstab. Не лишайте їх читабельними для сервісних користувачів «для зручності».

7) Мій монтаж працює інтерактивно, але падає при завантаженні. Як виправити?

Використайте nofail,_netdev,x-systemd.automount, щоб система завантажувалась незважаючи на затримки мережі, а монтаж виконувався при першому доступі. Для Kerberos забезпечте наявність квитків у контексті, який виконує доступ, або використайте keytab-підхід.

8) Чи варто використовувати `noperm`?

Іноді. Це вирішує невідповідності локальних перевірок прав, коли сервер — джерело істини. Але це також прибирає шар локального захисту. Використовуйте усвідомлено, а не як забобон.

9) Чому я бачу дивну власність, наче всі файли належать root або nobody?

Тому що SMB за замовчуванням не відображає Windows-ідентичності в Linux UIDs/GIDs без додаткових механізмів. Встановіть uid=, gid= і режими для передбачуваної поведінки Linux, або реалізуйте коректне відображення ідентичностей, якщо середовище цього вимагає.

10) Чи доречно монтувати CIFS всередині контейнерів?

Не за замовчуванням. Монтуйте CIFS на хості і потім bind-mount у контейнери, якщо ви не розумієте наскрізь можливості ядра, обробку облікових даних і як ваш оркестратор ставиться до монтувань.

Висновок: наступні дії, які працюють

Якщо Ubuntu 24.04 каже «Permission denied» при монтуванні CIFS, припустіть, що це невідповідність між тим, що ви просите, і тим, що вимагає політика сервера. Далі доведіть це правильними доказами.

Зробіть це далі:

Запустіть тести smbclient, щоб відокремити проблеми облікових даних/ACL від проблем узгодження монтування.
Зафіксуйте vers=3.0 і правильне sec=. Додайте sign. Додайте seal, якщо потрібно.
Після кожної невдалої спроби читайте dmesg; сприймайте текст помилки mount як резюме, а не діагностику.
Помістіть робочу конфігурацію в /etc/fstab з nofail і x-systemd.automount, щоб наступне перезавантаження не стало вашим новим інцидентом.

Схожі статті

Proxmox CIFS «Доступ заборонено»: виправлення облікових даних, діалекту SMB і параметрів монтування