Proxmox «imposible escribir /etc/pve/*»: disco, pmxcfs o permisos — cómo identificarlo

El modelo mental: qué es realmente /etc/pve

En Proxmox VE, /etc/pve no es «solo configuración en disco». Es un sistema de archivos virtual proporcionado por pmxcfs (Proxmox Cluster File System), montado vía FUSE. Se comporta como una base de datos de configuración compartida con semántica de sistema de archivos: archivos y directorios, actualizaciones atómicas, permisos y eventos inotify. Pero la verdad debajo es más bien «máquina de estado de cluster más replicación» que «una carpeta».

Este hecho explica la mayoría de las rarezas:

• Si pmxcfs está inestable o en solo lectura, los escritos en /etc/pve fallan aunque tu sistema raíz tenga espacio libre.
• Si el cluster pierde quorum, pmxcfs suele volverse de solo lectura para protegerte contra split brain. El error parece de sistema de archivos porque así interactúas con él.
• Si los permisos están mal, puedes ser root en el nodo y aún recibir una denegación dependiendo de cómo escribas y en qué contexto estés (token API, usuario, propiedad del archivo o un patrón de bloqueo obsoleto).

Así que cuando veas «unable to write /etc/pve/*», no te lances inmediatamente a la danza clásica de Linux de chown -R y chmod -R. Ahí es donde la gente convierte un problema manejable en un proyecto de recuperación.

Traducción operativa:

• Problema de disco significa que el almacenamiento del que depende pmxcfs está sin espacio o es inestable (típicamente el sistema raíz local para logs/estado, o peor: corrupción, remonte en solo lectura, errores de I/O).
• Problema de pmxcfs/quorum significa que el estado/membresía del cluster no es escribible; tu nodo puede haber perdido quorum, corosync estar fallando o pve-cluster estar atascado.
• Problema de permisos significa que el agente que escribe (usuario CLI, usuario/token API, proceso de servicio) no puede escribir, o existe un archivo bloqueado/obsoleto que provoca la falla.

Una cita operativa que vale la pena tener pegada en el monitor: «idea parafraseada» de Werner Vogels (CTO de Amazon): Construyes, lo operas; la retroalimentación de operaciones es parte de la ingeniería. El punto: no solo «arregles la escritura», arregla la razón por la que el sistema decidió que escribir era inseguro.

Guía rápida de diagnóstico (primero/segundo/tercero)

Primero: confirma qué está haciendo /etc/pve ahora mismo (segundos)

1. ¿Está pmxcfs montado y escribible? Comprueba el tipo de montaje y si está en modo solo lectura.
2. ¿El cluster tiene quorum? Si no, espera comportamiento de solo lectura.
3. ¿Están los servicios sanos? Específicamente pve-cluster y corosync.

Segundo: descarta los asesinos aburridos (minutos)

1. ¿Disco lleno en / o /var? La presión de disco rompe todo de forma indirecta.
2. ¿Sistema de archivos remontado en solo lectura? Un tropiezo de I/O y tus escrituras están condenadas.
3. ¿Presión de memoria? pmxcfs mantiene metadatos en RAM; presión extrema puede producir síntomas extraños.

Tercero: verifica el actor y la ruta de escritura específica (minutos)

1. ¿Estás escribiendo vía GUI/token API? El modelo de permisos difiere de «root por SSH».
2. ¿Hay un archivo de bloqueo o una configuración obsoleta? Los locks de VM y tareas de replicación pueden mantener las cosas bloqueadas.
3. ¿Este nodo es «especial»? Desajuste de tiempo, pérdida de red o modo de cluster de nodo único pueden cambiar el comportamiento.

Si estás en una caída real: no reinicies todo a ciegas. Reiniciar corosync en el lado equivocado de una partición es como probar a ver qué sabe el split brain.

Broma #1: pmxcfs es como un chat grupal: si la mitad del equipo no ve los mensajes, nadie puede editar el post fijado.

Hechos interesantes & contexto histórico (por qué se comporta así)

• Hecho 1: /etc/pve es un montaje FUSE provisto por pmxcfs, no un directorio normal en disco. Por eso los errores «de sistema de archivos» son en realidad errores de estado del cluster disfrazados.
• Hecho 2: Proxmox usa Corosync para membresía de cluster y decisiones de quorum; pmxcfs usa eso para decidir cuándo es seguro aceptar escrituras.
• Hecho 3: El comportamiento «solo lectura si no hay quorum» es una característica de seguridad contra split brain. Es molesto hasta que te salva de tener dos nodos con configuraciones en conflicto.
• Hecho 4: pmxcfs mantiene gran parte de la configuración del cluster en memoria y la sincroniza; perder pmxcfs no es lo mismo que perder todo el sistema de archivos del SO.
• Hecho 5: Históricamente, los sistemas de archivos de cluster en stacks de virtualización han tendido a un control de escritura conservador. El modelo de VMware vCenter y muchas pilas HA también favorecen «parar escrituras» cuando la membresía es incierta.
• Hecho 6: La decisión de diseño de Proxmox —hacer que la configuración del cluster parezca archivos— facilita la automatización (editar un archivo, ejecutar un comando), pero también hace que los modos de falla parezcan engañosamente «a la Unix».
• Hecho 7: Muchas fallas de escritura en Proxmox son efectos secundarios: disco lleno detiene logs, servicios entran en bucle, quorum se altera y de repente /etc/pve parece roto aunque el problema real sea capacidad.
• Hecho 8: La deriva de tiempo puede desestabilizar la membresía de corosync en redes marginales. En clusters, el tiempo es una dependencia como la energía y el enfriamiento —solo que más silenciosa.

Tareas de triaje: comandos, salidas y decisiones (12+)

Estos son los comandos que realmente ejecuto cuando la producción está en llamas. Cada tarea incluye qué buscas, qué significa la salida y qué decisión tomar después.

Task 1: confirm /etc/pve es un montaje 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)

Significado: Esperas type fuse.pve. Si falta, pmxcfs no está montado (pve-cluster caído o atascado).

Decisión: Si falta, salta a comprobaciones de servicios (pmxcfs/quorum) y logs. Si está pero con ro, trátalo como un problema de quorum o estado de pmxcfs.

Task 2: prueba la ruta de escritura sin causar daños

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

Significado: «Read-only file system» suele ser pmxcfs negando escrituras (a menudo por quorum). «Permission denied» es actor/ACL. «No such file» indica que el montaje desapareció.

Decisión: Solo lectura → comprobar quorum y pve-cluster; permiso denegado → comprobar usuario/contexto API; no existe → pmxcfs no montado.

Task 3: comprobar rápidamente el estado de 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

Significado: Quorate: No es tu pista decisiva. pmxcfs puede pasar a solo lectura para prevenir divergencia.

Decisión: Arregla la conectividad de corosync/quorum antes de intentar «arreglar permisos» o reiniciar servicios al azar.

Task 4: ver quién cree corosync que está presente

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

Significado: Los anillos están activos localmente, pero eso no garantiza que los otros nodos sean alcanzables.

Decisión: Si los anillos locales muestran fallos, arregla NIC/VLAN/MTU primero. Si local parece bien pero quorum perdido, comprueba accesibilidad a pares y logs de corosync.

Task 5: comprobar la vista de membresía del 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

Significado: Total votes 1 implica que estás aislado. Esto no es un problema de «disco lleno». Es un problema de red/membresía del cluster.

Decisión: Deja de intentar hacer escrituras. Restaura la conectividad o toma una decisión deliberada sobre operar en modo nodo único temporalmente.

Task 6: comprobar estado del servicio 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

Significado: Si está inactivo/fallado, /etc/pve o no se montará o estará obsoleto.

Decisión: Si falló, lee logs antes de reiniciar. Si está en ejecución pero /etc/pve es RO, céntrate en quorum/estado más que en reiniciar servicios.

Task 7: lee los logs relevantes, no todos los logs

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

Significado: pmxcfs está rechazando escrituras explícitamente por pérdida de quorum. Esa es la historia completa.

Decisión: Ve a arreglar la membresía de corosync. Si esto es una partición por mantenimiento planificado, usa un procedimiento planificado (ver listas de verificación).

Task 8: descartar agotamiento simple de disco

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

Significado: 100% del sistema raíz es un generador de incidencias. Los servicios fallan de maneras creativas. pmxcfs puede montarse, pero otros componentes no pueden escribir estado/logs.

Decisión: Libera espacio inmediatamente (logs, caches), luego revisa servicios y comportamiento de /etc/pve. No empieces pensando «el cluster está roto» si el nodo no puede escribir en /.

Task 9: comprobar agotamiento de inodos (sí, todavía ocurre)

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

Significado: Puedes tener gigabytes libres y aún así no poder crear archivos nuevos. Algunas fallas de escritura emergen como «unable to write» y parecen de permisos.

Decisión: Encuentra el hog de inodos (a menudo archivos pequeños bajo /var/lib o /var/log) y limpia con seguridad. Luego reintenta escrituras en /etc/pve.

Task 10: detectar remonte en solo lectura por errores de 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

Significado: El sistema de archivos del SO está en solo lectura. No puedes confiar en ningún comportamiento de escritura, incluyendo servicios que gestionan /etc/pve.

Decisión: Para. Arregla el almacenamiento/hardware subyacente o recupera el sistema de archivos. Un error de escritura de configuración de cluster no es el problema real aquí.

Task 11: confirmar opciones de montaje 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

Significado: Si muestra ro, es una decisión de bloqueo (quorum o estado de pmxcfs) o un modo de fallo de montaje.

Decisión: ro + quorate=no → arregla quorum. ro + quorate=yes → indaga en la salud de pmxcfs y sus logs.

Task 12: validar que el nodo ve a sus pares (comprobación de red)

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

Significado: Que ping funcione no implica que corosync funcione, pero si ping falla normalmente has encontrado la razón de votos perdidos.

Decisión: Si ping falla, arregla L2/L3 primero. Si ping funciona, investiga MTU, multicast/UDPU, reglas de firewall o especificidades del transporte knet.

Task 13: buscar archivos de bloqueo que afecten escrituras de configuración

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

Significado: Estás comprobando propiedad y permisos por configuración de VM. Lo normal suele ser root:www-data con modo restrictivo.

Decisión: Si ves propiedad extraña (user:user) o bits world-writable, no «arregles» a ciegas—averigua qué lo escribió así. Si faltan archivos, puede indicar un montaje o problema de sincronización.

Task 14: reproducir la falla con una escritura controlada vía la capa API

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

Significado: Si el error es «Permission denied» vía pvesh, puede que estés en un shell no-root o usando un token API con privilegios insuficientes.

Decisión: Confirma tu identidad y roles. Si eres root y aún hay denegación, busca daño en ACL/propiedad o un problema de permisos en pmxcfs.

Task 15: confirma quién eres (importa más de lo que crees)

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

Significado: «grupo sudo» no es «root». Si tu herramienta no usó sudo, no eres root. Proxmox frecuentemente espera escrituras a nivel root para configuración de cluster.

Decisión: Usa sudo -i para acciones administrativas o arregla tu automatización para que ejecute con los privilegios correctos.

Task 16: comprobar si el sistema raíz está lo bastante sano para confiar

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!

Significado: Si el disco está fallando, olvida todo lo demás. Podrías estar persiguiendo «errores de permisos» causados por fallos de I/O.

Decisión: Prioriza la seguridad de los datos: evacua cargas si es posible, reemplaza el disco y luego arregla el software. La fiabilidad vence a la astucia.

Broma #2: Los errores de permisos son el equivalente laboral de una tarjeta de acceso que deja de funcionar justo cuando llevas café.

Tres grandes categorías: disco, pmxcfs/quorum, permisos

Bucket A: problemas de disco y sistema de archivos del SO

Los problemas de disco se manifiestan de dos formas: capacidad (bloques/inodos llenos) e integridad (errores de I/O que causan remonte en solo lectura). Ambas pueden producir «unable to write /etc/pve/*» porque los componentes de Proxmox necesitan disco local para funcionar incluso si /etc/pve en sí es virtual.

Cadenas comunes impulsadas por disco:

• / lleno → servicios se comportan mal → servicios de cluster hacen flap → pmxcfs se vuelve inestable. Esto ocurre más de lo que la gente admite.
• Remonte en solo lectura → pve-cluster puede seguir en ejecución pero no puede persistir estado/logs. Ves fallos de escritura, pero la solución es almacenamiento, no Proxmox.
• Agotamiento de inodos → tormenta de archivos pequeños (logs de contenedor, colas de backup, spool de monitorización) → las escrituras de configuración fallan indirectamente.

Qué no hacer: no «resuelvas» disco lleno borrando archivos aleatorios bajo /var/lib/pve-cluster o cualquier cosa que huela a estado de cluster. Limpia logs, rota, poda backups, elimina ISOs abandonadas y luego reevalúa.

Bucket B: pmxcfs y quorum (el clásico)

Si tu nodo no tiene quorum, Proxmox a menudo te hace un favor negando escrituras. La configuración del cluster debe mantenerse consistente. Si múltiples nodos pudieran escribir configuraciones divergentes durante una partición, terminarías con dos realidades incompatibles. Eso no es «alta disponibilidad». Eso es «alto drama».

Indicadores clave de que este es tu bucket:

• pvecm status muestra Quorate: No
• journalctl -u pve-cluster menciona pérdida de quorum, rechazando escrituras
• /etc/pve está montado pero en solo lectura
• Los cambios en la GUI fallan en general: crear VM, editar almacenamiento, editar red

¿Qué causa pérdida de quorum en la vida real?

• Particiones de red, especialmente «funciona TCP pero no corosync» (desajustes de MTU, reglas de firewall, enrutamiento asimétrico)
• Nodo caído (planificado o no) y cluster dimensionado de forma que pierdes la mayoría
• Deriva de tiempo que causa inestabilidad de membresía
• Cambios de configuración de corosync aplicados parcial o incorrectamente

Guía operativa: si tienes un cluster de dos nodos sin desempate, estás viviendo peligrosamente. Puede funcionar, pero el modo de fallo es exactamente este: un nodo se va y el otro rechaza escrituras. No es un bug; es matemáticas.

Bucket C: permisos y problemas de la vía de acceso

Los permisos son la categoría menos emocionante, pero comunes en entornos con automatización, tokens API y cambios «temporales» que se vuelven permanentes.

Casos típicos:

• No eres root (o tu herramienta no usa sudo) y tratas de escribir configuración de cluster.
• Un token API no tiene el rol/privilegios necesarios para modificar objetos específicos.
• Alguien cambió propiedad/modo bajo /etc/pve manualmente (sí, es posible; no, no es un pasatiempo).
• Semánticas de lock obsoletas: no locks clásicos de UNIX, sino estados de «lock» en Proxmox (backup, snapshot, migración) que impiden escribir la conf de la VM.

La distinción diagnóstica clave es el texto del error:

• Permission denied tiende a ser actor/ACL/propiedad.
• Read-only file system tiende a ser gating por quorum/pmxcfs o remonte RO del SO.
• No space left on device es o bien disco del SO o a veces manifestación de agotamiento de recursos subyacente.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: el incidente causado por una suposición errónea

Tenían un cluster Proxmox de tres nodos en un sitio remoto. Se programó una actualización de firmware de un switch a las 2 a.m., porque por supuesto. El plan: actualizar un switch a la vez, confiar en uplinks redundantes, sin downtime. Clásico.

La asunción errónea fue sutil: «Si ping funciona, corosync funcionará». Tras el reinicio del primer switch, la red de gestión siguió accesible. SSH funcionaba. El monitoring mostraba los nodos «arriba». Pero el tráfico de corosync circulaba por otra VLAN con MTU distinto, y el nuevo firmware había cambiado por defecto el comportamiento de jumbo frames. No lo rompió todo, solo lo suficiente para producir pérdida intermitente de paquetes en tramas grandes.

Media hora después, el on-call intentó crear una VM urgente. La GUI falló: unable to write /etc/pve/nodes/.... Hicieron lo que muchos hacen bajo estrés: asumieron que era local. Limpiaron disco, reiniciaron pve-cluster, incluso rebootearon un nodo. No ayudó. De hecho, empeoró la inestabilidad de membresía porque el cluster seguía reelectando mientras la red era inestable.

La solución no fue Proxmox. Fue restaurar la fiabilidad de corosync: alinear MTU end-to-end, confirmar estabilidad del enlace knet y solo entonces dejar que el quorum se estabilizara. Una vez estable, /etc/pve fue escribible al instante—sin tocar permisos, sin vudú de configuración.

La lección: no diagnostiques un sistema distribuido como si fuera una sola caja. «Puedo SSH» es un umbral bajo. El tráfico de quorum tiene requisitos más estrictos que tu sesión de terminal.

Micro-historia 2: la optimización que salió mal

Otra organización quería failovers más rápidos. Ajustaron agresivamente: timeouts de corosync más cortos, detección de fallo más sensible y una ruta de red «delgada». Además consolidaron tráfico de cluster en las mismas interfaces usadas para replicación de almacenamiento porque «todo es 10GbE, ¿qué podría salir mal?».

Funcionó maravillosamente en calma. Entonces empezaron los backups mensuales y el tráfico de replicación se disparó. Las interfaces se saturaron lo suficiente para introducir jitter. Corosync no necesita mucho ancho de banda, pero odia la latencia impredecible. La membresía empezó a hacer flap. El quorum caía y volvía, caía otra vez. Los operadores no vieron «red caída»; vieron «Proxmox no puede escribir configuración».

El contratiempo fue operativo, no teórico. Cada vez que el quorum caía, pmxcfs dejaba de aceptar escrituras. Los cambios via GUI se aplicaban parcialmente y luego se revertían. La automatización que asumía idempotencia empezó a agitar tareas: «set storage», «fail», «retry», creando una tormenta de tareas y logs. Esa tormenta de logs, a su vez, empujó al nodo más cerca de presión de disco. Una optimización ordenada se convirtió en un fallo multinivel.

La solución final fue aburrida: separar el tráfico de corosync de los flujos pesados, revertir tiempos a valores sensatos y tratar la estabilidad de quorum como un SLO de primera clase. El cluster se volvió un poco «más lento» en declarar fallos y mucho más rápido para recuperarse con seguridad.

Lección: en HA, la velocidad es una característica solo cuando puedes permitirla. Si compras velocidad reduciendo márgenes de seguridad, lo pagarás después—con intereses.

Micro-historia 3: la práctica aburrida pero correcta que salvó el día

Un entorno similar a salud (lo bastante regulado para ser cauteloso) ejecutaba Proxmox en tres nodos, con un cuarto nodo pequeño «testigo» para voto de quorum. Nada sofisticado. También tenían una costumbre que a los ingenieros les encanta burlarse: un runbook escrito con «pre-checks» y «condiciones de parada».

Una tarde, un controlador de almacenamiento empezó a lanzar errores intermitentes. El SO remontoó un sistema de archivos en solo lectura en un nodo. Ese nodo siguió accesible, pero los servicios se degradaron. El on-call vio unable to write /etc/pve/... al intentar deshabilitar una tarea programada. En vez de reiniciar todo a la fuerza, siguieron el runbook: comprobar dmesg, estado de montajes, quorum, salud del disco. El runbook les obligó a probar o descartar cada categoría.

En minutos, se dieron cuenta de que no era quorum. El cluster estaba cuorate; pmxcfs bien. El sistema local estaba en solo lectura por errores detectados por el kernel. Eso cambió la respuesta: evacuar VMs de ese nodo, marcarlo como cordonado y proceder con sustitución de hardware. No «arreglaron permisos» ni arriesgaron corromper estado de cluster.

Al día siguiente, el informe del incidente fue aburrido. Eso es un cumplido. Fue aburrido porque trataron «unable to write /etc/pve» como síntoma, no como diagnóstico, y siguieron un camino disciplinado para aislar la causa.

Lección: la lista de verificación aburrida no es burocracia. Es una característica de fiabilidad.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: «Read-only file system» al tocar /etc/pve

Causa raíz: Cluster sin quorum, o pmxcfs rechazando escrituras intencionalmente.

Solución: Restaurar quorum (red, membresía de corosync). Verificar que pvecm status muestre Quorate: Yes. No uses chmod para salir del paso.

2) Síntoma: la GUI no guarda, la CLI como root también falla

Causa raíz: pmxcfs bloqueando escrituras (quorum) o pmxcfs no saludable; menos común, sistema de archivos del SO en solo lectura.

Solución: Comprobar findmnt /etc/pve por ro, revisar journalctl -u pve-cluster, revisar dmesg por remontes en solo lectura.

3) Síntoma: «Permission denied» solo en GUI o automatización, pero root por SSH puede editar

Causa raíz: Token API / rol de usuario sin permisos; o automatización ejecutándose como no-root sin sudo.

Solución: Auditar roles/ACLs y confirmar identidad. Reejecutar la misma acción con pvesh como root para aislar diferencias de vía de acceso.

4) Síntoma: solo una configuración de VM no se actualiza; las demás sí

Causa raíz: VM bloqueada (backup, snapshot, migración), o estado de lock obsoleto.

Solución: Comprobar estado de lock de la VM en la configuración y la lista de tareas; resolver la tarea subyacente. Evitar eliminar locks manualmente a menos que estés seguro de que la operación terminó y no se reanudará.

5) Síntoma: errores empezaron tras reinicio/maintenance del nodo

Causa raíz: Nodo arrancó aislado (trunk VLAN faltante, regla de firewall, interfaz equivocada), por lo que perdió quorum y pmxcfs pasó a solo lectura.

Solución: Validar interfaces de corosync, etiquetado VLAN, MTU y accesibilidad a peers antes de tocar servicios de Proxmox.

6) Síntoma: «No space left on device» al escribir en /etc/pve

Causa raíz: Sistema raíz o agotamiento de inodos; a veces tormenta de logs o spool de backup descontrolado.

Solución: Liberar espacio/inodos de forma segura y volver a comprobar. No borres archivos de estado del cluster como primer movimiento.

7) Síntoma: /etc/pve falta o está vacío

Causa raíz: pve-cluster/pmxcfs no montado; o fallo de montaje durante el arranque.

Solución: Arrancar/reparar pve-cluster; revisar por qué falló en los logs. Confirmar que FUSE funciona y que las dependencias del servicio están sanas.

8) Síntoma: capacidad intermitente para escribir; funciona un minuto y luego falla

Causa raíz: quorum haciendo flap debido a jitter de red, desajuste de MTU, enlaces corosync saturados o timeouts agresivos.

Solución: Estabilizar transporte de corosync. Reducir la contención. No ajustes timeouts por «velocidad» sin medir jitter bajo carga.

Listas de verificación / plan paso a paso (secuencia segura)

Checklist A: acabas de ver «unable to write /etc/pve/*» y quieres la verdad rápido

1. Confirma montaje y modo: findmnt /etc/pve. Si falta → problema de servicio/montaje; si ro → probablemente gating por quorum/pmxcfs.
2. Confirma quorum: pvecm status. Si no hay quorum, no pierdas tiempo en permisos.
3. Confirma servicios: systemctl status pve-cluster corosync.
4. Revisa logs: journalctl -u pve-cluster -u corosync --since "30 min ago".
5. Descarta presión de disco: df -h, df -i y dmesg por remontes en solo lectura.
6. Reproduce con una escritura inofensiva: touch /etc/pve/.diag-write-test e interpreta el mensaje exacto de error.
7. Toma una decisión: si falta quorum, arregla red/quorum. Si disco muerto, evacua nodo. Si son permisos, arregla ACLs/identidad.

Checklist B: si falta quorum, decide tu postura operativa (no improvises)

1. ¿Es partición de red real o solo un nodo abajo? Determina si los peers son alcanzables y si el nodo caído es esperado.
2. ¿Tienes mayoría en algún lado? En un cluster de 3 nodos, un nodo aislado no tiene quorum; los otros dos probablemente sí.
3. Prefiere arreglar conectividad sobre forzar escrituras. «Forzar» es último recurso porque puede crear estado divergente.
4. Estabiliza la ruta de red: verifica VLANs, MTU, reglas de firewall; busca saturación en enlaces de corosync.
5. Tras recuperar quorum: reintenta las escrituras. No reinicies servicios salvo que tengas una razón clara.

Checklist C: si es disco/lleno/RO, trátalo como un incidente de almacenamiento

1. Confirma condición del disco: dmesg y estado SMART/RAID.
2. Si el sistema de archivos está RO por errores: deja de intentar «arreglar Proxmox». Evacua cargas si es posible. Planifica la reparación.
3. Si solo está lleno: limpia espacio de forma segura (rotar logs, podar backups, eliminar ISOs no usadas). Evita borrar estado de Proxmox.
4. Revisa servicios y comportamiento de /etc/pve tras recuperar capacidad. Incidentes de capacidad suelen encadenarse.

Checklist D: si son permisos, arregla lo mínimo necesario

1. Confirma identidad y contexto de ejecución (id, sudo -l, roles de token API).
2. No hagas chmod/chown recursivo en /etc/pve. Así es como creas permisos misteriosos.
3. Arregla roles/ACLs a nivel Proxmox (usuarios, grupos, roles) en lugar de trucos a nivel de archivo.
4. Valida re-ejecutando la acción fallida y confirmando que los logs/tareas de auditoría tienen éxito.

Preguntas frecuentes

1) ¿Por qué Proxmox guarda la configuración del cluster en /etc/pve en vez de una base de datos?

Porque los archivos son una interfaz universal. Herramientas, scripts y administradores pueden leerlos fácilmente, diferenciarlos y hacer backups. pmxcfs ofrece semántica de «archivos» mientras gestiona sincronización y control de acceso del cluster.

2) Si /etc/pve es virtual, ¿por qué importa mi disco local?

Porque el SO, los servicios, los logs y el estado en ejecución aún necesitan disco local. Discos llenos o remontes en solo lectura desestabilizan los servicios que mantienen pmxcfs en funcionamiento y saludables.

3) ¿Cuál es la forma más rápida de distinguir quorum vs permisos?

Ejecuta pvecm status y haz un touch inofensivo bajo /etc/pve. «Quorate: No» o «Read-only file system» apunta fuertemente a gating por quorum/pmxcfs. «Permission denied» apunta a permisos/identidad.

4) ¿Puedo simplemente reiniciar pve-cluster para arreglarlo?

A veces, pero no es el primer movimiento. Si falta quorum, reiniciar pve-cluster no creará votos de la nada. Si el sistema de archivos del SO está en solo lectura, los reinicios son teatro. Lee logs primero; decide según la evidencia.

5) ¿Por qué las modificaciones en la GUI fallan pero editar archivos por SSH parece funcionar (o al revés)?

Porque la GUI usa la API con su propio modelo de permisos y puede fallar en ACLs aunque tu sesión SSH como root pueda escribir. O al revés: root no puede escribir porque pmxcfs está en solo lectura, y la GUI muestra un error genérico.

6) ¿Es mala idea un cluster de dos nodos?

Es una idea frágil a menos que añadas un voto tercero (qdevice/testigo) o aceptes que perder un nodo puede quitar quorum y bloquear escrituras. Dos nodos pueden funcionar, pero el modo de fallo es exactamente el que estás depurando.

7) ¿Qué protege «pmxcfs rejecting writes while not quorate»?

Previene la divergencia por split brain: dos nodos actualizando configuraciones de VM, definiciones de almacenamiento o reglas de firewall aisladamente. Cuando la partición se sana, reconciliar ese conflicto es doloroso y a veces destructivo.

8) ¿Puedo forzar que Proxmox sea escribible sin quorum?

Puedes operar en modos degradados, pero es un procedimiento de emergencia deliberado, no un interruptor casual. El riesgo es divergir el estado del cluster. Si debes hacerlo, documenta, minimiza cambios y planifica una reincorporación limpia.

9) ¿Y si solo las escrituras a una ruta específica fallan, como la conf de una VM?

Busca locks y estado de tareas (backup/migración/snapshot) en esa VM. La incapacidad de escribir a nivel de cluster suele apuntar a quorum/pmxcfs; fallos en un solo objeto suelen ser locks/tareas o un archivo de configuración corrupto.

10) ¿Cómo prevengo que esto vuelva a ocurrir?

Diseña para estabilidad de quorum (número impar de votos, red corosync fiable), aplica higiene de capacidad en disco (alertas sobre espacio e inodos) y estandariza el acceso privilegiado (tokens API con roles explícitos, automatización con privilegios adecuados).

Conclusión: pasos para evitar recurrencias

«Unable to write /etc/pve/*» es Proxmox diciéndote que no aceptará cambios de configuración porque algo fundamental está mal o es inseguro. Tu trabajo es clasificar la falla rápidamente:

• Si falta quorum: arregla conectividad y membresía de corosync. No luches contra pmxcfs; te está protegiendo.
• Si el disco está lleno o en solo lectura: trátalo como un incidente de almacenamiento. Libera espacio de forma segura o evacua y repara hardware/sistemas de archivos.
• Si son permisos: arregla identidad, roles y ACLs a nivel Proxmox. No hagas chmod recursivos al cerebro del cluster.

Pasos prácticos para el lunes por la mañana (cuando no estás en medio de una caída):

1. Añade monitorización sobre pvecm status (quorum), salud de pve-cluster y estabilidad de enlaces corosync.
2. Alerta sobre df -h y df -i para root y /var. El agotamiento de inodos es una incidencia sigilosa.
3. Usa un número impar de votos. Si debes operar con dos nodos, añade un testigo de votos y trata la red como infraestructura crítica.
4. Escribe un runbook corto con la «Guía rápida de diagnóstico» arriba. Quieres que el futuro tú sea perezoso y correcto.