Proxmox « impossible d’écrire /etc/pve/* » : disque, pmxcfs ou permissions — comment trancher

Le modèle mental : ce qu’est vraiment /etc/pve

Dans Proxmox VE, /etc/pve n’est pas « juste des configurations sur disque ». C’est un système de fichiers virtuel fourni par pmxcfs (Proxmox Cluster File System), monté via FUSE. Il se comporte comme une base de configuration partagée avec une sémantique de système de fichiers : fichiers et répertoires, mises à jour atomiques, permissions et événements inotify. Mais la vérité sous-jacente ressemble davantage à « machine d’état de cluster plus réplication » qu’à « un dossier ».

Ce seul fait explique la plupart des bizarreries :

• Si pmxcfs est indésirable ou en lecture seule, les écritures vers /etc/pve échouent même si votre système de fichiers racine a beaucoup d’espace libre.
• Si le cluster perd le quorum, pmxcfs devient souvent lecture seule pour vous protéger d’un split brain. L’erreur ressemble à un problème de système de fichiers parce que c’est ainsi que vous interagissez avec lui.
• Si les permissions sont incorrectes, vous pouvez être root sur le nœud et quand même subir un refus selon le contexte d’écriture (jeton API, utilisateur, propriété du fichier, ou un verrou obsolète).

Donc quand vous voyez « unable to write /etc/pve/* », ne lancez pas immédiatement la danse classique Linux du chown -R et du chmod -R. C’est comme ça que des gens transforment un problème gérable en projet de récupération.

Voici la traduction opérationnelle :

• Problème disque signifie qu’un stockage dont dépend pmxcfs est plein ou dégradé (typiquement le système root local pour logs/état, ou pire : corruption, remontage en lecture seule, erreurs I/O).
• Problème pmxcfs/quorum signifie que l’état d’adhésion du cluster n’est pas modifiable ; votre nœud peut avoir perdu le quorum, corosync est mécontent, ou pve-cluster est bloqué.
• Problème de permissions signifie que l’acteur qui écrit (utilisateur CLI, utilisateur/jeton API, processus de service) ne peut pas écrire, ou qu’un fichier est verrouillé/obsolète d’une manière qui se manifeste comme un échec d’écriture.

Une citation opérationnelle à garder sous les yeux : « idée paraphrasée » de Werner Vogels (CTO d’Amazon) : Vous le construisez, vous l’exploitez ; le retour d’exploitation fait partie de l’ingénierie. Le point : ne vous contentez pas de « réparer l’écriture », corrigez la raison pour laquelle le système a jugé l’écriture dangereuse.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : confirmez ce que fait /etc/pve maintenant (secondes)

1. Est-ce que pmxcfs est monté et accessible en écriture ? Vérifiez le type de montage et le statut lecture-seule.
2. Le cluster est-il quoré ? Sinon, attendez-vous à un comportement en lecture seule.
3. Les services sont-ils sains ? En particulier pve-cluster et corosync.

Second : éliminez les tueurs ennuyeux (minutes)

1. Disque plein sur / ou /var ? La pression disque casse tout indirectement.
2. Système de fichiers remonté en lecture seule ? Un incident I/O et vos écritures sont condamnées.
3. Pression mémoire ? pmxcfs garde les métadonnées en RAM ; une pression extrême peut produire des symptômes étranges.

Troisième : vérifiez l’acteur et le chemin d’écriture spécifique (minutes)

1. Écrivez-vous via l’interface graphique/jeton API ? Le modèle de permissions diffère de « root sur SSH ».
2. Y a-t-il un fichier de verrou ou une config obsolète ? Les verrous de config VM et les tâches de réplication peuvent bloquer les choses.
3. Ce nœud est-il « spécial » ? Dérive horaire, perte réseau ou mode cluster mono-nœud peuvent inverser le comportement.

Si vous êtes en panne réelle : ne redémarrez pas tout aveuglément. Redémarrer corosync du mauvais côté d’une partition est la façon dont on découvre à quoi ressemble un split brain.

Blague #1 : pmxcfs, c’est comme un chat de groupe : si la moitié de l’équipe ne voit pas les messages, personne ne peut modifier le post épinglé.

Faits intéressants et contexte historique (pourquoi ça se comporte ainsi)

• Fait 1 : /etc/pve est un montage FUSE fourni par pmxcfs, pas un répertoire normal sur disque. Voilà pourquoi les erreurs « système de fichiers » sont en réalité des erreurs d’état de cluster déguisées.
• Fait 2 : Proxmox utilise Corosync pour l’adhésion au cluster et les décisions de quorum ; pmxcfs l’utilise pour décider quand il est sûr d’accepter des écritures.
• Fait 3 : Le comportement « lecture seule quand pas de quorum » est une fonctionnalité de sécurité contre le split brain. C’est agaçant jusqu’à ce que ça vous évite deux nœuds modifiant des configs VM de façon contradictoire.
• Fait 4 : pmxcfs conserve une grande partie de la config du cluster en mémoire et la synchronise ; perdre pmxcfs n’est pas équivalent à perdre tout votre système de fichiers OS.
• Fait 5 : Historiquement, les systèmes de fichiers de cluster dans les piles de virtualisation ont plutôt tendance à limiter les écritures. Le modèle vCenter de VMware et de nombreuses piles HA préfèrent aussi « arrêter les écritures » quand l’adhésion est incertaine.
• Fait 6 : Le choix de conception de Proxmox — faire ressembler la config du cluster à des fichiers — simplifie l’automatisation (éditer un fichier, exécuter une commande), mais rend aussi les modes de défaillance trompeusement « unixiens ».
• Fait 7 : De nombreuses défaillances d’écriture Proxmox sont des effets secondaires : disque plein arrête les écritures de logs, les services redémarrent en boucle, le quorum vacille, et soudain /etc/pve semble cassé alors que le vrai problème est la capacité.
• Fait 8 : La dérive horaire peut déstabiliser l’adhésion corosync sur des réseaux limites. Dans un cluster, l’heure est une dépendance comme l’électricité et la climatisation — juste plus discrète.

Tâches de triage : commandes, sorties et décisions (12+)

Voici les commandes que j’exécute réellement quand la production brûle. Chaque tâche inclut ce que vous cherchez, ce que signifie la sortie et quelle décision prendre ensuite.

Tâche 1 : confirmer que /etc/pve est un montage pmxcfs FUSE

cr0x@server:~$ mount | grep "on /etc/pve"
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Signification : Vous devez voir type fuse.pve. S’il manque, pmxcfs n’est pas monté (pve-cluster en panne ou bloqué).

Décision : Si absent, passez aux vérifications des services (pmxcfs/quorum) et aux journaux. Si présent mais en ro, traitez-le comme un problème de quorum ou d’état pmxcfs.

Tâche 2 : tester le chemin d’écriture sans dommages collatéraux

cr0x@server:~$ touch /etc/pve/.diag-write-test
touch: cannot touch '/etc/pve/.diag-write-test': Read-only file system

Signification : « Read-only file system » est généralement pmxcfs qui bloque les écritures (souvent quorum). « Permission denied » est acteur/ACL. « No such file » indique que le montage a disparu.

Décision : Read-only → vérifiez le quorum et pve-cluster ; Permission denied → vérifiez l’identité/utilisation API ; No such file → pmxcfs non monté.

Tâche 3 : vérifier rapidement l’état du quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 25 12:10:03 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          No

Signification : Quorate: No est votre preuve évidente. pmxcfs peut basculer en lecture seule pour éviter la divergence.

Décision : Corrigez la connectivité corosync/quorum avant d’essayer de « réparer les permissions » ou de redémarrer des services au hasard.

Tâche 4 : voir qui corosync pense être présent

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
	id	= 192.0.2.11
	status	= ring 0 active with no faults
RING ID 1
	id	= 198.51.100.11
	status	= ring 1 active with no faults

Signification : Les anneaux sont actifs localement, mais cela ne garantit pas que les autres nœuds sont joignables.

Décision : Si les anneaux locaux montrent des défauts, réparez NIC/VLAN/MTU d’abord. Si le local semble correct mais que le quorum est perdu, vérifiez la joignabilité des pairs et les journaux de corosync.

Tâche 5 : vérifier la vue d’adhésion au cluster

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Thu Dec 25 12:10:08 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.2
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      1
Quorum:           2
Flags:            0

Signification : Total votes 1 implique que vous êtes isolé. Ce n’est pas un problème « disque plein ». C’est un problème de réseau/adhésion au cluster.

Décision : Arrêtez d’essayer de forcer des écritures. Restaurez la connectivité ou prenez une décision délibérée concernant une opération en mode nœud unique temporaire.

Tâche 6 : vérifier l’état du service pve-cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Thu 2025-12-25 12:01:22 UTC; 8min ago
   Main PID: 1543 (pmxcfs)
      Tasks: 7
     Memory: 52.3M
        CPU: 9.122s

Signification : Si inactive/failed, /etc/pve ne sera pas monté ou sera obsolète.

Décision : Si en échec, lisez les logs avant de redémarrer. Si en cours mais /etc/pve est RO, concentrez-vous sur le quorum/l’état plutôt que sur des redémarrages de service.

Tâche 7 : lire les journaux pertinents, pas tous les journaux

cr0x@server:~$ journalctl -u pve-cluster -u corosync --since "30 min ago" --no-pager
Dec 25 11:55:02 pve1 pmxcfs[1543]: [status] notice: received write while not quorate - rejecting
Dec 25 11:55:04 pve1 corosync[1321]:   [QUORUM] This node is within the non-primary component
Dec 25 11:55:06 pve1 pmxcfs[1543]: [dcdb] notice: leaving CFS service because of lost quorum

Signification : pmxcfs rejette explicitement les écritures à cause de la perte du quorum. C’est toute l’histoire.

Décision : Restaurez l’adhésion corosync. Si c’est une partition de maintenance planifiée, suivez la procédure prévue (voir les checklists).

Tâche 8 : écarter l’épuisement simple du disque

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  110G  109G     0 100% /

Signification : 100% du système root est un générateur d’incidents. Les services échouent de manière créative. pmxcfs peut être monté, mais d’autres composants ne peuvent pas écrire l’état/logs.

Décision : Libérez de l’espace immédiatement (logs, caches), puis revérifiez les services et le comportement de /etc/pve. Ne commencez pas par « le cluster est cassé » si le nœud ne peut pas écrire sur /.

Tâche 9 : vérifier l’épuisement des inodes (oui, ça arrive encore)

cr0x@server:~$ df -i /
Filesystem     Inodes IUsed  IFree IUse% Mounted on
/dev/sda2     7208960 7208801    159  100% /

Signification : Vous pouvez avoir des gigaoctets libres et pourtant être incapable de créer de nouveaux fichiers. Certaines erreurs d’écriture remontent comme « unable to write » et ressemblent à des problèmes de permissions.

Décision : Trouvez le consommateur d’inodes (souvent des petits fichiers sous /var/lib ou /var/log) et nettoyez en toute sécurité. Puis retentez l’écriture vers /etc/pve.

Tâche 10 : détecter un remontage en lecture seule dû à des erreurs I/O

cr0x@server:~$ dmesg -T | tail -n 20
[Thu Dec 25 12:06:14 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 25 12:06:14 2025] EXT4-fs (sda2): Remounting filesystem read-only

Signification : Le système de fichiers OS est en lecture seule. Vous ne pouvez pas faire confiance à un comportement d’écriture, y compris des services qui gèrent /etc/pve.

Décision : Stoppez. Réparez le stockage/matériel sous-jacent ou restaurez le système de fichiers. Une erreur d’écriture de config de cluster n’est pas le vrai problème ici.

Tâche 11 : confirmer les options de montage de /etc/pve (rw vs ro)

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /etc/pve
/etc/pve fuse.pve rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other

Signification : Si cela affiche ro, c’est une décision de blocage (quorum ou état pmxcfs) ou un mode d’échec de montage.

Décision : ro + quorate=no → rétablir quorum. ro + quorate=yes → creuser la santé de pmxcfs et les logs.

Tâche 12 : valider que le nœud voit ses pairs (vérification réseau)

cr0x@server:~$ ping -c 2 192.0.2.12
PING 192.0.2.12 (192.0.2.12) 56(84) bytes of data.
64 bytes from 192.0.2.12: icmp_seq=1 ttl=64 time=0.332 ms
64 bytes from 192.0.2.12: icmp_seq=2 ttl=64 time=0.301 ms

--- 192.0.2.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : Le ping qui fonctionne ne garantit pas que corosync fonctionne, mais l’échec du ping indique généralement la raison de la perte de voix.

Décision : Si le ping échoue, réparez L2/L3 d’abord. Si le ping fonctionne, enquêtez sur MTU, multicast/UDPU, règles de pare-feu ou spécificités du transport knet.

Tâche 13 : chercher des fichiers de verrou qui impactent les écritures de config

cr0x@server:~$ ls -la /etc/pve/nodes/pve1/qemu-server/ | head
total 8
drwxr-xr-x 2 root www-data 4096 Dec 25 11:50 .
drwxr-xr-x 4 root www-data 4096 Dec 25 11:40 ..
-rw-r----- 1 root www-data  612 Dec 25 11:50 101.conf

Signification : Vous vérifiez la propriété et les perms sur une config VM par nœud. Normalement c’est souvent root:www-data avec un mode restrictif.

Décision : Si vous voyez une propriété étrange (user:user) ou des bits world-writable, ne « corrigez » pas aveuglément — identifiez ce qui l’a écrit ainsi. Si des fichiers sont manquants, cela peut indiquer un problème de montage ou de synchronisation.

Tâche 14 : reproduire l’échec via une écriture contrôlée par la couche API

cr0x@server:~$ pvesh set /nodes/pve1/config -description "diag change"
unable to write file '/etc/pve/nodes/pve1/config': Permission denied

Signification : Si l’erreur est « Permission denied » via pvesh, vous exécutez peut-être dans un shell non-root ou utilisez un jeton API sans privilèges suffisants.

Décision : Confirmez votre identité et vos rôles. Si vous êtes root et que vous avez toujours un refus, examinez les ACL/propriétés corrompues ou un état de permission pmxcfs anormal.

Tâche 15 : confirmer qui vous êtes (ça compte plus que vous ne le pensez)

cr0x@server:~$ id
uid=1001(ops) gid=1001(ops) groups=1001(ops),27(sudo)

Signification : « sudo group » n’est pas « root ». Si votre outil n’a pas utilisé sudo, vous n’êtes pas root. Proxmox attend souvent des écritures de configuration au niveau root.

Décision : Utilisez sudo -i pour les actions administratives ou adaptez votre automatisation pour s’exécuter avec les privilèges appropriés.

Tâche 16 : vérifier si votre système de fichiers root est assez sain pour être fiable

cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Signification : Si le disque est en train de lâcher, tout peut s’effondrer. Vous pourriez courir après des « erreurs de permission » causées par des défaillances I/O.

Décision : Priorisez la sécurité des données : évacuez les workloads si possible, remplacez le disque, puis corrigez le logiciel. La fiabilité prime sur l’astuce.

Blague #2 : Les bugs de permissions sont l’équivalent au travail d’une carte d’accès qui cesse de fonctionner juste quand vous avez un café à la main.

Trois grands ensembles : disque, pmxcfs/quorum, permissions

Ensemble A : problèmes de disque et du système de fichiers OS

Les problèmes de disque se manifestent de deux manières : la capacité (blocs/inodes pleins) et l’intégrité (erreurs I/O provoquant des remontages en lecture seule). Les deux peuvent produire « unable to write /etc/pve/* » parce que les composants Proxmox ont besoin du disque local pour fonctionner même si /etc/pve est lui-même virtuel.

Chaînes courantes entraînées par le disque :

• / plein → services déraillent → services de cluster oscillent → pmxcfs devient instable. Cela arrive plus souvent qu’on ne l’admet.
• Remontage du système de fichiers en lecture seule → pve-cluster peut rester en cours mais ne peut pas persister l’état/logs. Vous voyez des échecs d’écriture, mais la correction est du côté stockage, pas Proxmox.
• Inodes épuisés → tempêtes de petits fichiers (logs de conteneurs, spools de sauvegarde, monitoring) → écritures de config échouent indirectement.

Ce qu’il ne faut pas faire : ne « résolvez » pas un disque plein en supprimant au hasard des fichiers sous /var/lib/pve-cluster ou quoi que ce soit qui sente l’état du cluster. Nettoyez les logs, faites une rotation, supprimez les sauvegardes obsolètes et les ISO inutilisés, puis réévaluez.

Ensemble B : pmxcfs et quorum (le classique)

Si votre nœud n’est pas quoré, Proxmox vous rend souvent service en refusant les écritures. La config du cluster doit rester cohérente. Si plusieurs nœuds pouvaient écrire des configs divergentes pendant une partition, vous finiriez par deux réalités incompatibles. Ce n’est pas de la haute disponibilité, c’est du drame élevé.

Indicateurs clés que c’est votre ensemble :

• pvecm status montre Quorate: No
• journalctl -u pve-cluster mentionne la perte de quorum, le rejet des écritures
• /etc/pve est monté mais en lecture seule
• Les changements via l’interface échouent partout : création VM, édition de stockage, modifications réseau

Qu’est-ce qui cause la perte de quorum en pratique ?

• Partitions réseau, en particulier « le TCP marche mais pas corosync » (mismatch MTU, règles de pare-feu, routage asymétrique)
• Nœud hors service (planifié ou non) et cluster dimensionné de sorte à perdre la majorité
• Dérive horaire provoquant l’instabilité de l’adhésion
• Modifications partielles ou incorrectes de la config corosync

Guidance opérationnelle : si vous êtes dans un cluster à deux nœuds sans briseur d’égalité, vous vivez dangereusement. Ça peut fonctionner, mais le mode de défaillance est exactement celui que vous déboguez.

Ensemble C : permissions et problèmes de chemin d’accès

Les permissions sont le lot le moins excitant, mais ils sont fréquents dans les organisations avec automatisation, jetons API et changements « temporaires » qui deviennent permanents.

Cas typiques :

• Vous n’êtes pas root (ou votre outil n’utilise pas sudo) et vous tentez d’écrire la config du cluster.
• Un jeton API n’a pas le rôle/les privilèges requis pour modifier certains objets.
• Quelqu’un a modifié manuellement la propriété/le mode sous /etc/pve (oui, c’est possible ; non, ce n’est pas une passe-temps judicieuse).
• Sémantiques de verrou obsolète : pas des verrous classiques UNIX, mais des états de « lock » Proxmox (backup, snapshot, migration) qui empêchent les écritures de conf VM.

La distinction diagnostique clé est le texte d’erreur :

• Permission denied tend à pointer vers acteur/ACL/propriété.
• Read-only file system tend à pointer vers le gating quorum/pmxcfs ou un remontage RO du système OS.
• No space left on device indique soit disque OS soit parfois une manifestation d’épuisement d’une ressource sous-jacente.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : l’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox à trois nœuds sur un site distant. Une mise à jour de firmware de commutateur était programmée à 2h du matin, parce que bien sûr. Le plan : mettre à jour un commutateur à la fois, s’appuyer sur des uplinks redondants, pas de downtime. Classique.

L’hypothèse erronée était subtile : « Si le ping marche, corosync marchera ». Après le redémarrage du premier commutateur, le réseau de gestion restait joignable. SSH fonctionnait. Le monitoring montrait les nœuds « up ». Mais le trafic corosync passait sur un VLAN différent avec un MTU différent, et le nouveau firmware avait un comportement de jumbo-frames légèrement différent par défaut. Pas assez cassé pour perdre tout le trafic — juste assez pour provoquer une perte de paquets intermittente sur les trames plus grosses.

Une demi-heure plus tard, l’astreinte a tenté de créer une VM pour une charge urgente. L’interface a échoué : unable to write /etc/pve/nodes/.... Ils ont fait ce que font beaucoup de personnes intelligentes sous stress : ils ont supposé que c’était local. Ils ont nettoyé le disque, redémarré pve-cluster, et même rebooté un nœud. Ça n’a rien amélioré. Pire : cela a aggravé le flapping d’adhésion parce que le cluster se réélisait constamment pendant que le réseau était instable.

La réparation n’était pas Proxmox. La réparation consistait à rendre corosync fiable à nouveau : aligner le MTU bout en bout, confirmer la stabilité des liens knet, et ensuite laisser le quorum se stabiliser. Une fois le quorum stable, /etc/pve est redevenu modifiable instantanément — sans retouches de permissions ni magie de configuration.

La leçon : ne diagnostiquez pas un système distribué comme une seule machine. « Je peux SSH » est un seuil faible. Le trafic de quorum a des exigences plus strictes que votre session terminal.

Mini-récit 2 : l’optimisation qui s’est retournée contre eux

Une autre organisation voulait des basculements plus rapides. Ils ont affiné agressivement : timeouts corosync plus courts, détection de panne plus sensible, et un chemin réseau « léger ». Ils ont aussi consolidé le trafic du cluster sur les mêmes interfaces utilisées pour la réplication de stockage parce que « tout est en 10GbE, que pourrait-il mal se passer ? »

Tout fonctionnait parfaitement par temps calme. Puis les sauvegardes mensuelles ont démarré et le trafic de réplication a explosé. Les interfaces étaient saturées au point d’introduire du jitter. Corosync n’a pas besoin de beaucoup de bande passante, mais il déteste la latence imprévisible. L’adhésion a commencé à flapper. Le quorum tombait brièvement, revenait, puis retombait. Les opérateurs ne voyaient pas « réseau en panne » ; ils voyaient « Proxmox ne peut pas écrire la config ».

La déconvenue était opérationnelle, pas théorique. À chaque perte de quorum, pmxcfs cessait d’accepter les écritures. Les changements via l’interface s’appliquaient partiellement, puis étaient annulés. L’automatisation qui supposait de l’idempotence a commencé à thrash : « set storage », « fail », « retry », créant une tempête de tâches et de logs. Ce torrent de logs, à son tour, a poussé le nœud vers la pression disque. Une optimisation propre est devenue une défaillance multi-couches.

La solution finale était ennuyeuse : séparer le trafic corosync des flux lourds, revenir à des timeouts raisonnables, et traiter la stabilité du quorum comme un SLO de première classe. Le cluster a été légèrement « plus lent » à déclarer une panne, et bien plus rapide à récupérer en sécurité.

Leçon : en HA, la vitesse est une fonctionnalité seulement quand vous pouvez vous la permettre. Si vous achetez la vitesse en réduisant les marges de sécurité, vous paierez plus tard — avec intérêts.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Un environnement proche du secteur de la santé (assez régulé pour rendre prudent) faisait tourner Proxmox sur trois nœuds, avec un quatrième petit nœud « témoin » pour les votes de quorum. Rien de fancy. Ils avaient aussi une habitude que les ingénieurs aiment moquer : un runbook écrit avec des « pré-contrôles » et des « conditions d’arrêt ».

Un après-midi, un contrôleur de stockage a commencé à renvoyer des erreurs intermittentes. L’OS a remonté un système de fichiers en lecture seule sur un nœud. Ce nœud restait joignable, mais les services se dégradaient. L’astreinte a vu unable to write /etc/pve/... en essayant de désactiver une tâche planifiée. Au lieu de redémarrer tout de force, ils ont suivi le runbook : vérifier dmesg, l’état de montage, le quorum, et la santé disque. Le runbook les a forcés à prouver ou infirmer chaque ensemble.

En quelques minutes, ils ont réalisé que ce n’était pas le quorum. Le cluster était quoré ; pmxcfs allait bien. Le système de fichiers local était en lecture seule à cause d’erreurs détectées par le noyau. Cela a changé la réponse : évacuer les VM de ce nœud, le cordonner, et engager le remplacement matériel. Ils n’ont pas « réparé les permissions » et n’ont pas risqué de corrompre l’état du cluster.

Le lendemain, le rapport d’incident était ennuyeux. C’est un compliment. La raison pour laquelle c’était ennuyeux, c’est qu’ils ont traité « impossible d’écrire /etc/pve » comme un symptôme, pas comme un diagnostic, et ils avaient un chemin discipliné pour isoler la cause.

Leçon : la checklist ennuyeuse n’est pas de la bureaucratie. C’est une fonctionnalité de fiabilité.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « Read-only file system » en touchant /etc/pve

Cause racine : Cluster non quoré, ou pmxcfs refuse intentionnellement les écritures.

Correction : Rétablir le quorum (réseau, adhésion corosync). Vérifier pvecm status affiche Quorate: Yes. Ne résolvez pas ça avec un chmod.

2) Symptom : les sauvegardes GUI échouent, la CLI en root échoue aussi

Cause racine : pmxcfs bloque les écritures (quorum) ou pmxcfs est dégradé ; plus rarement le système de fichiers OS est en lecture seule.

Correction : Vérifier findmnt /etc/pve pour ro, consulter journalctl -u pve-cluster, et vérifier dmesg pour des remontages en lecture seule.

3) Symptom : « Permission denied » seulement dans la GUI ou l’automatisation, mais root sur SSH peut éditer

Cause racine : Jeton API / rôle utilisateur sans permissions ; ou automatisation non-root sans sudo approprié.

Correction : Auditez les rôles/ACLs et confirmez l’identité. Re-tentez la même action avec pvesh en root pour isoler la différence de chemin d’accès.

4) Symptom : une seule configuration de VM ne se met pas à jour ; les autres passent

Cause racine : La VM est verrouillée (backup, snapshot, migration), ou un état de verrou obsolète existe.

Correction : Vérifiez l’état de lock de la VM dans la config et la liste des tâches ; résolvez la tâche sous-jacente. Évitez la suppression manuelle du verrou sauf si vous êtes sûr que l’opération est morte et ne reprendra pas.

5) Symptom : les erreurs ont commencé après un reboot / maintenance du nœud

Cause racine : Le nœud est revenu isolé (trunk VLAN manquant, règle de pare-feu, mauvaise interface), donc il a perdu le quorum et pmxcfs est passé en lecture seule.

Correction : Validez les interfaces corosync, le tagging VLAN, le MTU et la joignabilité des pairs avant de toucher aux services Proxmox.

6) Symptom : « No space left on device » en écrivant /etc/pve

Cause racine : Système root ou inodes épuisés ; parfois un log storm ou spool de sauvegarde en fuite.

Correction : Libérez l’espace/inodes en toute sécurité, puis revérifiez. Ne supprimez pas d’emblée les fichiers d’état du cluster.

7) Symptom : /etc/pve est absent ou vide

Cause racine : pve-cluster/pmxcfs non monté ; ou montage échoué au démarrage.

Correction : Démarrez/réparez pve-cluster ; vérifiez pourquoi il a échoué dans les logs. Confirmez que FUSE fonctionne et que les dépendances de service sont saines.

8) Symptom : capacité d’écrire intermittente ; ça marche pendant une minute puis échoue

Cause racine : quorum qui flappe à cause de jitter réseau, MTU non aligné, liens corosync surchargés ou timeouts agressifs.

Correction : Stabilisez le transport corosync. Réduisez la contention. Ne tunez pas les timeouts pour la « vitesse » sans mesurer le jitter sous charge.

Listes de contrôle / plan étape par étape (séquence sûre)

Checklist A : vous venez de voir « unable to write /etc/pve/* » et vous voulez la vérité vite

1. Confirmez le montage et le mode : findmnt /etc/pve. Si absent → problème de service/montage ; si ro → quorum/pmxcfs probable.
2. Confirmez le quorum : pvecm status. Si pas quoré, ne perdez pas de temps sur les permissions.
3. Confirmez les services : systemctl status pve-cluster corosync.
4. Vérifiez les logs : journalctl -u pve-cluster -u corosync --since "30 min ago".
5. Écartez la pression disque : df -h, df -i, et dmesg pour les remontages RO.
6. Reproduisez avec une écriture inoffensive : touch /etc/pve/.diag-write-test et interprétez le message d’erreur précis.
7. Prenez une décision : si le quorum est perdu, réparez le réseau/quorum. Si le disque est HS, évacuez le nœud. Si ce sont des permissions, corrigez identité/ACL.

Checklist B : si le quorum est perdu, décidez de votre posture opérationnelle (n’improvisez pas)

1. Est-ce une vraie partition réseau ou juste un nœud down ? Déterminez si les pairs sont joignables et si le nœud down est attendu.
2. Avez-vous la majorité quelque part ? Dans un cluster à 3 nœuds, un nœud isolé n’a pas le quorum ; les deux autres l’ont probablement.
3. Préférez réparer la connectivité plutôt que forcer des écritures. « Forcer » est un dernier recours car cela peut créer des états divergents.
4. Stabilisez le chemin réseau : vérifiez VLANs, MTU, règles de pare-feu ; contrôlez la saturation des liens corosync.
5. Après le retour du quorum : retentez les écritures. Ne redémarrez pas les services sauf si vous avez une raison claire.

Checklist C : si c’est disque/plein/RO, traitez comme un incident de stockage

1. Confirmez l’état du disque : dmesg et l’état SMART/RAID.
2. Si le système de fichiers est RO à cause d’erreurs : arrêtez de « réparer Proxmox ». Évacuez les workloads si possible. Planifiez la réparation.
3. Si c’est juste plein : nettoyez l’espace en toute sécurité (rotation des logs, suppression de sauvegardes, suppression des ISO inutilisés). Évitez de supprimer l’état Proxmox.
4. Revérifiez les services et le comportement de /etc/pve après le retour de capacité. Les incidents de capacité se propagent souvent.

Checklist D : si ce sont les permissions, corrigez le plus petit truc qui fonctionne

1. Confirmez l’identité et le contexte d’exécution (id, sudo -l, rôles de jeton API).
2. Ne faites pas de chmod/chown récursif sur /etc/pve. C’est comme ça qu’on crée des permissions mystères.
3. Corrigez les rôles/ACL au niveau Proxmox (utilisateurs, groupes, rôles) plutôt que de bidouiller les fichiers.
4. Validez en relançant l’action échouée et en confirmant que les logs/audits montrent la réussite.

FAQ

1) Pourquoi Proxmox met-il la config du cluster dans /etc/pve plutôt que dans une base de données ?

Parce que les fichiers sont une interface universelle. Outils, scripts et administrateurs peuvent les lire facilement, faire des diffs et les sauvegarder. pmxcfs offre la sémantique « fichiers » tout en gérant la synchronisation et le contrôle d’accès du cluster.

2) Si /etc/pve est virtuel, pourquoi mon disque local a-t-il de l’importance ?

Parce que l’OS, les services, les logs et l’état runtime dépendent toujours du disque local. Disques pleins ou remontages en lecture seule déstabilisent les services qui maintiennent pmxcfs en bonne santé.

3) Quelle est la façon la plus rapide de distinguer quorum vs permissions ?

Exécutez pvecm status et faites un touch inoffensif sous /etc/pve. « Quorate: No » ou « Read-only file system » pointe fortement vers le quorum/pmxcfs. « Permission denied » pointe vers permissions/identité.

4) Puis-je simplement redémarrer pve-cluster pour corriger ça ?

Parfois, mais ce n’est pas le premier geste. Si le quorum est perdu, redémarrer pve-cluster ne créera pas des voix ex nihilo. Si le système de fichiers OS est en lecture seule, les redémarrages sont du spectacle. Lisez d’abord les logs ; décidez en fonction des preuves.

5) Pourquoi les changements via l’interface échouent mais l’édition par SSH semble marcher (ou inversement) ?

Parce que la GUI utilise l’API avec sa propre modélisation des permissions et peut échouer sur des ACL alors que votre session SSH root peut écrire. Ou inversement : root ne peut pas écrire car pmxcfs est en lecture seule, et la GUI affiche une erreur d’écriture générique.

6) Un cluster à deux nœuds est-ce une mauvaise idée ?

C’est fragile à moins d’ajouter un troisième vote (qdevice/témoin) ou d’accepter que la perte d’un nœud puisse retirer le quorum et bloquer les écritures. Deux nœuds peuvent fonctionner, mais le mode de défaillance est précisément celui que vous dépannez.

7) Que protège exactement « pmxcfs rejettant les écritures quand pas de quorum » ?

La divergence de configuration en split brain : deux nœuds mettant à jour « avec succès » des configs VM, définitions de stockage ou règles de firewall en isolation. Quand la partition se résorbe, concilier ce désordre est pénible et parfois destructeur.

8) Puis-je forcer Proxmox à être modifiable sans quorum ?

Vous pouvez opérer en modes dégradés, mais c’est une procédure d’urgence délibérée, pas un interrupteur à manipuler à la légère. Le risque est de diverger l’état du cluster. Si vous devez le faire, documentez, minimisez les changements et planifiez un rejoignement propre.

9) Et si seules les écritures vers un chemin spécifique échouent, par exemple une config VM ?

Cherchez des verrous et l’état des tâches (backup/migration/snapshot) sur cette VM. Une incapacité d’écriture à l’échelle du cluster pointe généralement vers le quorum/pmxcfs ; les échecs sur un seul objet pointent vers des verrous/tâches ou un fichier de config corrompu.

10) Comment prévenir que cela se reproduise ?

Concevez pour la stabilité du quorum (nombre impair de voix, corosync réseau fiable), imposez l’hygiène de capacité disque (alertes sur espace et inodes), et standardisez l’accès privilégié (jetons API avec rôles explicites, automatisation qui utilise les privilèges corrects).

Conclusion : prochaines étapes qui préviennent les répétitions

« Unable to write /etc/pve/* » est Proxmox qui vous dit qu’il n’accepte pas de changements de configuration parce que quelque chose de fondamental est cassé ou dangereux. Votre travail est de classer rapidement la défaillance :

• Si le quorum est perdu : rétablissez la connectivité corosync et l’adhésion. Ne combattez pas pmxcfs ; il vous protège.
• Si le disque est plein ou lecture seule : traitez cela comme un incident de stockage. Libérez de l’espace en sécurité ou évacuez et réparez le matériel/système de fichiers.
• Si ce sont les permissions : corrigez l’identité, les rôles et les ACL au niveau Proxmox. Ne chmod/chown pas récursivement le cerveau du cluster.

Prochaines étapes pratiques pour le lundi matin (quand vous n’êtes pas en plein incident) :

1. Ajoutez du monitoring sur pvecm status (quorum), la santé de pve-cluster et la stabilité des liens corosync.
2. Alertez sur df -h et df -i pour / et /var. L’épuisement d’inodes est une panne furtive.
3. Utilisez un nombre impair de voix. Si vous devez opérer avec deux nœuds, ajoutez un témoin et traitez le réseau comme une infrastructure critique.
4. Rédigez un court runbook interne avec le « Playbook de diagnostic rapide » ci-dessus. Vous voulez que votre futur vous soit paresseux et correct.