Guía de recuperación de la contraseña de Portainer-CE en OMV

SinEtiqueta

Una crónica en primera persona sobre cómo casi destruyo mi servidor doméstico intentando resetear una contraseña

Capítulo 1: El problema inocente

Todo comenzó un martes por la tarde. Necesitaba acceder a Portainer en mi OpenMediaVault (OMV) para gestionar unos contenedores, pero por más que intentaba, la contraseña no funcionaba. «No pasa nada», pensé, «un simple reset y listo».

Capítulo 2: La falsa seguridad del grupo root

Mi primer error fue asumir que ser usuario del grupo root en OMV me daba superpoderes. En la interfaz web de OMV, yo era administrador. En la terminal, tras añadir mi usuario al grupo root, me sentía invencible.

bash

# Creía que esto me hacía root
usermod -aG root mi_usuario

La realidad fue cruel: Linux no funciona así. Ser parte del grupo root no te da privilegios de superusuario. Necesitas sudo o convertirte realmente en root:

bash

# La realidad
sudo -i
# O
su -

Capítulo 3: El caos de los contenedores duplicados

Al investigar mi sistema, descubrí algo aterrador:

bash

docker ps -a | grep portainer

Había dos instancias de Portainer corriendo. ¿Cómo llegaron ahí? No lo sé. Pero ambas compartían el mismo volumen portainer_data. Esto explicaba por qué cada reset era inútil: una instancia pisaba los cambios de la otra.

Capítulo 4: La eliminación desesperada

Frustrado, decidí tomar medidas drásticas:

bash

# ¡Error! Esto detuvo TODOS mis contenedores
docker stop $(docker ps -aq)

# ¡Error mayor! Esto los eliminó a TODOS
docker rm $(docker ps -aq)

En mi defensa, estaba estresado. Pero las consecuencias fueron inmediatas: mi servidor de Jellyfin dejó de servir películas, mi instancia de Nextcloud dejó de sincronizar archivos, y mi reverse proxy dejó de funcionar.

Capítulo 5: La traición de las imágenes huérfanas

Tras el desastre, intenté limpiar las imágenes:

bash

# ¡CUIDADO CON ESTO!
docker image prune -a -f

Este comando eliminó imágenes «no utilizadas». El problema: algunas de mis contenedores usaban imágenes antiguas que no estaban etiquetadas como latest. Perdí la capacidad de recrear ciertos contenedores exactamente como estaban.

Capítulo 6: El misterio del puerto 9000

Con Portainer reinstalado, intenté acceder:

  • Intenté https://mi-omv:9443 – nada
  • Intenté https://mi-omv:9000 – nada
  • Intenté http://mi-omv:9443 – nada

La solución era simple pero contraintuitiva: Portainer por defecto usa HTTP en el puerto 9000:

text

http://mi-omv:9000

Una vez dentro, la pantalla de creación de usuario apareció milagrosamente.

Capítulo 7: El costo real

Después de 4 horas de trabajo, logré:

  1. Recuperar Portainer ✓
  2. Perder 3 contenedores críticos ✗
  3. Interrumpir servicios por 2 horas ✗
  4. Perder configuraciones personalizadas ✗

Los volúmenes de datos seguían intactos, pero las configuraciones de los contenedores (puertos mapeados, variables de entorno, redes) habían desaparecido.

Lecciones aprendidas (la manera difícil)

1. Nunca uses comandos de destrucción masiva

bash

# ❌ NUNCA HAGAS ESTO
docker stop $(docker ps -aq)
docker rm $(docker ps -aq)
docker system prune -a

# ✅ HAZ ESTO EN CAMBIO
docker stop nombre_contenedor
docker rm nombre_contenedor
docker image prune --filter "until=24h"

2. Etiqueta TODO como si tu vida dependiera de ello

bash

# Al crear contenedores
docker run -d \
  --name mi_contenedor \
  --label "backup=critical" \
  --label "owner=yo" \
  --label "do_not_delete=true" \
  mi_imagen:tag

# Luego puedes filtrar por etiquetas
docker ps -a --filter "label=backup=critical"

3. Crea un sistema de backup ANTES de necesitarlo

bash

#!/bin/bash
# backup_docker.sh
FECHA=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/srv/backups/docker_${FECHA}"
mkdir -p $BACKUP_DIR

# Backup de configuraciones
docker inspect $(docker ps -aq) > "$BACKUP_DIR/containers.json"
docker network ls -q | xargs docker network inspect > "$BACKUP_DIR/networks.json"

# Backup de volúmenes
docker volume ls --format "{{.Name}}" | while read VOL; do
  docker run --rm -v $VOL:/data -v $BACKUP_DIR:/backup alpine \
    tar czf /backup/${VOL}.tar.gz -C /data .
done

echo "Backup en: $BACKUP_DIR"

4. Usa Docker Compose para TODO

yaml

# docker-compose.yml
version: '3.8'
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - "9000:9000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    labels:
      - "backup=daily"
      - "critical=yes"

volumes:
  portainer_data:

5. Documenta tu infraestructura

markdown

# MI INFRAESTRUCTURA DOCKER.md

## Contenedores críticos:
1. **Portainer** - Gestión Docker
   - Puerto: 9000 (HTTP)
   - Volumen: portainer_data
   - Comando recreación: docker-compose up -d

2. **Jellyfin** - Servidor multimedia
   - Puerto: 8096
   - Volumen: jellyfin_config, jellyfin_cache
   - Variables: PUID=1000, PGID=100

Mi guía definitiva para resetear Portainer en OMV

Paso 1: Diagnóstico seguro

bash

# Ver TODO sin tocar nada
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"
docker volume ls
docker network ls

Paso 2: Backup selectivo

bash

# Backup SOLO de Portainer
docker run --rm \
  -v portainer_data:/source \
  -v $(pwd):/backup \
  alpine tar czf /backup/portainer_backup_$(date +%Y%m%d).tar.gz -C /source .

Paso 3: Eliminación quirúrgica

bash

# Detener solo Portainer
docker stop portainer 2>/dev/null || true

# Eliminar solo Portainer
docker rm portainer 2>/dev/null || true

# Eliminar solo su volumen
docker volume rm portainer_data 2>/dev/null || true

Paso 4: Reinstalación limpia

bash

docker volume create portainer_data
docker run -d \
  -p 9000:9000 \
  --name portainer \
  --restart unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

Paso 5: Verificación

bash

# Esperar 30 segundos
sleep 30

# Verificar
curl -s http://localhost:9000 | grep -i portainer && \
  echo "✅ Portainer funcionando" || echo "❌ Error"

Reflexión final

Aprendí más sobre Docker en esas 4 horas de crisis que en 6 meses de uso normal. El costo fue alto: perdí tiempo, paciencia y algo de fe en mis habilidades técnicas.

Pero hoy tengo:

  • Un sistema de backup automatizado
  • Todos mis contenedores en Docker Compose
  • Documentación actualizada
  • Scripts de recuperación para cada servicio

La moraleja: En administración de sistemas, la paranoia es una virtud. El comando que escribes a las 2 AM, frustrado y con sueño, puede destruir lo que construiste en meses.

Mi consejo para ti, que lees esto: Haz backup hoy. Etiqueta todo. Documenta cada cambio. Tu yo del futuro te lo agradecerá.

¿Cometiste errores similares? ¿Tienes mejores prácticas que compartir? Este artículo es mi confesión pública y mi contribución a la comunidad. Que mi dolor sea tu aprendizaje.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *