El error unknown storage type file significa que tu configuración usa storage "file", un backend que OpenBao 2.7.0 eliminó, y se arregla migrando los datos con bao operator migrate, no volviendo a la 2.6. Tus secretos siguen intactos en el volumen. La propia imagen 2.7.2 todavía lee file como origen de una migración, así que puedes pasar a PebbleDB o a Raft sin bajar de versión. Lo probé el 2 de noviembre de 2026 en Linux arm64 con Docker 29.5.2, Compose 2.40.3 y las imágenes oficiales 2.6.5 y 2.7.2. Tienes la versión en inglés de esta guía.

Puntos clave

  • OpenBao 2.7.0, publicada el 23 de septiembre de 2026, quita el backend file; la 2.7.2 del 26 de octubre es la etiqueta latest en Docker Hub y en quay.io.
  • Con restart: unless-stopped, el contenedor entra en bucle: en mi prueba sumó 7 reinicios con la misma línea unknown storage type file antes de pararlo.
  • bao operator migrate de la 2.7.2 copió las 34 claves de file a PebbleDB; la 2.6.5 no sirve para eso, porque no conoce el backend pebbledb.
  • El servidor migrado arranca sellado con las mismas claves de desellado y el mismo token raíz, y el volumen de origen queda intacto para volver atrás.
  • La 2.7.x será la última que lea file en una migración: las notas de la 2.7.0 anuncian que lo quitan también de bao operator migrate en la v2.8.0.

¿Qué significa unknown storage type file en OpenBao?

Significa que el servidor no reconoce el tipo de almacenamiento de tu bloque storage, porque el backend file ya no está compilado en la 2.7. No es un problema de permisos ni de datos corruptos: el proceso sale con código 1 antes de abrir el volumen. Esto es lo que devolvió docker compose logs al cambiar la imagen de openbao/openbao:2.6.5 a 2.7.2 sobre una instalación con storage "file":

$ docker compose logs openbao
[INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
unknown storage type file
[INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
unknown storage type file

He quitado la fecha del principio de cada línea [INFO]. docker compose ps -a mostraba el servicio como Restarting (1), y docker inspect daba exit=1 restarts=7 a los pocos segundos. Mientras dura el bucle, la API en el puerto 8200 ni siquiera acepta conexiones, así que tus aplicaciones ven un error de conexión y no un 503 de servidor sellado.

¿Qué versiones de OpenBao provocan el error?

Lo provocan todas las de la rama 2.7, de la 2.7.0 en adelante, cuando la configuración del servidor sigue usando storage "file". Las notas de la versión 2.7.0[1] lo recogen en una línea, "Remove file storage backend support", y la guía de migración a PebbleDB[2] lo dice sin rodeos: "Because OpenBao 2.7.0 removes the File storage backend, you must migrate to a different backend."

Versión Fecha Qué cambia para file
2.6.x (2.6.5 la más reciente) hasta el 26 de octubre de 2026 arranca con un aviso de obsolescencia
2.7.0 23 de septiembre de 2026 el servidor ya no lo reconoce; llega PebbleDB
2.7.1 1 de octubre de 2026 los paquetes de Linux pasan su configuración por defecto a pebbledb
2.7.2 26 de octubre de 2026 sin cambios en almacenamiento
2.8.0 sin fecha bao operator migrate dejará de leer file

Las fechas son las de las etiquetas en el registro de quay.io[3], y el 2 de noviembre de 2026 latest, 2 y 2.7 apuntaban al mismo resumen que 2.7.2 (sha256:5046911075e1…), también en Docker Hub. Si tu compose usa openbao/openbao:latest, el siguiente docker compose pull te pasa a la 2.7.2 sin avisar. Un actualizador automático como Watchtower hace lo mismo de madrugada.

La 2.6.5 ya advertía en cada arranque, con un texto que la 2.7.2 sigue imprimiendo durante la migración: the file physical backend is deprecated; use bao operator migrate to move to a supported storage backend by v2.7.0. La guía de instalación de OpenBao con Docker de este blog ya usaba Raft por ese motivo.

Arreglo inmediato: para el bucle y copia el volumen

Para el contenedor primero: la migración exige el servidor apagado, y el bucle de reinicios lo tendría arrancando cada pocos segundos. Este era el servicio de partida, con la configuración en ./config/bao.hcl y los datos en el volumen bao-file:

services:
  openbao:
    image: openbao/openbao:2.7.2
    command: server
    restart: unless-stopped
    cap_add: [IPC_LOCK]
    ports:
      - "127.0.0.1:8200:8200"
    environment:
      BAO_ADDR: http://127.0.0.1:8200
      SKIP_CHOWN: "true"
    volumes:
      - ./config:/openbao/config:ro
      - bao-file:/openbao/file

volumes:
  bao-file:

En mi laboratorio el puerto publicado era otro y la imagen venía de quay.io, con el mismo resumen que la de Docker Hub. SKIP_CHOWN evita que el script de entrada intente cambiar el propietario de ./config, montado en solo lectura, y llene el registro de avisos Read-only file system. Con el servicio así definido, para el contenedor y archiva el volumen con la misma imagen de OpenBao:

docker compose stop openbao
docker compose run --rm --no-deps --user root --entrypoint tar \
  -v "$PWD:/backup" openbao czf /backup/bao-file.tgz -C /openbao/file .

En mi prueba, con tres secretos en un motor de clave-valor (KV) v2 y una política, el volumen file ocupaba 136 KB y el archivo comprimido 12 KB. La guía oficial pide al menos un 60 % de disco libre, porque durante la migración los datos están dos veces. Si quieres entender qué guarda un volumen con nombre y dónde, está en volúmenes y bind mounts en Docker.

Cómo migrar de file a PebbleDB con bao operator migrate

PebbleDB es el sustituto directo de file: un almacén embebido en un único directorio, sin alta disponibilidad (HA) ni clúster, que llegó en la propia 2.7.0. La migración copia las claves cifradas tal cual, sin desellar nada. Escribe migrate.hcl al lado del compose, fuera de ./config, porque el servidor carga todos los ficheros de ese directorio:

storage_source "file" {
  path = "/openbao/file"
}

storage_destination "pebbledb" {
  path = "/openbao/data"
}

Añade un segundo volumen, bao-data, montado en /openbao/data. Deja también el de file, que es tu vuelta atrás:

    volumes:
      - ./config:/openbao/config:ro
      - bao-file:/openbao/file
      - bao-data:/openbao/data

volumes:
  bao-file:
  bao-data:

Ahora cambia el propietario del volumen nuevo y lanza la migración con la imagen 2.7.2. El chown no es opcional: /openbao/data no existe en la imagen, Docker crea el volumen como root y la imagen corre con el usuario openbao (UID 100). Sin él, la migración falló con failed to open database: open /openbao/data/LOCK: permission denied.

docker compose run --rm --no-deps --user root --entrypoint chown \
  openbao openbao:openbao /openbao/data
docker compose run --rm --no-deps \
  -v "$PWD/migrate.hcl:/tmp/migrate.hcl:ro" \
  openbao operator migrate -config=/tmp/migrate.hcl

La salida termina así; entre medias hay una línea copied key por cada clave, 34 en mi caso:

[WARN]  the file physical backend is deprecated; use bao operator
        migrate to move to a supported storage backend by v2.7.0
[INFO]  copied key: path=core/mounts
[INFO]  copied key: path=core/root-key
[INFO]  copied key: path=core/seal-config
Success! All of the keys have been migrated.

Intenté primero lo que sugiere la intuición, migrar con la 2.6.5 antes de actualizar, y no funciona para este destino: Error migrating: error mounting 'storage_destination': no Vault storage backend named: "pebbledb". PebbleDB solo existe a partir de la 2.7.0, así que la migración a PebbleDB se hace con la 2.7.x.

Arranca la 2.7.2 sobre PebbleDB y comprueba los secretos

Después de migrar, cambia solo el bloque storage de ./config/bao.hcl y deja el resto de la configuración como estaba:

storage "pebbledb" {
  path = "/openbao/data"
}

Arranca el servicio, desella con la clave de siempre y lee un secreto. La sustitución tu_clave_de_desellado es tu clave de bao operator init, y tu_token_raiz el token raíz o uno con permiso de lectura:

docker compose up -d
docker compose exec openbao bao status
docker compose exec openbao bao operator unseal tu_clave_de_desellado
docker compose exec -e BAO_TOKEN=tu_token_raiz openbao \
  bao kv list secret/app

El primer bao status devolvió Initialized true, Sealed true y Storage Type pebbledb, y tras el desellado bao kv list listó los tres secretos (api, db y smtp) con sus valores. La política app-read también seguía allí. El registro de arranque mostraba Storage: pebbledb y Version: OpenBao v2.7.2, y el contador de reinicios quedó a cero.

Fíjate en Initialized true, porque es la comprobación que importa. Si cambias el bloque storage sin migrar, la 2.7.2 arranca sin errores sobre un directorio vacío y bao status dice Initialized false. Parece una instalación nueva. No ejecutes bao operator init en ese estado: crearías un almacén distinto con claves nuevas y tus secretos seguirían en el volumen file.

Alternativa: migrar de file a Raft

Elige Raft si piensas añadir más nodos o quieres los snapshots con bao operator raft snapshot; para un único servidor en casa, PebbleDB pide menos configuración. El procedimiento es el mismo, con dos bloques distintos. Este es el migrate.hcl:

storage_source "file" {
  path = "/openbao/file"
}

storage_destination "raft" {
  path    = "/openbao/data"
  node_id = "bao-1"
}

cluster_addr = "http://127.0.0.1:8201"

En bao.hcl, el bloque storage "raft" lleva el mismo path y node_id, y la configuración necesita además cluster_addr = "http://127.0.0.1:8201". Restauré la copia del volumen en un proyecto aparte, migré con la 2.7.2 (34 claves también) y la 2.7.2 arrancó con Storage Type raft y HA Enabled true. Tras desellar, bao operator raft list-peers mostró un único nodo bao-1 como leader. La guía de instalación con Raft explica los snapshots y la migración desde file con la 2.6.

Cómo volver atrás si algo falla

Vuelve a la configuración storage "file" y a la imagen 2.6.5: el volumen de origen queda intacto. bao operator migrate solo añade un fichero de bloqueo mientras copia, y al terminar el volumen tenía los mismos 34 ficheros. Lo comprobé arrancando la 2.6.5 sobre el volumen file ya migrado: desselló con la misma clave, mostró Storage Type file y devolvió el secreto api.

Ten en cuenta dos límites antes de dar marcha atrás:

  • Lo que escribas en PebbleDB después de migrar no existe en file, así que perderías esos cambios
  • La 2.6.x no es un destino estable: file no va a volver, y la 2.6.5 del 26 de octubre de 2026 solo te da tiempo

El archivo bao-file.tgz del primer paso cubre el caso peor, un volumen dañado por otro motivo. Cuando la 2.7.2 lleve unos días funcionando, borra el volumen bao-file y su línea del compose.

Preguntas frecuentes

¿Pierdo mis secretos con el error unknown storage type file?

No. El servidor sale antes de tocar el volumen, y en mi prueba los 34 ficheros seguían en bao-file tras siete reinicios. Los recuperas al migrar o al volver a la 2.6.5 con la misma configuración. Haz igualmente la copia del volumen antes de migrar.

¿Tengo que volver a la 2.6 para migrar?

No, y para PebbleDB ni siquiera sirve: la 2.6.5 no conoce ese backend. La 2.7.2 lee file como origen de bao operator migrate y escribe en PebbleDB, Raft o PostgreSQL. Las notas de la 2.7.0 avisan de que ese origen desaparecerá en la 2.8.0, así que no dejes la migración para después.

¿Necesito las claves de desellado para migrar?

No para copiar: la migración mueve los datos cifrados sin descifrarlos. Sí las necesitas justo después, para desellar la 2.7.2 sobre el almacén nuevo. Si las perdiste, la migración no te ayuda, porque el almacén nuevo está cifrado con la misma clave raíz que el viejo.

Conclusión

unknown storage type file es el aviso de obsolescencia de la 2.6 cumplido: OpenBao 2.7.0 quitó el backend file, y latest ya apunta a la 2.7.2. Para el bucle, copia el volumen, haz el chown del volumen nuevo y migra a PebbleDB con la 2.7.2; desellas con las claves de siempre. Hazlo durante la rama 2.7, antes de que la 2.8.0 retire también el origen file de la migración. Si estás comparando gestores de secretos, la introducción a Vault de HashiCorp explica el modelo del que parte OpenBao y cómo instalar Infisical con Docker muestra una alternativa con otra filosofía.

Fuentes: [1] OpenBao, notas de la versión 2.7.0[1], [2] OpenBao, notas de la versión 2.7.1[4], [3] OpenBao, guía de migración de file a PebbleDB[2], [4] OpenBao, documentación de operator migrate[5], [5] OpenBao, backend de almacenamiento PebbleDB[6], [6] Etiquetas de openbao/openbao en quay.io[3], [7] Etiquetas de openbao/openbao en Docker Hub[7].

Fuentes

  1. versión 2.7.0
  2. guía de migración a PebbleDB
  3. registro de quay.io
  4. OpenBao, notas de la versión 2.7.1
  5. OpenBao, documentación de operator migrate
  6. OpenBao, backend de almacenamiento PebbleDB
  7. Etiquetas de openbao/openbao en Docker Hub