Proxmox “qemu-img: Could not create”: права доступу, шляхи та виправлення файлової системи, які справді працюють

Що насправді означає ця помилка (і чого вона не означає)

Коли Proxmox створює диск VM, зазвичай він викликає qemu-img (для образів у файлах, як qcow2/raw), або просить інструменти сховища створити блочний пристрій (ZFS zvol, LVM логічний том, Ceph RBD). Якщо крок створення не вдається, ви часто побачите:

• “qemu-img: Could not create …”
• “Permission denied” (якщо пощастить — явне)
• “No such file or directory” (проблема шляху або монтовання)
• “Read-only file system” (файлова система або NFS експорт змонтовані лише для читання)
• “No space left on device” (блоки даних, метадані, іноді inode, метадані тонкого пулу або квоти)

Ось що це зазвичай не означає:

• Не «випадкова баги Proxmox». Майже завжди це детермінована проблема.
• Не вирішується перезапуском pvedaemon «просто так». Перезапуск може дати відчуття продуктивності, однак це рідко лікує причину.
• Не вирішується chmod 777 на всьому (якщо ваша мета — створити майбутні інциденти, то це працює).

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

1. Де Proxmox намагається створити диск?
2. Хто його записує (процес/користувач/мапінг UID) і чи має права?
3. Що з бекендом сховища (змонтовано, доступно для запису, здорове, є місце, підтримує потрібні можливості)?

Одна цитата, яка працює в опрації: «Надія — не стратегія.» — General Gordon R. Sullivan. Коли qemu-img відмовляє, надія особливо дорога.

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

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

Перше: підтвердьте цільове сховище та точний шлях/пристрій

Витягніть ідентифікатор сховища та шлях, який намагався створити Proxmox, із журналу задач. Якщо це каталогне сховище, ви побачите щось на кшталт /mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2. Якщо це ZFS/LVM — побачите назву zvol або LV.

Друге: перевірте монтування й можливість запису за одну хвилину

Більшість збоїв «Could not create» — це відсутній монтувальний пункт, монтування що сталося на порожню директорію або файлова система, переведена в режим лише для читання через помилки. Ви можете виявити всі три швидко за допомогою findmnt, mount та маленького тесту на запис.

Третє: перевірте місце правильно (дані, inode, метадані тонкого пулу, квоти)

«Диск заповнений» — не одне поняття. Ідеться про: блоки, inode, ZFS квоту/refquota, LVM thin метадані, проектні квоти, NFS користувацькі квоти. Перевіряйте відповідні лічильники для вашого типу сховища.

Четверте: перевірте права й ідентичність (UID/GID, root_squash, ACL)

На локальних файлових системах Proxmox зазвичай пише як root (через pvedaemon/pveproxy, що викликають інструменти). На NFS/CIFS це може дивно поводитися: root стає nobody, спадкування ACL робить «корисний», або SMB мапить вас на інший користувач. Коли пахне правами, перевірте з namei, stat і тестом на запис із хоста.

П’яте: перевірте конфіг плагіна сховища й типи вмісту

Неправильні типи вмісту (наприклад, «VZDump backup only», а ви намагаєтесь зберегти образи), неправильний шлях, неправильна назва пулу або застаріла конфігурація сховища на вузлі кластера — усе це проявиться як помилка створення.

Цікаві факти й контекст (чому це повторюється)

• Факт 1: qemu-img з’явився раніше за Proxmox і використовується широко в стеку віртуалізації. Proxmox часто лише передавач повідомлення.
• Факт 2: Directory-сховище Proxmox вводить в оману простотою: це просто шлях у файловій системі, отже монтування та права — ваша відповідальність за визначення.
• Факт 3: NFS «root_squash» існує саме для того, щоб запобігти віддаленому root стати root на сервері. Це також одна з трьох головних причин, чому створення дисків на NFS не вдається.
• Факт 4: LVM-thin може вичерпати саме метадані, при цьому має багато простору для даних. Повідомлення про помилку часто брехливо вказує, що саме заповнено.
• Факт 5: ZFS може відмовляти у створенні через квоти, конфлікти резервувань або пул, який формально онлайн, але не має доступного простору через фрагментацію та налаштування recordsize.
• Факт 6: Ext4 і XFS поводяться по-різному при «заповненні»: виснаження inode частіше трапляється на ext4 при роботі з багатьма маленькими файлами; XFS може несподівано стикатися з проектними квотами.
• Факт 7: AppArmor може блокувати операції QEMU навіть коли Unix-права виглядають коректними, особливо для нестандартних точок монтування, які не охоплені профілями.
• Факт 8: Відсутнє монтування може бути невидимим, якщо точка монтування існує як каталог. Ви записуватимете в локальну кореневу файлову систему і помітите це лише коли вона заповниться. Це спричинило реальні аварії в поважних компаніях.

Діагностика, керована завданням: команди, виводи, рішення

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

Завдання 1: Прочитайте журнал задач Proxmox, щоб знайти справжню ціль

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve1:0000A1B2:0001C3D4:676D1A2B:qmcreate:101:root@pam:
error: unable to create VM 101 - qemu-img: Could not create '/mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2': Permission denied

Що це означає: Невдалий шлях вказано явно. Це золото. Якщо повідомлення не показує шлях, подивіться повний журнал задач у GUI або в /var/log/pve/tasks.

Рішення: Скопіюйте точний шлях/ідентифікатор сховища. Усе інше залежить від цього.

Завдання 2: Підтвердіть, яку конфігурацію сховища використовує Proxmox

cr0x@server:~$ pvesm status
Name     Type     Status     Total      Used      Available  %
local    dir      active     98.00GB    12.10GB    80.90GB   12.35%
fastssd  dir      active     1.80TB     1.22TB     0.58TB    67.78%
zfspool  zfspool  active     3.50TB     2.10TB     1.40TB    60.00%

Що це означає: Proxmox вважає fastssd активним. Це не гарантує, що воно змонтоване або доступне для запису.

Рішення: Продовжуйте перевірки. «Active» — необхідна, але не достатня умова.

Завдання 3: Перевірте, що монтування реальне (а не порожня директорія)

cr0x@server:~$ findmnt -T /mnt/pve/fastssd
TARGET           SOURCE        FSTYPE OPTIONS
/mnt/pve/fastssd /dev/sdb1     ext4   rw,relatime,errors=remount-ro

Що це означає: Добре: це реальне монтування з /dev/sdb1. Якщо цей вивід порожній — ви записуєте в звичайну директорію локальної файлової системи.

Рішення: Якщо не змонтовано — виправте fstab/systemd mount і змонтируйте перед будь-якими іншими діями.

Завдання 4: Перевірте, чи не переключилася файловая система в режим тільки для читання

cr0x@server:~$ mount | grep -E '/mnt/pve/fastssd| / '
/dev/sdb1 on /mnt/pve/fastssd type ext4 (ro,relatime,errors=remount-ro)
/dev/mapper/pve-root on / type ext4 (rw,relatime,errors=remount-ro)

Що це означає: Сховище змонтовано як ro. Proxmox не зможе створити нічого, і помилка може показувати «Permission denied» або «Read-only file system» залежно від коду помилки.

Рішення: Перестаньте намагатися створювати диски. Розслідуйте причину перемикання файлової системи, запустіть fsck (для ext4) або виправте проблему обладнання, потім перемонтуйте у rw.

Завдання 5: Зробіть мінімальний тест запису з хоста (єдина істина)

cr0x@server:~$ touch /mnt/pve/fastssd/.pve-write-test && echo OK
touch: cannot touch '/mnt/pve/fastssd/.pve-write-test': Read-only file system

Що це означає: Це не проблема прав Proxmox. Це «файлова система не записувана».

Рішення: Спочатку виправте стан монтування/файлової системи. Права не мають значення, поки записи не вдаються.

Завдання 6: Перевірте місце й inode (так, обидва)

cr0x@server:~$ df -h /mnt/pve/fastssd
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.8T     0 100% /mnt/pve/fastssd

cr0x@server:~$ df -i /mnt/pve/fastssd
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1      122M     1.1M    121M    1% /mnt/pve/fastssd

Що це означає: Блоки заповнені, inode в порядку. Якщо б блоки були вільні, а inode — 100%, ви б побачили схожі помилки створення.

Рішення: Звільніть місце або розширте файлову систему. Не «пробуйте ще раз» — це не допоможе.

Завдання 7: Підтвердіть власність каталогу й права проходження всього шляху

cr0x@server:~$ namei -l /mnt/pve/fastssd/images/101
f: /mnt/pve/fastssd/images/101
drwxr-xr-x root root /
drwxr-xr-x root root mnt
drwxr-xr-x root root pve
drwxr-x--- root root fastssd
drwxr-xr-x root root images
drwx------ 100000 100000 101

Що це означає: Директорія VM належить UID 100000, що часто буває при спільному монтуванні або при використанні user namespace. Також зверніть увагу, що fastssd має drwxr-x---; лише root і група root можуть проходити.

Рішення: Якщо Proxmox пише як root, root може проходити; але якщо якийсь компонент скидає привілеї або використовує мапінг ідентичностей, потрібно виправити власність/ACL. Якщо це NFS з root_squash, root не буде root.

Завдання 8: Відтворіть як «root» і правильно інтерпретуйте помилки прав

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/fastssd/images/101/.root-test
touch: cannot touch '/mnt/pve/fastssd/images/101/.root-test': Permission denied

Що це означає: Якщо навіть локальний root не може писати, то або:

• це віддалена файлова система, що мапить root у nobody (NFS root_squash),
• ACL забороняють запис,
• є незмінні атрибути (immutable),
• або файлова система змонтована з обмежувальними опціями.

Рішення: Для NFS/CIFS перевірте опції експорту/монтування. Для локальної FS перевірте ACL та атрибути.

Завдання 9: Перевірте ACL та immutable-прапори, коли права «виглядають добре»

cr0x@server:~$ getfacl -p /mnt/pve/fastssd/images/101 | sed -n '1,25p'
# file: /mnt/pve/fastssd/images/101
# owner: 100000
# group: 100000
user::rwx
group::---
other::---

cr0x@server:~$ lsattr -d /mnt/pve/fastssd/images/101
-------------------P-- /mnt/pve/fastssd/images/101

Що це означає: ACL тут повністю забороняють групі й іншим. Це нормально, якщо писальник відповідає власникові. Але якщо NFS стискає root у nobody, це не збігається. Атрибути виглядають нормально (немає прапора i незмінності).

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

Завдання 10: Перевірте опції монтування NFS і симптоми root squashing

cr0x@server:~$ findmnt -T /mnt/pve/nfs-store -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET            SOURCE                    FSTYPE OPTIONS
/mnt/pve/nfs-store 10.0.20.10:/exports/pve nfs4   rw,relatime,vers=4.1,sec=sys,clientaddr=10.0.20.21

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/nfs-store/.nfs-root-test
touch: cannot touch '/mnt/pve/nfs-store/.nfs-root-test': Permission denied

root@server:~# stat -c '%u %g %n' /mnt/pve/nfs-store
65534 65534 /mnt/pve/nfs-store

Що це означає: UID/GID 65534 — класичне «nobody/nogroup» мапування. Це свідчить про root_squash або анонімне мапування на NFS-сервері.

Рішення: Виправте експорти NFS: встановіть коректну власність на сервері відповідно до мапованого UID або налаштуйте опції експорту (обережно), щоб Proxmox міг писати.

Завдання 11: Перевірте здоров’я LVM-thin (дані vs метадані)

cr0x@server:~$ lvs -a -o +devices,lv_size,data_percent,metadata_percent,lv_attr vg0
  LV               VG  Attr       LSize   Data%  Meta%  Devices
  thinpool         vg0 twi-aotz--  900.00g  72.10  99.85 /dev/sdc3(0)
  thinpool_tmeta   vg0 ewi-aotz--    8.00g                 /dev/sdc3(230400)
  thinpool_tdata   vg0 ewi-aotz--  900.00g                 /dev/sdc3(4096)

Що це означає: Дані на 72%, метадані майже заповнені. Створення завершиться невдачею, хоча «місце» на перший погляд є.

Рішення: Розширте метадані тонкого пулу (і налаштуйте моніторинг). Не продовжуйте просто повторювати спроби — ви лише засмітите журнали.

Завдання 12: Перевірте стан ZFS-пулу та обмеження квот

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint
NAME              USED  AVAIL  REFER  MOUNTPOINT
rpool             120G   80G    96K   /rpool
rpool/data        110G   80G    96K   /rpool/data
rpool/data/vm-101-disk-0  50G  0B     50G   -

cr0x@server:~$ zfs get -H -o property,value quota,refquota rpool/data
quota    none
refquota none

Що це означає: Конкретний zvol показує 0B доступного, бо це том, і цей вивід може вводити в оману. Важливіший сигнал — доступність пулу/дейтасету й квоти/резервування. Якщо AVAIL низький або встановлені квоти, створення zvol може не вдаватися.

Рішення: Якщо пул здоровий, але AVAIL низький або встановлені квоти, звільніть місце або налаштуйте quota/refquota/reservation. Також перевірте ashift і фрагментацію, якщо ви постійно працюєте на межі.

Завдання 13: Переконайтеся, що типи вмісту Proxmox налаштовані правильно (помилка, що схожа на «права»)

cr0x@server:~$ grep -A4 -n '^dir: fastssd' /etc/pve/storage.cfg
12:dir: fastssd
13:        path /mnt/pve/fastssd
14:        content vztmpl,backup
15:        prune-backups keep-last=3

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

Рішення: Додайте images у типи вмісту (і, можливо, iso), якщо це сховище призначене для дисків VM.

Завдання 14: Перевірте, що шлях сховища існує на цьому вузлі (дріфт у кластері)

cr0x@server:~$ ls -ld /mnt/pve/fastssd
ls: cannot access '/mnt/pve/fastssd': No such file or directory

cr0x@server:~$ pvecm status | sed -n '1,20p'
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Що це означає: У кластері /etc/pve/storage.cfg спільний, але монтування не синхронізується автоматично. Вузол може мати конфігурацію сховища, але не мати його фізично.

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

Завдання 15: Перевірте, чи AppArmor не блокує QEMU для нестандартних точок монтування

cr0x@server:~$ dmesg | tail -n 20
[12345.678901] audit: type=1400 audit(1735212345.123:456): apparmor="DENIED" operation="open" profile="libvirt-2d7c3a1e-..." name="/mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2" pid=3210 comm="qemu-img" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0

cr0x@server:~$ aa-status | sed -n '1,20p'
apparmor module is loaded.
45 profiles are loaded.

Що це означає: Unix-права можуть бути ідеальні, але ви все одно отримаєте «permission denied», якщо AppArmor блокує доступ. Рядок у dmesg — курильний пістолет.

Рішення: Відредагуйте відповідний профіль або забезпечте використання очікуваних шляхів зберігання. «Вимкнути AppArmor» — грубий інструмент; використовуйте його тільки для короткої діагностики, а не як постійне рішення.

Завдання 16: Переконайтеся, що CIFS/SMB монтування не брешуть щодо прав

cr0x@server:~$ findmnt -T /mnt/pve/smb-store -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET             SOURCE                       FSTYPE OPTIONS
/mnt/pve/smb-store  //nas01/proxmox             cifs   rw,relatime,vers=3.0,uid=0,gid=0,dir_mode=0755,file_mode=0644,nounix

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/smb-store/.smb-test && echo OK
touch: cannot touch '/mnt/pve/smb-store/.smb-test': Permission denied

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

Рішення: Виправте права шару шари шару на сервері й налаштування облікових даних; розгляньте NFS для образів VM, якщо хочете менше несподіваних семантик.

Підводні камені залежно від типу сховища: Directory, ZFS, LVM-thin, NFS, CIFS

Directory storage (шлях у файловій системі): найпростіше і тому найпростіше неправильно змонтувати

Directory storage — буквально «пишіть файли сюди». Це означає, що qemu-img створює qcow2/raw файли під path/images/<vmid>. Невдачі походять від:

• Відсутнього монтування; точка монтування існує як порожня директорія
• Файлова система стала лише для читання після помилок
• Немає вільного місця / виснаження inode
• Невідповідність прав/ACL на директорії VMID або їхніх батьків
• AppArmor відмовляє доступ до нестандартних точок монтування

Рекомендація: для directory-сховища використовуйте виділену точку під /mnt/pve/<storageid> і переконайтеся, що її монтує systemd, а не «хтось монтує вручну після перезавантаження». Люди ненадійні під час завантаження.

ZFS zvol: швидко, надійно й алергічно до поганих практик заповнення

VM-диски на ZFS часто — це zvol. Помилки створення виникають коли:

• У пулу мало доступного простору (ZFS потребує «повітря»; 95% використання — запрошення до проблем)
• Дейтасет має квоти/refquota/reservation, що заважають створенню
• Пул деградований або призупинений (I/O помилки поширюються дивно)
• Конфлікт імен (залишився застарілий zvol від попереднього невдалого створення)

Практична порада: ставтеся до ZFS як до живої системи. Моніторьте простір, регулярно scrub-те і не поводьтеся з ним як з «просто ще одним ext4 диском».

LVM-thin: коли метадані — це ваш справжній диск

LVM-thin добре працює, поки не працює. Класична помилка «Could not create» виникає, коли метадані тонкого пулу заповнені. Дані можуть бути на 40%, а метадані — на 100% — і створення припиняється.

Також звертайте увагу на:

• Тонкий пул, що став у режим тільки для читання через помилки
• Недостатньо вільного простору в VG для розширення метаданих
• Налаштування discard/TRIM, що взаємодіють з підлеглим сховищем

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

NFS: театральність прав, головна роль — root_squash

NFS часто використовують для спільного сховища Proxmox, і він постійно приносить «Permission denied». Root squashing, невідповідність ACL або експорти, що змонтовані на одному вузлі, але не на іншому — основні винуватці.

Якщо використовуєте NFS для образів VM, переконайтеся, що:

• Експорт призначений для цього (низька затримка, правильна синхронізація)
• UID/GID мапінг продуманий і документований
• Опції монтування узгоджені на всіх вузлах

CIFS/SMB: підходить для ISO та бекапів; образи VM — лотерея

SMB можна змусити працювати, але семантика відрізняється. Блокування, oplocks, мапінг прав і «виглядає доступним, але не працює» — регулярні сюжети. Якщо повинні використовувати SMB, тестуйте qemu-img create під навантаженням, а не лише touch.

Модель прав у Proxmox: хто пише що й куди

Коли ви натискаєте кнопки в UI, запит йде через демон Proxmox, що працює як root. Крок створення диска зазвичай виконується root на хості. Це означає:

• На локальних файлових системах Unix-права здебільшого не проблема, якщо ви не занадто суворо їх налаштували або не використовували ACL.
• На NFS root може не бути root на сервері. Root_squash перетворює «root» на анонімний UID, який не може створювати файли в директоріях, що належать реальним користувачам.
• На CIFS root може мапитися на користувача шару, що не має прав на запис.
• У кластерних налаштуваннях конфігурація розподілена, але монтування — ні. Вузол A може писати; вузол B — ні; у GUI все виглядає однаково, поки не перестане.

Практичне правило: завжди тестуйте запис з хоста у ту ж саму директорію, яку використовує Proxmox. Якщо touch не вдається — qemu-img також не вдасться. Якщо touch працює, а qemu-img — ні, ви перейшли в область «AppArmor / тип вмісту / підтримка можливостей / специфіка плагіна».

Жарт №2: «Permission denied» — це система, що каже: «Я почув ваше прохання і обираю насильство».

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

1) Симптом: «No such file or directory» для шляху під /mnt/pve/…

Корінна причина: Точка монтування відсутня на цьому вузлі, або сховище не змонтовано, або дерево директорій (images/<vmid>) не створено через попередні помилки.

Виправлення: Створіть точку монтування, забезпечте автоматичне монтування при завантаженні й перевірте через findmnt -T. Потім повторіть створення.

2) Симптом: Proxmox показує сховище «active», але створення відразу зазнає невдачі

Корінна причина: Перевірки статусу сховища можуть бути поверхневими; застаріле монтування або підлегла директорія може все ще виглядати «active».

Виправлення: Перевірте реальність монтування й можливість запису: findmnt + тест touch у точному шляху.

3) Симптом: «Permission denied» на NFS, навіть від root

Корінна причина: NFS root_squash або анонімне мапування UID; права експорту не дозволяють запис мапованому UID.

Виправлення: Узгодьте власність на сервері з мапованим UID/GID або налаштуйте опції експорту та модель безпеки. Перевірте через stat показуючи UID/GID і тест на запис.

4) Симптом: «Read-only file system» раптово на локальному ext4

Корінна причина: ext4 перемонтувався в режим readonly після виявлення помилок файлової системи (часто через проблеми диска або некоректне вимкнення).

Виправлення: Перегляньте логи, заплануйте простій, виконайте fsck на блочному пристрої, виправте апаратні проблеми, потім перемонтуйте rw.

5) Симптом: Достатньо «вільного місця», але не можна створити на LVM-thin

Корінна причина: Метадані тонкого пулу заповнені або пул у стані помилки.

Виправлення: Перевірте lvs metadata_percent. Розширте метадані і налаштуйте моніторинг/авто-розширення.

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

Корінна причина: Монтування або облікові дані відрізняються на вузлах; конфіг сховища спільна, але монтування та секрети — ні.

Виправлення: Уніфікуйте монтування й опції на всіх вузлах. Для NFS/CIFS забезпечте ідентичні юніти mount і файли з обліковими даними.

7) Симптом: «Permission denied», але Unix-права виглядають коректно

Корінна причина: AppArmor відмова, SELinux (рідше в стандартному Proxmox) або ACL.

Виправлення: Перегляньте dmesg на предмет AppArmor denies; відредагуйте профіль або змініть шлях сховища. Перевірте getfacl.

8) Симптом: Падає тільки для qcow2, raw працює (або навпаки)

Корінна причина: Файлова система або опції монтування заважають (наприклад, CIFS «nobrl»/поведінка блокувань), або очікування інструментів не збігаються.

Виправлення: Віддавайте перевагу raw для блочних пристроїв (zvol/LV). Для мережевих шарів тестуйте під реальним навантаженням; перегляньте вибір сховища для образів VM.

9) Симптом: «Could not create» при виборі сховища, яке «лише для бекапів»

Корінна причина: Типи вмісту сховища не включають images.

Виправлення: Оновіть /etc/pve/storage.cfg, щоб додати images для цього сховища (або оберіть правильне сховище).

10) Симптом: «No space left on device», але df показує місце

Корінна причина: Виснаження inode, досягнута квота, проектна квота, метадані тонкого пулу або ZFS квота/refquota/reservation.

Виправлення: Перевірте відповідний лічильник для типу сховища: df -i, ZFS квоти, метадані LVM, інструменти квот.

Три міні-історії з корпоративного життя (як це ламається насправді)

Міні-історія 1: Хибне припущення (active сховище ≠ змонтоване сховище)

Середовище виглядало охайно: невеликий кластер Proxmox, каталогне сховище «fastssd» і кілька нових додатків VM, які потрібно було запустити до обіду. Інженер бачив у UI, що fastssd позначено «active», і припустив, що воно змонтоване й здорове. Розумне припущення. Неправильне.

Один вузол перезавантажився вночі після оновлення ядра. mount-unit не відновився, бо залежав від шляху пристрою, що змінився. Точка монтування директорії все ще існувала, тож усе виглядало нормально. Proxmox намагався створювати образи дисків під /mnt/pve/fastssd — яке тепер було просто директорією у кореневій файловій системі.

Створення іноді падало з qemu-img: Could not create, поки коренева FS поступово заповнювалася. Тим часом інші сервіси почали падати: оновлення пакетів не могли завершитися, логи не могли записуватися, і канал інцидентів наповнився трьома різними «корінними причинами».

Виправлення було боляче простим: налаштували mount unit на використання стабільного ідентифікатора, змонтували файлову систему і прибрали випадково створені часткові образи, що писалися у неправильне місце. Реальне поліпшення — процесне: після інциденту команда додала «findmnt -T цільового шляху» в процедуру триажу сховищ. Це запобігло повторенню через кілька тижнів — бо ту саму помилку спробували ще раз.

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

Інша команда хотіла більше корисного простору у своєму LVM-thin пулі. Вони прочитали достатньо, щоб бути небезпечними, і вирішили зробити метадані «меншими». У перший день все виглядало чудово: більше гігабайтів, менше «відходів», плюсики в щотижневому звіті.

Через кілька місяців платформа почала отримувати спорадичні невдачі при створенні VM. Це було непослідовно й непередбачувано. Помилка була та сама — образливо невтішне «qemu-img could not create» при створенні дисків на тонкому пулі.

Використання даних було в нормі. Пул не був повним. Але метадані були. Знімки, клонування і висока активність з’їли метадані. Коли метадані досягають ліміту, тонке провізування перестає бути «тонким» і стає крихким. Системи не деградували плавно; вони просто перестали створювати нові томи.

Виправили шляхом розширення метаданих і ввімкнення моніторингу. Але справжній урок був культурний: оптимізувати лише видимий показник (вільний простір) ігноруючи метадані — типовий приклад «виграшу в таблиці, втрата в продакшні». Після цього стандартизували розміри створення пулів і налаштували оповіщення за metadata_percent. Не захоплювало — але стало стабільно.

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

Одне підприємство впровадило правило, що звучало майже дитячо: після перезавантаження кожен вузол проходить стандартний «smoke test» сховища. Він перевіряє, що кожна точка монтування Proxmox існує, змонтована й доступна для запису. Навіть створює і видаляє невеликий файл у точній директорії, яку використовує Proxmox.

Під час рутинного вікна технічного обслуговування NFS-сервер оновили. Один експорт повернувся з зміненими політиками: root тепер сквошився, де раніше не сквошився. З точки зору безпеки, зміна виправдана. Операційно — вона означала, що Proxmox більше не може створювати диски на цьому експорті.

Smoke test після перезавантаження впав відразу на кількох вузлах, до того як хтось спробував створити VM. Команда не дізналася про проблему під час клієнтського робочого процесу. Вони виявили її в контрольованому перевірці, виправили мапінг власності експорту і задокументували це.

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

Чеклисти / поетапний план (робіть це, а не магію)

Покроково: коли ви бачите “qemu-img: Could not create”

1. Зафіксуйте точний шлях/пристрій, що падає з журналу задач Proxmox. Не перефразовуйте.
2. Визначте тип сховища: Directory, ZFS, LVM-thin, NFS, CIFS, Ceph. Використовуйте pvesm status і /etc/pve/storage.cfg.
3. Перевірка монтування (directory/NFS/CIFS):
   • findmnt -T <path> має показати source і очікуваний fstype.
   • mount має показати rw (якщо це не навмисно ro).
4. Тест запису у точному каталозі:
   • touch і потім видаліть. Якщо не вдається — зупиніться й виправте це спочатку.
5. Перевірка ємності:
   • Directory: df -h і df -i
   • LVM-thin: lvs data_percent + metadata_percent
   • ZFS: zfs list і zfs get quota,refquota,reservation
6. Перевірка прав:
   • namei -l для повного шляху
   • getfacl якщо використовується ACL
   • На NFS перевірте мапінг UID через stat
7. Перевірка рівня безпеки:
   • dmesg на предмет AppArmor deny
   • aa-status для підтвердження активних профілів
8. Перевірка конфігурації Proxmox:
   • Типи вмісту сховища включають images
   • Сховище увімкнене на вузлі, який створює VM
9. Повторіть спробу один раз після виправлення кореневої причини. Якщо знову не вдається — зафіксуйте логи й ескалюйте методично. Ніякого безладного натискання кнопки.

Операційний чеклист: запобігання повторів

• Монтування визначені зі стабільними ідентифікаторами (UUID або /dev/disk/by-id), а не нестабільні /dev/sdX шляхи.
• Systemd mount юніти або запис у fstab протестовані після перезавантаження.
• Оповіщення на: події перемикання файлової системи в readonly, низьке місце, виснаження inode, метадані LVM thin, заповнення ZFS пулу.
• Уніфіковані опції монтування на всіх вузлах кластера для спільного сховища.
• Невеликий smoke-test сховища після перезавантаження (монтування + запис + видалення) для кожного шляху Proxmox.
• Документовані політики експорту NFS: root_squash, anonuid/anongid, модель власності.

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

1) Чому Proxmox каже «qemu-img could not create», коли реальна проблема — права NFS?

Бо qemu-img — інструмент, що робить створення. NFS відкидає запис, qemu-img звітує про невдачу. Завжди корелюйте з опціями монтування й мапінгом UID.

2) Сховище в Proxmox показує «active» — чи означає це, що воно змонтоване й доступне для запису?

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

3) Який найшвидший спосіб виявити відсутнє монтування vs проблему прав?

findmnt -T <path> плюс touch <path>/.test. Якщо findmnt порожній — проблема в монтуванні. Якщо touch не вдається — читайте точну помилку.

4) Чому root може отримати «Permission denied» на NFS?

Бо на сервері root може бути мапований на анонімний UID (root_squash). Цей UID може не володіти директорією і не мати прав на запис.

5) Чи можна вирішити це chmod 777 на шляху сховища?

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

6) Що робити, якщо помилка трапляється тільки на одному вузлі кластера?

Припустіть, що монтування або облікові дані відрізняються. Перевірте той самий шлях сховища на цьому вузлі через findmnt і тести запису. Конфіг кластера спільний; монтування — ні.

7) Як зрозуміти, що причина — метадані LVM-thin, а не місце на диску?

Перевірте lvs і подивіться на metadata_percent. Якщо він близький до 100% — ви знайшли винуватця.

8) Коли підозрювати AppArmor?

Коли права й тести запису працюють, але qemu-img все ще падає — або коли dmesg містить рядки AppArmor «DENIED», що вказують на шлях диска.

9) Чи підходить CIFS/SMB для дисків VM?

Може працювати, але менш передбачувано ніж NFS через семантику прав і блокувань. Багато команд використовують SMB для ISO/бекапів і тримають образи VM на блочних або NFS-сховищах.

10) Як запобігти «помилці запису в кореневу FS через відсутнє монтування»?

Використовуйте systemd automounts або суворі mount-юніти і подумайте зробити точку монтування недоступною для запису до моменту монтування. Принаймні — налаштуйте оповіщення на несподіваний ріст кореневої FS.

Висновок: кроки, що запобігають повторенню

Помилка «qemu-img: Could not create» не містить містики. Вона повторювана. Це добра новина: повторювані проблеми можна стандартизувати й виправити.

Зробіть наступне, по порядку:

1. Візьміть один невдалий шлях з журналу задач і перевірте його через findmnt та тест запису.
2. Перевірте ємність правильно для вашого типу сховища (блоки, inode, метадані thin, ZFS квоти).
3. Виправте ідентичність і права з наміром: мапінг NFS root_squash, ACL CIFS, локальні ACL і профілі AppArmor.
4. Впровадьте нудні засоби запобігання: smoke-тести після перезавантаження та оповіщення про перемикання в readonly і вичерпання метаданих.

Після цього наступного разу, коли Proxmox видасть «Could not create», ви витратите п’ять хвилин на діагностику замість години на дискусії зі своїми припущеннями.