named volume not working

[bonelifer]

Trying a named volume to persist cloudi-cli data, gets me this.

[persist-claude-json] live Claude state restored from persisted state updated
[entrypoint] Starting s6-overlay...
/package/admin/s6-overlay/libexec/preinit: info: container permissions: uid=0 (root), euid=0, gid=0 (root), egid=0
/package/admin/s6-overlay/libexec/preinit: info: /run permissions: uid=0 (root), gid=0 (root), perms=oxorgxgruxuwur
s6-rc: info: service xvfb: starting
s6-rc: info: service persist-claude-json: starting
s6-rc: info: service cloudcli: starting
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service cloudcli successfully started
s6-rc: info: service xvfb successfully started
s6-rc: info: service persist-claude-json successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services successfully started
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file
❌ Error: unable to open database file

services:
  holyclaude:
    image: coderluii/holyclaude:latest
    container_name: holyclaude
    restart: unless-stopped
    shm_size: 2g
    cap_add:
      - SYS_ADMIN   # Current browser profile for this release; hardening is separate
      - SYS_PTRACE  # Debugging-related capability
    security_opt:
      - seccomp=unconfined  # Current browser profile for this release; hardening is separate
    ports:
      - "192.168.1.80:3001:3001"
#      - "127.0.0.1:3001:3001"
    volumes:
      - ./data/claude:/home/claude/.claude
      - ./data/workspace:/workspace
      - cloudcli-data:/home/claude/.cloudcli

    environment:
      - TZ=America/Chicago

volumes:
  cloudcli-data:

[CoderLuii]

@bonelifer thanks for including the Compose file and the full startup log. That confirmed a real gap in the named-volume setup we documented: /home/claude/.cloudcli can be mounted with ownership that prevents CloudCLI from opening auth.db.

I opened #70 to track the fix. v1.5.3 is being prepared so fresh volumes inherit the right owner, existing local volumes are repaired during normal Docker startup, and an unusable or read-only mount fails before CloudCLI starts.

For the current image, you can repair that named volume once with:

docker compose run --rm --user root --entrypoint sh holyclaude \
  -c 'mkdir -p /home/claude/.cloudcli && chown -R ${PUID:-1000}:${PGID:-1000} /home/claude/.cloudcli'
docker compose up -d

That keeps the existing database files in place. Use it only for a local Docker volume, not a NAS, SMB/CIFS, or NFS mount, because SQLite locking is a separate issue on network storage.

I’ll keep the tracking issue open until both image variants are published and the volume check passes against the release images.

[CoderLuii]

@bonelifer this is fixed in v1.5.3. Thanks again for posting the Compose file and startup log; they exposed a real problem in the named-volume setup we documented.

Fresh .cloudcli volumes now start with usable ownership. Existing local volumes are repaired during normal root-starting Docker startup after PUID/PGID is applied, and the container checks auth.db plus existing SQLite sidecars before CloudCLI starts. The rootless Podman profile also now persists /home/claude/.cloudcli with SELinux :Z labeling.

Update with:

docker compose pull
docker compose up -d

The published full and slim images passed the volume persistence checks on amd64 and arm64 in both Docker Hub and GHCR.