Proxmox « qemu-img: Could not create » : permissions, chemins et correctifs de système de fichiers qui fonctionnent réellement

Ce que l’erreur signifie vraiment (et ce qu’elle ne signifie pas)

Quand Proxmox crée un disque de VM, il finit généralement par appeler qemu-img (pour les images basées sur fichiers comme qcow2/raw), ou il demande aux outils de stockage de créer un périphérique bloc (zvol ZFS, volume logique LVM, RBD Ceph). Si cette étape de création échoue, vous verrez souvent :

• « qemu-img: Could not create … »
• « Permission denied » (explicite, si vous avez de la chance)
• « No such file or directory » (problème de chemin ou de montage)
• « Read-only file system » (système de fichiers ou export NFS monté en lecture seule)
• « No space left on device » (blocs de données, métadonnées, inodes, métadonnées de thin pool, ou quota)

Voici ce que ce n’est généralement pas :

• Pas un « bug aléatoire de Proxmox ». C’est presque toujours déterministe.
• Pas résolu en redémarrant pvedaemon « juste parce que ». Redémarrer peut vous donner l’impression d’avoir été productif, cependant.
• Pas résolu en faisant chmod 777 sur tout (sauf si votre objectif est de créer des incidents futurs).

L’état d’esprit pratique : traitez cela comme une défaillance d’écriture de stockage. Votre travail est de répondre à trois questions :

1. Où Proxmox essaie-t-il de créer le disque ?
2. Qui l’écrit (processus/utilisateur/mappage UID), et a-t-il les droits ?
3. Quel est l’état du support (monté, inscriptible, sain, a de l’espace, supporte les fonctionnalités) ?

Une citation qui tient en exploitation : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. Quand qemu-img échoue, l’espoir coûte particulièrement cher.

Blague #1 : Le stockage est le seul département où « Je ne peux pas créer un fichier » est considéré comme un message d’erreur détaillé.

Feuille de route de diagnostic rapide (vérifier premier/deuxième/troisième)

Premier : confirmer le stockage cible et le chemin/périphérique exact

Depuis le journal de tâche Proxmox, trouvez l’ID du stockage et le chemin qu’il a tenté de créer. Si vous êtes sur un stockage de type directory, vous verrez quelque chose comme /mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2. Si c’est ZFS/LVM, vous verrez un nom de zvol ou de LV.

Deuxième : valider le montage et la possibilité d’écriture en une minute

La plupart des échecs « Could not create » proviennent d’un montage manquant, d’un point de montage qui est en réalité le répertoire vide sous-jacent, ou d’un système de fichiers passé en lecture seule à cause d’erreurs. Vous pouvez détecter ces trois cas rapidement avec findmnt, mount et un petit test d’écriture.

Troisième : valider l’espace correctement (données, inodes, métadonnées thin, quotas)

Le manque d’espace n’est pas une seule chose. C’est : blocs, inodes, quota ZFS/refquota, métadonnées LVM thin, quotas utilisateur NFS. Vérifiez les compteurs pertinents pour le type de stockage.

Quatrième : vérifier permissions et identité (UID/GID, root_squash, ACL)

Sur les systèmes de fichiers locaux, Proxmox écrit typiquement en tant que root (via pvedaemon/pveproxy appelant les outils). Sur NFS/CIFS, ça peut devenir étrange : root devient nobody, l’héritage ACL fait quelque chose « utile », ou SMB vous mappe vers un utilisateur invité. Quand ça sent les permissions, vérifiez avec namei, stat et faites un test d’écriture depuis l’hôte.

Cinquième : vérifier la configuration du plugin de stockage et les types de contenu

Des types de contenu mal configurés (par exemple « VZDump backup only » alors que vous essayez d’y stocker des images), un mauvais chemin, un nom de pool erroné, ou une config de stockage obsolète sur un nœud du cluster provoqueront tous des échecs de création.

Faits et contexte intéressants (pourquoi ça revient)

• Fait 1 : qemu-img est antérieur à Proxmox et est utilisé largement dans les piles de virtualisation. Proxmox est souvent juste le messager.
• Fait 2 : Le stockage « Directory » de Proxmox est trompeusement simple : c’est juste un chemin de système de fichiers, ce qui signifie que les montages et permissions sont volontairement votre responsabilité.
• Fait 3 : Le root_squash NFS existe spécifiquement pour empêcher que root distant soit root sur le serveur. C’est aussi une des trois premières raisons pour lesquelles la création de disques VM échoue sur NFS.
• Fait 4 : L’LVM-thin peut manquer de métadonnées alors qu’il a encore beaucoup d’espace pour les données. L’erreur affichée induit souvent en erreur sur ce qui est plein.
• Fait 5 : ZFS peut refuser des créations à cause de quotas, conflits de réservation, ou d’un pool qui est techniquement en ligne mais sans espace allouable à cause de fragmentation et des choix de recordsize.
• Fait 6 : Ext4 et XFS se comportent différemment quand ils sont « pleins » : l’épuisement des inodes est plus courant sur ext4 avec des charges à petits fichiers ; XFS peut rencontrer des limites de quota de projet de manière surprenante.
• Fait 7 : AppArmor peut bloquer des opérations QEMU même quand les permissions Unix semblent correctes, surtout avec des points de montage personnalisés non couverts par les profils.
• Fait 8 : Un montage manquant peut être invisible si le répertoire de montage existe. Vous écrirez dans le système de fichiers racine local et ne le remarquerez que lorsqu’il se remplit. Cela a causé de vraies pannes dans des entreprises respectables.

Diagnostic orienté tâches : commandes, sorties, décisions

Ci‑dessous des tâches pratiques. Chacune inclut la commande, une sortie réaliste esquissée, et la décision à prendre. Exécutez-les depuis l’hôte Proxmox en échec, pas depuis votre portable, et pas depuis « l’autre nœud qui marche ».

Task 1: Read the Proxmox task log for the real target

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

Ce que ça signifie : Le chemin en échec est explicite. C’est de l’or. Si le message ne montre pas le chemin, consultez le journal complet de la tâche dans l’interface ou /var/log/pve/tasks.

Décision : Copiez le chemin exact/ID du stockage. Tout dépendra de cela.

Task 2: Confirm the storage definition Proxmox is using

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%

Ce que ça signifie : Proxmox pense que fastssd est actif. Cela ne garantit pas qu’il est correctement monté ou inscriptible.

Décision : Continuez les vérifications. « Active » est nécessaire, pas suffisante.

Task 3: Verify the mount is real (not an empty directory)

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

Ce que ça signifie : Bien : c’est un vrai montage depuis /dev/sdb1. Si cette sortie est vide, vous écrivez dans un répertoire simple sur le filesystem racine.

Décision : Si ce n’est pas monté, corrigez fstab/unités systemd et remontez avant toute autre action.

Task 4: Check whether it silently flipped read-only

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)

Ce que ça signifie : Le stockage est monté en ro. Proxmox échouera à créer quoi que ce soit, et l’erreur peut s’afficher comme « Permission denied » ou « Read-only file system » selon le chemin d’exécution.

Décision : Arrêtez d’essayer de créer des disques. Cherchez la cause de l’erreur système de fichiers, exécutez fsck (si ext4), ou corrigez le problème sous-jacent, puis remontez en rw.

Task 5: Do a minimal write test as the host (the only truth)

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

Ce que ça signifie : Ce n’est pas un problème de permissions Proxmox. C’est « le système de fichiers n’est pas inscriptible ».

Décision : Corrigez l’état du montage/du FS d’abord. Les permissions sont hors sujet tant que les écritures échouent.

Task 6: Check space and inodes (yes, both)

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

Ce que ça signifie : Les blocs sont pleins, les inodes vont bien. Si les blocs étaient suffisants mais les inodes à 100%, vous verriez des échecs de création similaires.

Décision : Libérez de l’espace ou étendez le système de fichiers. Ne « réessayez » pas sans rien faire : ça n’améliorera rien.

Task 7: Confirm directory ownership and traverse permissions on the full path

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

Ce que ça signifie : Le répertoire VM est possédé par l’UID 100000, ce qui arrive quand c’est un montage partagé créé par autre chose ou quand des mappings de namespace utilisateur sont en jeu. Notez aussi que fastssd est drwxr-x--- ; seuls root et le groupe root peuvent traverser.

Décision : Si Proxmox écrit en root, root peut traverser ; mais si un composant baisse ses privilèges ou utilise des IDs mappés, vous devrez peut‑être corriger la propriété/les ACL. Si c’est NFS avec root_squash, root ne sera pas root.

Task 8: Reproduce as “root” and interpret permission errors properly

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

Ce que ça signifie : Si même le root local ne peut pas écrire, alors soit :

• c’est un système de fichiers distant mappant root vers nobody (NFS root_squash),
• les ACL refusent l’écriture,
• des attributs immuables existent,
• ou le système de fichiers est monté avec des options restrictives.

Décision : Pour NFS/CIFS, inspectez les options d’export/montage. Pour un FS local, vérifiez ACLs et attributs.

Task 9: Inspect ACLs and immutable flags when permissions “look fine”

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

Ce que ça signifie : Les ACLs ici refusent complètement groupe/others. C’est acceptable si l’auteur correspond au propriétaire. Mais si NFS écrase root en nobody, cela ne correspondra pas. Les attributs semblent normaux (pas de flag i immuable).

Décision : Alignez la propriété avec l’identité effective de l’auteur, ou ajustez les options d’export et la sémantique de montage.

Task 10: Check NFS mount options and root squashing symptoms

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

Ce que ça signifie : UID/GID 65534 est le mapping classique « nobody/nogroup ». Cela suggère fortement un root_squash ou un mapping anonyme sur le serveur NFS.

Décision : Corrigez les exports NFS : soit définissez la bonne propriété sur l’export pour matcher l’UID mappé, soit ajustez les options d’export (avec prudence) afin que Proxmox puisse écrire.

Task 11: Check LVM-thin health (data vs metadata)

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)

Ce que ça signifie : Les données sont à 72%, les métadonnées sont quasiment pleines. La création échouera même si « l’espace » semble disponible à première vue.

Décision : Étendez les métadonnées du thinpool (et envisagez de surveiller cela). Ne continuez pas à réessayer ; vous ne ferez que remplir les journaux.

Task 12: Check ZFS pool health and quota constraints

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

Ce que ça signifie : Le zvol spécifique montre 0B disponible parce que c’est un volume et cet affichage peut être trompeur. Le signal plus important est la disponibilité du pool/dataset et les quotas/réservations. Si AVAIL est faible ou si des quotas existent, la création de zvol peut échouer.

Décision : Si le pool est sain mais que AVAIL est bas ou que des quotas existent, libérez de l’espace ou ajustez quota/refquota/reservation. Vérifiez aussi ashift et la fragmentation si vous êtes souvent en limite.

Task 13: Verify Proxmox storage content types (a sneaky “permission-like” failure)

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

Ce que ça signifie : Ce stockage est configuré pour modèles et sauvegardes seulement, pas pour images VM. Tenter de créer un disque VM là-bas échouera, parfois avec un message confus selon le flux de travail.

Décision : Ajoutez images au type de contenu (et peut‑être iso) si ce stockage est destiné aux disques VM.

Task 14: Validate that the storage path exists on this node (cluster drift)

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

Ce que ça signifie : Dans un cluster, /etc/pve/storage.cfg est partagé, mais les montages ne le sont pas automatiquement. Un nœud peut avoir le stockage configuré mais ne pas l’avoir réellement présent.

Décision : Créez/mount le chemin de façon cohérente sur tous les nœuds, ou limitez le stockage aux nœuds qui le possèdent.

Task 15: Check for AppArmor blocking QEMU on odd mountpoints

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.

Ce que ça signifie : Les permissions Unix peuvent être parfaites et vous aurez tout de même un « permission denied » si AppArmor bloque l’accès. La ligne dans dmesg est la preuve irréfutable.

Décision : Ajustez le profil concerné ou assurez-vous d’utiliser des chemins de stockage attendus. « Désactiver AppArmor » est une arme lourde ; servez‑vous en seulement pour un diagnostic court, pas comme solution permanente.

Task 16: Verify CIFS/SMB mounts aren’t lying about permissions

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

Ce que ça signifie : CIFS peut présenter des permissions qui ont l’air permissives localement mais sont rejetées par le serveur. C’est l’ACL côté serveur ou le mapping utilisateur qui compte.

Décision : Corrigez les permissions du partage et les identifiants ; envisagez NFS pour les images VM si vous souhaitez moins de surprises sémantiques.

Pièges par type de stockage : Directory, ZFS, LVM-thin, NFS, CIFS

Directory storage (path-backed) : le plus simple, et donc le plus facile à mal monter

Le stockage par répertoire est littéralement « écris les fichiers ici ». Cela signifie que qemu-img crée des fichiers qcow2/raw sous path/images/<vmid>. Les échecs proviennent de :

• Montage manquant ; le point de montage existe comme répertoire vide
• Système de fichiers monté en lecture seule après erreurs
• Plus d’espace disponible / épuisement des inodes
• Inadéquation des permissions/ACL sur le répertoire VMID ou ses parents
• AppArmor refusant l’accès à des points de montage non standards

Conseil d’opinion : pour le stockage de type directory, utilisez un point de montage dédié sous /mnt/pve/<storageid> et assurez-vous qu’il soit monté par systemd, pas « quelqu’un monte après le reboot ». Les humains ne sont pas des processus de démarrage fiables.

ZFS zvol storage : rapide, cohérent, et allergique aux mauvaises habitudes de capacité

Les disques VM sur ZFS sont souvent des zvols. Les échecs de création apparaissent quand :

• Le pool a peu d’espace disponible (ZFS veut de l’air libre ; être à 95% est inviter aux latences étranges)
• Des quotas/refquotas/réservations bloquent de nouveaux volumes
• Le pool est dégradé ou suspendu (les erreurs I/O se propagent de manière étrange)
• Conflits de noms (un zvol stale existe depuis une création précédente échouée)

Conseil pratique : traitez les pools ZFS comme des systèmes vivants. Surveillez l’espace, scrutez régulièrement, et ne les traitez pas comme « juste un autre disque ext4 ».

LVM-thin : quand les métadonnées sont votre vrai disque

LVM-thin est bien, jusqu’à ce que ça ne le soit plus. L’échec « Could not create » est classique quand les métadonnées du thin pool sont pleines. Les données peuvent être à 40% d’utilisation, les métadonnées à 100% et vous obtenez des erreurs sévères.

Surveillez aussi :

• Thin pool en mode lecture seule à cause d’erreurs
• Espace libre du VG insuffisant pour étendre les métadonnées
• Paramètres discard/TRIM interagissant avec le stockage sous-jacent

Ne « compactez » pas les métadonnées en les rendant ridiculement petites. C’est comme acheter un entrepôt puis construire un classeur à tiroir unique pour l’inventaire. Ça marche jusqu’à ce que vous stockiez plus de trois choses.

NFS : théâtre des permissions, avec root_squash en vedette

NFS est courant pour le stockage partagé Proxmox, et c’est aussi une source constante de « Permission denied ». Root squashing, incompatibilités ACL, ou exports montés sur un nœud mais pas sur l’autre sont les principaux coupables.

Si vous utilisez NFS pour les images VM, assurez-vous :

• Que l’export est conçu pour cela (faible latence, comportement sync correct)
• Que le mapping UID/GID est délibéré et documenté
• Que les options de montage sont cohérentes entre nœuds

CIFS/SMB : bien pour les ISO et sauvegardes ; les images VM sont un pari

Vous pouvez faire fonctionner SMB, mais la sémantique diffère. Verrouillage, oplocks, mapping des permissions, et le fameux « semble inscriptible mais ne l’est pas » sont des fonctions régulières. Si vous devez l’utiliser, testez les opérations qemu-img create en conditions de charge, pas seulement avec un touch.

Modèle de permissions dans Proxmox : qui écrit quoi, où

Quand vous cliquez sur les boutons de l’UI, la requête passe par des démons Proxmox qui s’exécutent en root. L’étape de création du disque est généralement réalisée par root sur l’hôte. Cela signifie :

• Sur les systèmes de fichiers locaux, les permissions Unix ne sont généralement pas le problème sauf si vous les avez durcies agressivement ou utilisé des ACL.
• Sur NFS, root peut ne pas être root sur le serveur. Root_squash transforme « root » en UID anonyme, qui ne peut alors pas créer des fichiers dans des répertoires possédés par de vrais utilisateurs.
• Sur CIFS, root peut être mappé à un utilisateur de partage qui n’a pas les droits d’écriture.
• Dans les environnements en cluster, la configuration est partagée mais les montages ne le sont pas. Le nœud A peut écrire ; le nœud B ne peut pas ; l’UI a l’air identique jusqu’à ce qu’elle ne le soit plus.

Règle pratique : testez toujours les écritures depuis l’hôte vers le répertoire exact utilisé par Proxmox. Si touch échoue, qemu-img échouera. Si touch marche mais qemu-img échoue, vous êtes alors dans la zone « AppArmor / type de contenu / support de fonctionnalités / spécificités du plugin ».

Blague #2 : « Permission denied » est la façon du système de dire : « J’ai entendu votre requête et j’ai choisi la violence. »

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “No such file or directory” for a path under /mnt/pve/…

Cause racine : Le point de montage n’existe pas sur ce nœud, ou le stockage n’est pas monté, ou l’arborescence (images/<vmid>) n’a pas été créée à cause d’échecs précédents.

Correction : Créez le répertoire point de montage, assurez-vous que le filesystem est monté au démarrage, et vérifiez avec findmnt -T. Puis retentez la création.

2) Symptom: Proxmox shows storage “active,” but create fails instantly

Cause racine : Les vérifications d’état du stockage peuvent être superficielles ; un montage stale ou un répertoire sous-jacent peut quand même apparaître « active ».

Correction : Validez que le montage est réel et inscriptible : findmnt + test touch sur le chemin exact.

3) Symptom: “Permission denied” on NFS, even as root

Cause racine : NFS root_squash ou mapping UID anonyme ; les permissions d’export n’autorisent pas l’UID mappé à écrire.

Correction : Alignez la propriété côté serveur avec l’UID/GID mappé, ou ajustez les options d’export et le modèle de sécurité. Vérifiez avec stat montrant UID/GID et un test d’écriture.

4) Symptom: “Read-only file system” suddenly on local ext4

Cause racine : ext4 remonté en lecture seule après détection d’erreurs du système de fichiers (souvent liées à un disque défaillant ou un arrêt non sûr).

Correction : Consultez les logs, planifiez une fenêtre d’arrêt, exécutez fsck sur le périphérique bloc, corrigez les problèmes matériels sous-jacents, puis remontez en rw.

5) Symptom: Plenty of “free space,” still can’t create on LVM-thin

Cause racine : Les métadonnées du thin pool sont pleines, ou le thin pool est en état d’erreur.

Correction : Vérifiez lvs pour metadata_percent. Étendez les métadonnées et envisagez d’activer la surveillance/autoextend.

6) Symptom: Create fails on one cluster node but works on another

Cause racine : Montages ou identifiants différents par nœud ; la configuration de stockage est partagée mais les montages et secrets peuvent ne pas l’être.

Correction : Standardisez les montages et options entre nœuds. Pour NFS/CIFS, assurez-vous d’unités de montage et de fichiers d’identifiants identiques.

7) Symptom: “Permission denied,” but Unix perms look correct

Cause racine : AppArmor, SELinux (moins courant sur Proxmox par défaut), ou ACLs.

Correction : Inspectez dmesg pour des refus AppArmor ; ajustez le profil ou le chemin de stockage. Vérifiez getfacl.

8) Symptom: Fails only for qcow2, raw works (or vice versa)

Cause racine : Fonctionnalités du système de fichiers ou options de montage interférant (par ex. CIFS « nobrl »/comportement de locking), ou attentes de la chaîne d’outils.

Correction : Préférez raw sur périphériques bloc (zvol/LV). Pour les partages réseau, testez en charge réelle ; repensez le choix de stockage pour les images VM.

9) Symptom: “Could not create” when selecting a storage that is “backup-only”

Cause racine : Les types de contenu du stockage n’incluent pas images.

Correction : Mettez à jour /etc/pve/storage.cfg pour inclure images pour ce stockage (ou choisissez le stockage approprié).

10) Symptom: “No space left on device” but df shows space

Cause racine : Inodes épuisés, quota atteint, quota de projet atteint, métadonnées thin pleines, ou quota/refquota ZFS.

Correction : Vérifiez le compteur pertinent selon le type de stockage : df -i, quotas ZFS, métadonnées LVM, outils de quota.

Trois mini-histoires d’entreprise (comment ça échoue en pratique)

Mini-story 1: The wrong assumption (active storage ≠ mounted storage)

L’environnement semblait propre : un petit cluster Proxmox, un stockage directory « fastssd », et quelques nouvelles VMs à provisionner avant le déjeuner. L’ingénieur les voyait « active » dans l’UI et a supposé que c’était monté et sain. Hypothèse raisonnable. Hypothèse fausse.

Un nœud avait redémarré la nuit précédente après une mise à jour du kernel. L’unité de montage n’était pas revenue car elle dépendait d’un chemin de périphérique qui avait changé. Le point de montage existait toujours, donc tout avait l’air normal. Proxmox a essayé de créer des images disque sous /mnt/pve/fastssd — qui était maintenant juste un répertoire sur le filesystem racine.

La création échouait avec qemu-img: Could not create de façon intermittente à mesure que le filesystem racine se remplissait. Pendant ce temps, d’autres services ont commencé à échouer de manière non liée : les mises à jour de paquets échouaient, les logs ne pouvaient plus être vidés, et la chaîne d’incident a rapidement reçu trois diagnostics différents.

La correction fut douloureusement simple : corriger l’unité de montage pour utiliser un identifiant stable, monter le filesystem, et nettoyer les images partielles écrites au mauvais endroit. L’amélioration réelle fut procédurale : après cet incident, ils ont intégré « findmnt -T le chemin cible » dans chaque triage de stockage. Cela a empêché une répétition dans les semaines suivantes — car le même mode d’échec a tenté de se reproduire.

Mini-story 2: The optimization that backfired (tiny thin metadata)

Une autre équipe voulait plus d’espace utilisable dans leur pool LVM-thin. Ils ont lu juste assez pour être dangereux et ont décidé que les métadonnées étaient « overhead ». Ils ont reconstruit le thin pool avec un volume de métadonnées plus petit. Le premier jour, tout semblait parfait : plus de gigaoctets dispo, moins de « gaspillage », points bonus lors de la réunion infra.

Des mois plus tard, l’équipe plateforme a commencé à voir des échecs sporadiques de provisionnement de VM. Ce n’était pas constant. Ce n’était pas prévisible. Et l’erreur était le vague insultant habituel « qemu-img could not create » lors de la création de disques sur le thin pool.

L’utilisation des données allait bien. Le pool n’était pas plein. Mais les métadonnées l’étaient. Snapshots, clones et churn avaient tout consommé. Quand les métadonnées atteignent le plafond, le thin provisioning cesse d’être « thin » et devient fragile. Les systèmes ne dégradent pas en douceur ; ils arrêtent simplement de créer de nouveaux volumes.

Ils ont réparé le problème en étendant les métadonnées et en activant la surveillance. Mais la leçon réelle était culturelle : optimiser pour une métrique visible (espace libre de données) en ignorant les métadonnées est un classique « gain sur feuille de calcul, perte en production ». Après ça, ils ont standardisé les tailles de création de pool et alerté sur metadata_percent. Ce n’était pas excitant, mais c’était stable.

Mini-story 3: The boring practice that saved the day (write tests and uniform mounts)

Un environnement d’entreprise avait une règle presque enfantine : chaque nœud doit passer un « smoke test » stockage standard après reboot. Il vérifiait que chaque point de montage Proxmox existait, était monté, et inscriptible. Il créait même et supprimait un petit fichier dans le répertoire exact utilisé par Proxmox.

Pendant une maintenance routinière, un serveur NFS a été mis à jour. Un export est revenu avec une politique modifiée : root était maintenant squashed alors qu’avant il ne l’était pas. D’un point de vue sécurité, ce changement était défendable. Opérationnellement, cela signifiait que Proxmox ne pouvait plus créer de disques VM sur cet export.

Le test smoke post‑reboot a échoué immédiatement sur plusieurs nœuds, avant que quiconque n’essaie de créer une VM. L’équipe n’a pas découvert le problème lors d’un flux de travail visible par les clients. Ils l’ont découvert lors d’un contrôle maîtrisé, puis ont corrigé le mapping de propriété de l’export et l’ont documenté.

Pas de drame. Pas de pages nocturnes. Pas de « ça marchait hier ». Juste un contrôle ennuyeux qui a évité un incident spectaculaire. En production, l’ennuyeux est un produit premium.

Listes de vérification / plan pas-à-pas (faites ceci, pas de magie)

Step-by-step: when you hit “qemu-img: Could not create”

1. Capturer le chemin/périphérique exact en échec depuis le journal de tâche Proxmox. Ne le paraphrasez pas.
2. Identifier le type de stockage : Directory, ZFS, LVM-thin, NFS, CIFS, Ceph. Utilisez pvesm status et /etc/pve/storage.cfg.
3. Sanité du montage (directory/NFS/CIFS) :
   • findmnt -T <path> doit montrer une source et un fstype attendu.
   • mount doit le montrer en rw (sauf si intentionnellement en ro).
4. Test d’écriture sur le répertoire exact :
   • touch puis supprimer. Si ça échoue, arrêtez et corrigez cela d’abord.
5. Sanité de capacité :
   • Directory : df -h et df -i
   • LVM-thin : lvs data_percent + metadata_percent
   • ZFS : zfs list et zfs get quota,refquota,reservation
6. Sanité des permissions :
   • namei -l sur le chemin complet
   • getfacl si des ACLs sont impliquées
   • Sur NFS, confirmez le mapping UID avec stat
7. Sanité de la couche sécurité :
   • dmesg pour des refus AppArmor
   • aa-status pour confirmer que les profils sont actifs
8. Sanité de la config Proxmox :
   • Les types de contenu du stockage incluent images
   • Le stockage est activé sur le nœud qui crée la VM
9. Réessayer une fois après correction de la cause racine. Si ça échoue encore, capturez les logs et escaladez méthodiquement. Pas de clics en rafale.

Operational checklist: prevent repeats

• Montages définis avec identifiants stables (UUIDs ou /dev/disk/by-id), pas des chemins /dev/sdX volatils.
• Unités systemd de montage ou entrées fstab testées au redémarrage.
• Alertes sur : événements de remount en lecture seule, faible espace, épuisement d’inodes, métadonnées LVM thin, capacité pool ZFS.
• Options de montage cohérentes entre nœuds du cluster pour le stockage partagé.
• Un petit smoke test stockage post‑reboot (mount + write + delete) pour chaque chemin de stockage Proxmox.
• Politiques d’export NFS documentées : root_squash, anonuid/anongid, modèle de propriété.

FAQ

1) Why does Proxmox say “qemu-img could not create” when the real issue is NFS permissions?

Parce que qemu-img est l’outil tentant la création. NFS rejette l’écriture, qemu-img rapporte l’échec. Corrélez toujours avec les options de montage et le mapping UID.

2) Storage shows “active” in Proxmox—doesn’t that mean it’s mounted and writable?

Non. Cela signifie souvent que le plugin de stockage de Proxmox voit le chemin ou que le backend répond. Un point de montage absent peut quand même « exister » et tromper des vérifications superficielles.

3) What’s the fastest way to detect a missing mount vs a permission problem?

findmnt -T <path> plus un touch <path>/.test. Si findmnt est vide, c’est un problème de montage. Si touch échoue, lisez l’erreur exacte.

4) Why can root get “Permission denied” on NFS?

Parce que sur le serveur, root peut être mappé vers un UID anonyme (root_squash). Cet UID peut ne pas être propriétaire du répertoire et ne pas avoir les droits d’écriture.

5) Can I fix this by chmod 777 on the storage path?

Parfois ça « marche », et c’est précisément pourquoi c’est dangereux : cela masque les problèmes d’identité/mapping et augmente le rayon d’impact. Corrigez la propriété, les ACLs, ou la politique d’export à la place.

6) What if the error happens only on one node in a cluster?

Supposez des montages ou identifiants spécifiques au nœud. Validez le même chemin de stockage sur ce nœud avec findmnt et des tests d’écriture. La config du cluster est partagée ; les montages ne le sont pas.

7) How do I tell if it’s LVM-thin metadata and not disk space?

Vérifiez lvs et regardez metadata_percent. S’il est proche de 100%, vous avez trouvé le coupable.

8) When should I suspect AppArmor?

Quand les permissions et les tests d’écriture fonctionnent, mais qemu-img échoue encore — ou quand dmesg affiche des lignes AppArmor « DENIED » faisant référence au chemin du disque.

9) Is CIFS/SMB a good idea for VM disks?

Ça peut fonctionner, mais c’est moins prévisible que NFS pour les images VM à cause des sémantiques de permission et de verrouillage. Beaucoup d’équipes utilisent SMB pour les ISOs/sauvegardes et gardent les disques VM sur du bloc ou NFS.

10) What’s the cleanest way to prevent “missing mount writes to root filesystem”?

Utilisez des automounts systemd ou des unités de montage strictes et envisagez de rendre le point de montage non inscriptible tant qu’il n’est pas monté. Au minimum, alertez sur une croissance inattendue du filesystem racine.

Conclusion : prochaines étapes pour éviter la répétition

L’erreur « qemu-img: Could not create » n’est pas mystérieuse. Elle est répétitive. C’est une bonne nouvelle : les problèmes répétitifs reçoivent des correctifs standardisés.

Faites ceci ensuite, dans l’ordre :

1. Prenez un chemin en échec depuis le journal de tâche et vérifiez‑le avec findmnt et un test d’écriture.
2. Vérifiez la capacité correctement selon votre type de stockage (blocs, inodes, métadonnées thin, quotas ZFS).
3. Corrigez l’identité et les permissions avec intention : mapping root_squash NFS, ACLs de partage CIFS, ACLs locales, et profils AppArmor.
4. Implémentez les mesures préventives ennuyeuses : smoke tests post‑reboot pour le stockage et alertes sur remounts en lecture seule et exhaustion de métadonnées.

Une fois ceci fait, la prochaine fois que Proxmox lancera « Could not create », vous passerez cinq minutes à le diagnostiquer au lieu d’une heure à négocier avec vos propres hypothèses.