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

December 24, 2025 • February 3, 2026 • Читання: 3 хв • Views: 8

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

Ви ввели правильне ім’я користувача. Ви ввели правильний пароль. Ви вже пробували vers=3.0, vers=2.1, можливо навіть радикальні варіанти. І Proxmox усе одно повідомляє: Доступ заборонено.

Ось момент, коли CIFS/SMB навчає смиренності. «Доступ заборонено» може означати «поганий пароль»… або «ваш NAS не любить діалект SMB», «відображення UID/GID некоректне», «шар дозволів на шейрі лише для читання», або «ви пройшли аутентифікацію, але не маєте авторизації». Та сама помилка. Різні кримінальні сцени.

Швидкий план діагностики

Якщо ви хочете найкоротший шлях від «Доступ заборонено» до робочого монтування — робіть це в такому порядку. Не імпровізуйте. CIFS карає креативність.

1) Підтвердіть, що помилка пов’язана з авторизацією, а не з мережею чи резолюцією імен

Чи можна резолвити ім’я сервера з вузла Proxmox?
Чи доступний TCP/445?
Чи вдається узгодити діалект SMB взагалі?

Якщо DNS або маршрут неправильні, зазвичай ви побачите тайм-аути або помилки «No route», а не «Доступ заборонено». Зазвичай.

2) Перевірте облікові дані за допомогою `smbclient` (не за пам’яттю)

Якщо smbclient не в змозі перелічити шейр — монтування теж не вдасться. Якщо вдається — ви довели аутентифікацію і базовий доступ до шейру, і можете зосередитися на опціях монтування, відображенні UID/GID та використанні Proxmox.

3) Примусово вкажіть явний діалект SMB і режим безпеки

Встановіть vers=3.0 (або 3.1.1, якщо обидві сторони це підтримують) і явно вкажіть sec=ntlmssp або sec=krb5 залежно від середовища. Невідповідність діалекту часто проявляється як помилки авторизації, бо рукопотиск ніколи не доходить до частини з паролем.

4) Розділяйте «монтування працює» і «Proxmox може ним користуватися»

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

5) Читайте журнали ядра

dmesg часто скаже, що CIFS відмовив, який режим безпеки намагалися застосувати і який код статусу повернувся. Помилки в GUI Proxmox знаменито мінімалістичні. Ядро — ні.

Що насправді означає «Доступ заборонено» у CIFS

У Linux CIFS реалізовано модулем ядра і керується mount.cifs. Коли щось не вдається, ви можете бачити:

mount error(13): Permission denied
CIFS: VFS: cifs_mount failed w/return code = -13

Помилка 13 — це «EACCES». Це відро, яке ловить кілька режимів відмови:

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

Трохи сухої втіхи: у CIFS є лише один талант — робити різні проблеми схожими.

Цікаві факти та історія, що пояснюють сучасні проблеми

SMB почався в 1980-х в IBM і був популяризований Microsoft; він старший за багато «сучасних» стеків збереження, якими зараз його переслідують.
«CIFS» — це по суті SMB1, брендований Microsoft у 1990-х. Linux-спеціалісти все ще говорять «mount CIFS», навіть коли ведеться переговори SMB3.
SMB1 фактично мертвий з міркувань безпеки; багато серверів вимикають його за замовчуванням. Клієнти, що намагаються SMB1, можуть отримувати оманливі відмови.
SMB2 з’явився з Windows Vista/Server 2008 і виправив великі проблеми продуктивності (менше раундтріпів, конвеєрування, кращий кешинг).
SMB3 (епоха Windows 8/Server 2012) додав шифрування, multichannel та кращу стійкість — функції, що змінюють спосіб, у який «Доступ заборонено» проявляється при політиці.
NTLM — сумісний опосередник і одночасно ризик безпеки; підприємства дедалі частіше примушують Kerberos або відключають NTLM, що ламає «це працювало минулого року» скрипти.
Семантика режимів файлів у Linux CIFS є синтетичною: file_mode/dir_mode не переписують ACL сервера; вони — клієнтська презентація, якщо не використано Unix extensions / POSIX mapping.
Розширені атрибути важливі: відображення Windows ACL на Linux-права використовує xattrs; їх відключення може перетворити «працює в Explorer» на «Доступ заборонено» у Linux.
Підписування SMB колись було «можливо»; нині воно часто обов’язкове в захищених середовищах. Коли воно не узгоджується — помилка рідко дружня.

Контекст Proxmox: де живуть CIFS-монти і як PVE їх використовує

Proxmox VE (PVE) базується на Debian. Коли ви додаєте CIFS-сховище в GUI, Proxmox зазвичай:

Зберігає конфіг у /etc/pve/storage.cfg (кластерна файлова система).
Монтує шейр під /mnt/pve/<storageid>.
Використовує pvesm для активації сховища, і можуть задіюватися unit-и systemd залежно від версії і конфігурації.

Proxmox тут не особливий. Це Linux. Але Proxmox упереджений щодо поведінки зі сховищами:

Завдання резервного копіювання потребують надійного запису та стабільної семантики блокувань файлів.
ISO/template сховища переважно читаються, але все одно потребують створення каталогів під час завантажень.
Деякі функції погано поводяться на нестабільних SMB-шейрах (особливо якщо NAS має «допоміжні» політики opportunistic locking).

Правило: спочатку змонтуйте з CLI. Потім зробіть Proxmox щасливим. Якщо робити навпаки, ви будете звинувачувати GUI за проблему ядра.

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

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

Завдання 1: Переконайтесь, що хостнейм резолвиться так, як ви думаєте

cr0x@server:~$ getent hosts nas01
192.168.50.20   nas01.lab.local nas01

Значення: Вузол резолвить nas01 в 192.168.50.20. Якщо воно резолвиться в стару IP-адресу, ви «аутентифіковуєтесь» проти неправильного хоста і втратите години.

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

Завдання 2: Перевірте доступ до TCP/445 (не гадання)

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

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

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

Завдання 3: Подивіться, які діалекти SMB рекламуватиме сервер

cr0x@server:~$ smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'
Password for [LAB\backupuser]:
        Sharename       Type      Comment
        ---------       ----      -------
        backups         Disk      Proxmox Backups
        isos            Disk      ISO Library
        IPC$            IPC       IPC Service (NAS)
SMB1 disabled -- no workgroup available

Значення: Ми можемо аутентифікуватись і перелічити шейри з використанням SMB3. Рядок «SMB1 disabled» — добра новина.

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

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

cr0x@server:~$ smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'
Password for [LAB\backupuser]:
  .                                   D        0  Wed Dec 25 10:21:11 2025
  ..                                  D        0  Wed Dec 25 10:21:11 2025
  pve01                               D        0  Tue Dec 24 18:02:44 2025

                52403200 blocks of size 1024. 39122432 blocks available

Значення: Аутентифікація і доступ на рівні шейру в порядку. Якщо монтування все одно не вдається, підозрюйте діалект/опції безпеки, форматування облікових даних або особливості CIFS у ядрі.

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

Завдання 5: Спробуйте ручне монтування з явними, нудними опціями

cr0x@server:~$ sudo mkdir -p /mnt/test-backups
cr0x@server:~$ sudo mount -t cifs //nas01/backups /mnt/test-backups -o username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp,iocharset=utf8,nounix,uid=0,gid=0,file_mode=0640,dir_mode=0750
cr0x@server:~$ mount | grep test-backups
//nas01/backups on /mnt/test-backups type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.50.20,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl,rsize=1048576,wsize=1048576,actimeo=1)

Значення: Монтування працює. Це вже багато говорить: kernel CIFS в порядку, мережа в порядку, аутентифікація в порядку. Тепер проблема, ймовірно, у конфігурації Proxmox, збереженні облікових даних або відмінних опціях.

Рішення: Зіставте ваш успішний набір опцій з тим, що використовує Proxmox. Зробіть Proxmox поводитися як ваше ручне монтування.

Завдання 6: Якщо монтування не вдається — негайно читайте журнали ядра

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 09:11:07 2025] CIFS: Attempting to mount //nas01/backups
[Thu Dec 26 09:11:07 2025] CIFS: VFS: \\nas01 Send error in SessSetup = -13
[Thu Dec 26 09:11:07 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Значення: Налаштування сесії аутентифікації зазнало невдачі, а не резолюція шляху. Коли ви бачите «SessSetup», майже завжди це облікові дані, домен, режим безпеки або політика сервера (підпис/обмеження NTLM).

Рішення: Примусово вкажіть vers і sec. Якщо використовується AD, розгляньте Kerberos (sec=krb5) і перевірте синхронізацію часу.

Завдання 7: Перевірте, що Proxmox думає про це сховище

cr0x@server:~$ cat /etc/pve/storage.cfg
cifs: smb-backups
        path /mnt/pve/smb-backups
        server nas01
        share backups
        username backupuser
        domain LAB
        content backup
        options vers=3.0,sec=ntlmssp,iocharset=utf8,nounix

Значення: Proxmox зберігає визначення тут. Якщо options відсутні, Proxmox може використовувати небажані значення за замовчуванням.

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

Завдання 8: Активуйте сховище і спостерігайте точну помилку

cr0x@server:~$ sudo pvesm status
Name         Type     Status           Total            Used       Available        %
local        dir      active       24545689600      7512332288     17033357312   30.60%
smb-backups  cifs     inactive              0               0               0    0.00%
cr0x@server:~$ sudo pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Значення: Proxmox не може змонтувати, навіть якщо ваше ручне тестове монтування працювало (або ви ще не тестували вручну).

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

Завдання 9: Прослідкуйте спробу монтування (так, за допомогою strace)

cr0x@server:~$ sudo strace -f -o /tmp/pvesm.strace pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
cr0x@server:~$ tail -n 30 /tmp/pvesm.strace
execve("/usr/sbin/mount.cifs", ["mount.cifs", "//nas01/backups", "/mnt/pve/smb-backups", "-o", "username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp"], 0x7ffd0a1c2c90 /* 18 vars */) = 0
...
write(2, "mount error(13): Permission de"..., 39) = 39

Значення: Proxmox викликає mount.cifs без вашого повного набору опцій. Відсутність nounix, iocharset, UID/GID тощо іноді має значення; іноді це лише змінює спосіб презентації дозволів після монтування.

Рішення: Додайте відсутні опції до визначення сховища Proxmox. Не покладайтеся на значення за замовчуванням між оновленнями ядра.

Завдання 10: Використовуйте файл облікових даних (і виправте його дозволи)

cr0x@server:~$ sudo install -d -m 0700 /root/.cifs
cr0x@server:~$ sudo bash -c 'cat > /root/.cifs/nas01-backups.cred <

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

Рішення: Віддавайте перевагу файлу облікових даних і для Proxmox (залежно від операційної моделі). Принаймні — припиніть вставляти паролі в командний рядок.

Завдання 11: Перевірте зсув годин (в Kerberos середовищах це карають)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 09:25:41 UTC
           Universal time: Thu 2025-12-26 09:25:41 UTC
                 RTC time: Thu 2025-12-26 09:25:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Час синхронізований. Якщо ви використовуєте sec=krb5 і годинник відстає, аутентифікація може падати у вигляді «Доступ заборонено».

Рішення: Якщо час не синхронізовано — виправте NTP до того, як продовжите налагодження у Kerberos-середовищі.

Завдання 12: Перевірте політику на стороні сервера (підпис/шифрування)

cr0x@server:~$ sudo modinfo cifs | head
filename:       /lib/modules/6.2.16-3-pve/kernel/fs/smb/client/cifs.ko
license:        GPL
description:    VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
author:         Steve French

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

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

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

cr0x@server:~$ sudo touch /mnt/test-backups/.pve-write-test
cr0x@server:~$ echo $?
0
cr0x@server:~$ sudo mkdir -p /mnt/test-backups/.pve-mkdir-test
cr0x@server:~$ ls -ld /mnt/test-backups/.pve-mkdir-test
drwxr-x--- 2 root root 0 Dec 26 09:27 /mnt/test-backups/.pve-mkdir-test

Значення: Змонтовані облікові дані можуть записувати і створювати каталоги. Якщо резервні копії Proxmox потім провалюються, ви менш імовірно будете ганятися за привидами ACL.

Рішення: Якщо тут ви отримуєте «Доступ заборонено», ваша проблема — авторизація (ACL шейру / файлової системи), а не механіка монтування.

Завдання 14: Подивіться реальні прийняті опції монтування

cr0x@server:~$ sudo findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/test-backups
//nas01/backups /mnt/test-backups cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,gid=0,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl

Значення: Це — істина: які опції ядро прийняло. Якщо ви вказали опцію, а її немає тут — її не застосували.

Рішення: Використовуйте вивід findmnt для конфігурації Proxmox і документування очікувань експлуатації.

Завдання 15: Якщо шейр на Samba — підтвердьте, що сервер бачить вашого користувача (серверна валідація)

cr0x@server:~$ ssh admin@nas01 'sudo smbstatus -b | head'
Samba version 4.17.12
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------
24188   backupuser   domain users  192.168.50.11 (ipv4:192.168.50.11:54132)  SMB3_11           -                    partial

Значення: Сервер бачить вашу сесію. Якщо сервер ніколи не бачить її, відмова відбувається до завершення аутентифікації (діалект/безпека, фаєрвол тощо).

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

Параметри монтування, що важливі (і ті, що брешуть)

Опції монтування CIFS — це місце, де добрі наміри проходять аудит. Хитрість у тому, щоб вибрати невеликий набір явних опцій і трактувати їх як контракт API.

Базовий набір: зробіть це явним

Для більшості Proxmox→NAS налаштувань, що використовують локальних користувачів або AD з NTLMSSP, починайте з:

vers=3.0 (або 3.1.1, якщо ви впевнені, що обидві сторони це підтримують стабільно)
sec=ntlmssp (або sec=krb5 для Kerberos-середовищ)
iocharset=utf8
nounix (часто зменшує дивну поведінку з дозволами/власністю, якщо ви справді не використовуєте Unix extensions)
uid=0,gid=0 (або обліковий запис сервісу на хості Proxmox, якщо хочете подання власника, що не root)
file_mode=0640,dir_mode=0750 (шар презентації; все ще корисно)

Чому так часто nounix? Тому що SMB «Unix extensions» і POSIX-мепінг можуть бути мінним полем сумісності серед постачальників NAS і версій Samba. Якщо ваш NAS рекламує напіввідтворені POSIX semantics, Linux в це повірить, і тоді ви отримаєте поведінку дозволів, яка змусить вас сумніватися в кар’єрі.

Вибір діалекту: `vers=` не опціональний у продакшені

Так, клієнт може автоматично узгоджувати. Ні, не покладайтесь на це для сховищ Proxmox.

Симптом: «Доступ заборонено» після оновлення або після зміни політики NAS.
Причина: змінено за замовчуванням перевагу діалекту, відключено SMB1 або змінено політику підпису SMB3.
Виправлення: зафіксуйте vers=3.0 (або 3.1.1) і рухайтесь далі з вашими завданнями.

Режим безпеки: `sec=` — там ховається політика підприємства

Типові опції:

sec=ntlmssp: широко сумісний, досі поширений, але іноді обмежений.
sec=krb5: Kerberos, найкращий вибір в AD-середовищах, якщо ви можете управляти keytab-ами та синхронізацією часу.

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

Підпис і шифрування: невідповідність політики може виглядати як відмова в доступі

Залежно від ядра і сервера, вам можуть знадобитися опції типу:

seal (шифрування SMB)
sign (підпис увімкнений) або примусове виконання на сервері

Це не завжди потрібно. Часто це вимога політики, коли шейр містить чутливі резервні копії.

Відображення UID/GID: монтування може вдаватися, але бути «Доступ заборонено» пізніше

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

SMB не природньо «ставати Linux». Власність і режими мапуються. Якщо сервер відкриває ACL, які погано конвертуються, клієнт покаже дозволи, що не відображають реальність. Або навпаки.

Рекомендація:

Якщо NAS — просто глупа ціль для резервних копій, віддавайте перевагу nounix і керуйте правами на рівні шейру/ACL.
Якщо вам потрібна POSIX-семантика (спільні домашні каталоги, робота багатьох користувачів), використовуйте Samba з правильно налаштованими Unix extensions і тестуйте ретельно. Не вважайте, що ваш постачальник NAS зробив це правильно.

Одна коротка жартівлива ремарка (1 з 2)

SMB «Доступ заборонено» як корпоративне запрошення в календар: воно не скаже, що саме не так, лише повідомить, що ваш вечір зник.

Облікові дані проти авторизації: ACL шейру, NTFS ACL та особливості NAS

«Правильні облікові дані» ≠ «вам дозволено робити цю дію». SMB робить чітке розділення:

Аутентифікація: доведіть, хто ви (пароль/Kerberos/NTLM).
Авторизація: визначте, до чого маєте доступ (права шейру + дозволи файлової системи/ACL).

Права шейру проти прав файлової системи

Багато NAS-систем реалізують два шари:

Права на рівні шейру: хто може підключитися до //server/share.
ACL файлової системи: що можна робити всередині (створювати, видаляти, перейменовувати).

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

Формат домену: `DOMAIN\user` проти `user@domain`

SMB-стеки різні. Дехто любить LAB\backupuser. Дехто — backupuser@lab.local. Linux mount.cifs зазвичай хоче username= і domain= (або вбудований домен у username).

Практичне правило: використовуйте той же формат, що вдався з smbclient, а потім транслюйте його в опції монтування.

Гостьовий доступ і «map to guest» поведінка

Деякі конфіги Samba/NAS дозволяють гостьовий доступ, деякі явно забороняють. Якщо клієнт випадково спробує гостя або анонімну авторизацію (порожній username, неправильне відображення домену), ви можете отримати:

успішне підключення, але доступ лише для читання, або
немедичну відмову в доступі.

Зафіксуйте облікові дані явно. Уникайте думки «він просто використає мого залогіненого користувача» на вузлі Proxmox.

Kerberos в середовищах Proxmox

Якщо ви монтуєте з доменно приєднаного Linux-хоста з keytab, Kerberos — міцний вибір. Але це операційно суворе:

Синхронізація часу має бути коректною.
DNS має бути коректним.
SPN має існувати і відповідати імені сервера, яке ви використовуєте.

Помилки Kerberos можуть деградувати до повідомлень про відсутність доступу. Якщо ви використовуєте sec=krb5, дотримуйтесь передумов.

Три корпоративні міні-історії (бо ви це проживете)

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

Команда мала Proxmox-кластер, що робив резервні копії на центральний NAS по SMB. Сховище додали в GUI, воно монтувалось, і резервні копії працювали місяцями. Всім стало комфортно.

Потім відділ безпеки запровадив політику AD, щоб поетапно відключити NTLM. Вони надіслали лист. Він потрапив туди, куди потрапляють політичні листи: те саме місце, де зберігаються «обов’язкові тренінги» і «веселі командні заходи».

Одного вівторка ранком резервні копії почали падати з mount error(13): Permission denied. Інженер on-call виконав очікувану хореографію: скинув пароль, переписав пароль, спробував інший акаунт. Та сама відмова. Proxmox звинуватили. NAS звинуватили. Мережу звинуватили. Час ненадовго звинуватили, бо час завжди підозрюваний у розподілених системах.

Виявилось, що облікові дані були правильні. Аутентифікація відхилялась, бо NTLM більше не дозволений для цього класу акаунтів. Монтуванню потрібен був Kerberos: sec=krb5, keytab і стабільний DNS.

Хибне припущення було не в «пароль неправильний». Хибне припущення було в тому, що «політики аутентифікації не змінюються під має працюючих систем». Вони змінюються. Тихо. За розкладом.

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

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

Потім настав день відновлення. Відновлення VM іноді падало з симптомами корупції: відсутні шматки, невідповідності контрольних сум на рівні застосунку і випадкові «stale file handle»-подібні поведінки. Шейр не втрачав дані; поведінка клієнта повертала непослідовні читання під навантаженням запису.

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

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

У іншій компанії SRE-команда мала політику: кожне віддалене монтування файлоcистеми має бути відтворюване однією задокументованою CLI-командою, і кожне монтування має зафіксувати явний SMB-діалект і режим безпеки. Нудно. Люди скаржилися. Політика лишилася.

Під час апгрейду Proxmox частина вузлів почала падати CIFS-монти. GUI повідомлення було, як завжди, «Доступ заборонено». Різниця була в тому, що команда вже мала «відомі робочі» команди монтування і виводи findmnt з доапгрейдного стану.

Вони порівняли опції, що використовувалися до/після зміни, і виявили, що один вузол відхилився: він покладався на значення за замовчуванням і узгодив інший діалект через зміни політики на NAS. Вони виправили конфіг сховища, зафіксувавши vers=3.0 і режим безпеки, потім повторили задокументований CLI-тест монтування. Готово.

Нудна практика. Швидке відновлення. Усі повернулися до того, щоб вдавати, ніби їм подобаються вікна змін.

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

Цей розділ різкий, бо продакшн — різкий.

1) Симптом: «Доступ заборонено», але `smbclient -L` працює

Причина: монтування використовує інший діалект/безпеку, ніж smbclient, або Proxmox передає менше опцій, ніж ваш тест.
Виправлення: зафіксуйте vers=3.0 і sec=ntlmssp (або krb5) в options сховища Proxmox. Перевірте з strace і findmnt.

2) Симптом: ручне монтування працює від root, але резервні копії Proxmox падають з помилками доступу

Причина: авторизація всередині шейру: ACL файлової системи забороняє create/write/rename у шляху, який використовує Proxmox, або NAS примушує «тільки admin» операції.
Виправлення: протестуйте write/create/delete на змонтованому шляху; виправте ACL шейру і підлеглу файлову ACL. Не прикрасьте це лише file_mode.

3) Симптом: вчора працювало; сьогодні «Доступ заборонено» після оновлень

Причина: змінився за замовчуванням опцій або переговору діалекту; сервер відключив нижчі версії SMB; посилили політику NTLM.
Виправлення: зафіксуйте vers і sec. Якщо NTLM вимкнули — перейдіть на Kerberos або знову ввімкніть NTLM (за дозволом команди безпеки).

4) Симптом: «Доступ заборонено» лише при використанні hostname, а IP працює

Причина: SPN / DNS / політика залежна від імені (Kerberos очікує hostname), або ви резолвитесь в неправильний хост.
Виправлення: виправте DNS, перевірте getent hosts, і для Kerberos використовуйте канонічне ім’я, що відповідає SPN сервера.

5) Симптом: додавання сховища через GUI Proxmox не вдається, але CLI монтування працює

Причина: конфіг Proxmox не містить необхідних опцій, або він зберігає облікові дані інакше, ніж ваш CLI-тест.
Виправлення: додайте сховище через CLI або обережно відредагуйте /etc/pve/storage.cfg; перевірте з pvesm activate і strace, щоб побачити точний виклик монтування.

6) Симптом: можете читати, але не записувати

Причина: шейр лише для читання для цього користувача, або підлеглий ACL блокує запис/створення/видалення.
Виправлення: використайте smbclient для спроби запису, і тестуйте на монтованому шляху за допомогою touch/mkdir. Виправляйте серверні дозволи, а не косметику на клієнті.

7) Симптом: «Доступ заборонено», коли пароль містить спеціальні символи

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

8) Симптом: періодичні проблеми з правами під навантаженням

Причина: поведінка блокувань/oplocks/leases, баги NAS або опції кешування, що не відповідають вимогам консистентності навантаження.
Виправлення: поверніться до консервативних опцій; переконайтесь, що NAS підтримує важке одночасне записування; розгляньте NFS для Linux-орієнтованих навантажень, якщо середовище дозволяє.

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

Контрольний список A: Отримати надійне монтування на вузлі Proxmox (CLI спочатку)

Резолвіть ім’я сервера: getent hosts nas01. Якщо неправильно — виправте DNS або тимчасово використайте IP.
Перевірте досяжність: nc -vz nas01 445. Якщо заблоковано — виправте мережу/фаєрвол.
Підтвердіть облікові дані і видимість шейру: smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'.
Переконайтесь, що можете доступитись до шейру: smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'.
Створіть файл облікових даних з дозволами 0600.
Змонтируйте з зафіксованими опціями (vers, sec, nounix, iocharset, UID/GID і режими).
Протестуйте write/create/delete у шляху монтування.
Збережіть вивід findmnt як «відомо робочий» еталон.

Контрольний список B: Змусити Proxmox використовувати ту саму поведінку монтування

Перегляньте /etc/pve/storage.cfg для запису CIFS-сховища.
Встановіть явні options, щоб відповідали успішному CLI-монтуванню: діалект, режим безпеки та будь-які флаги сумісності.
Запустіть pvesm activate <storageid>.
Якщо не вдається — відразу запустіть dmesg -T | tail -n 50.
Використайте strace на pvesm activate, щоб підтвердити, які опції передають до mount.cifs.
Підтвердьте, що монтування є під /mnt/pve/<storageid> з findmnt.
Запустіть невелику резервну роботу Proxmox, щоб валідувати поведінку робочого навантаження (запис + шаблони перейменування).

Контрольний список C: Трек Kerberos (коли NTLM заборонено)

Перевірте синхронізацію часу: timedatectl має показувати synchronized.
Перевірте правильність DNS для імені SMB-сервера.
Отримайте і встановіть keytab для service principal (операційно: координуйтеся з AD).
Монтуйте з sec=krb5 і використовуйте правильне ім’я сервера (те, що відповідає SPN).
Якщо аутентифікація падає — вивчайте журнали ядра; помилки Kerberos часто виглядають як проблеми доступу.

Парафразована ідея (цитата для надійності): відомий принцип Gene Kranz з центру управління місіями — «будь строгим і компетентним». Цей підхід ідеально підходить для монтувань сховищ.

Одна коротка жартівлива ремарка (2 з 2)

Нічого не каже «підприємницьке збереження» як протокол з назвою «Simple», що потребує 14 опцій для базового монтування.

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

1) Чому Proxmox каже «Доступ заборонено», коли облікові дані правильні?

Бо помилка часто відображає авторизацію (ACL шейру/NTFS ACL), політику (NTLM відключено, підпис потрібний) або невдачу переговору діалекту/безпеки, а не лише правильність пароля.

2) Чи завжди треба вказувати `vers=3.0`?

У продакшені — так: встановіть явний діалект, який ви знаєте, що сервер підтримує. Якщо у вас сучасний NAS/Windows/Samba, SMB3 — правильна база. Якщо сервер надійно підтримує SMB3.1.1, можна використовувати його, але важливіше стабільність, ніж теоретичні оновлення.

3) У чому різниця між `sec=ntlmssp` і `sec=krb5`?

ntlmssp використовує NTLM-основану автентифікацію і широко сумісний. krb5 використовує Kerberos і зазвичай переважний в AD-середовищах із суворим контролем політик, але вимагає синхронізації часу і коректного DNS/SPN.

4) Я можу перелічити шейр, але не можу створювати файли. Чому?

Права на рівні шейру дозволяють підключитися, але файлові ACLи можуть блокувати запис. Тестуйте touch на монтованому шляху і виправляйте ACL на сервері. file_mode на клієнті не замінить серверну авторизацію.

5) Чи виправляють `file_mode` і `dir_mode` права?

Вони переважно впливають на те, як дозволи показуються на Linux-клієнті. Вони не надають магічно права запису, якщо сервер їх відхиляє.

6) Чому допомагає файл облікових даних?

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

7) Proxmox монтує під `/mnt/pve`. Чи можна монтувати в інше місце?

Proxmox очікує керувати сховищами під /mnt/pve/<storageid>. Ви можете монтувати вручну в інше місце для тестів, але визначення сховища має відповідати конвенціям Proxmox, якщо у вас немає вагомої причини відхилитись.

8) Чи підходить CIFS для резервних копій Proxmox?

Може бути. Але ставтесь до нього як до мережевої залежності з політичними змінами та багами прошивки NAS. Якщо ви контролюєте обидві сторони і середовище Linux-орієнтоване, NFS часто має менше сюрпризів з ідентифікацією/ACL. Якщо ви в Windows/AD середовищі — SMB з Kerberos є робочим корпоративним шляхом.

9) Який найкращий сигнал для налагодження?

dmesg відразу після помилки. Воно часто каже, чи відмова сталася під час сесійного налаштування, tree connect або пізніших перевірок авторизації.

Висновок: практичні наступні кроки

Коли Proxmox CIFS каже «Доступ заборонено», припиніть сперечатись, чи пароль правильний, і почніть збирати докази. Доведіть досяжність мережі, доведіть доступ до шейру з smbclient, зафіксуйте SMB-діалект і режим безпеки, а потім змусьте Proxmox використовувати точно ті ж опції монтування, що працювали в CLI.

Наступні кроки, що реально рухають ситуацію:

Запустіть smbclient проти точного шейру і користувача, з яким ви збираєтесь монтувати.
Зробіть одне ручне монтування з явними vers і sec, потім перевірте з findmnt.
Протестуйте операції запису/створення у шляху монтування — не припускайте.
Змусіть Proxmox співставити ваш відомо-робочий набір опцій і валідуйте з pvesm activate та dmesg.
Документуйте остаточний набір опцій монтування. Значення за замовчуванням змінюються. Ваш майбутній я не згадає, чому це працювало.

Схожі статті

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