10001:10001 Migration failed

[titro]

Hey

im running currently a 0.43 release on unraid. tried to go to 0.45.1 with migration of chown of the data and recordings mounts and changed the pid folder in the ini. my compose has 2 mounts:
volumes: - /mnt/user/appdata/lightnvr/config:/etc/lightnvr - /mnt/user/nvr-recording:/var/lib/lightnvr/data

Start of the new version is working but it is started as a fresh instance with the install wizard and without any recordings?

any hints?

[matteius]

I found a Docker image volume-layout regression that matches your symptoms, and reproduced the mount behavior locally.

The older image declared /var/lib/lightnvr/data as a volume. The newer image (including 0.45.1) declares separate volumes at:

• /var/lib/lightnvr/data/database
• /var/lib/lightnvr/data/recordings
• /var/lib/lightnvr/data/models

With your existing parent bind mount, Docker creates anonymous volumes at those child paths, hiding the original directories inside /mnt/user/nvr-recording. LightNVR then sees an empty database and shows the setup wizard. Changing ownership does not resolve that mount conflict. In the reproduction, the original host files remained intact.

To confirm, run this on the Docker host, replacing lightnvr with your container name:

docker inspect lightnvr --format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'

If you see your parent bind mount plus volume entries at the three child paths above, that confirms the conflict.

Recovery on 0.45.1

1. Stop the container. Verify /mnt/user/nvr-recording/database/lightnvr.db and the original recordings are present on the host. Back up the original config and database directory, including any SQLite -wal and -shm files. Preserve any new data written into the anonymous volumes too; do not run docker compose down -v or prune volumes during recovery.
2. Keep your two existing mounts and explicitly bind the three existing child directories:

volumes:
  - /mnt/user/appdata/lightnvr/config:/etc/lightnvr
  - /mnt/user/nvr-recording:/var/lib/lightnvr/data
  - /mnt/user/nvr-recording/database:/var/lib/lightnvr/data/database
  - /mnt/user/nvr-recording/recordings:/var/lib/lightnvr/data/recordings
  - /mnt/user/nvr-recording/models:/var/lib/lightnvr/data/models

Verify those source paths match your actual existing layout before starting: a missing bind source can become an empty directory. Keep your existing database and recording paths in lightnvr.ini, along with the ownership and PID-path changes you already made. Check for a DB_PATH environment override if the database is in a custom location.

3. Recreate the container to apply the mounts (substitute your Compose service name if different):

docker compose up -d --force-recreate lightnvr

A restart alone does not change mounts. The explicit child binds should make the original database and recordings visible again.

I've also prepared a local fix restoring the parent-only image volume declaration in both Dockerfiles, plus recovery documentation. All six Docker fixture checks passed across the two Dockerfiles for legacy parent mounts, separate child mounts, and the workaround above. That fix has not been committed or released yet, so the explicit mounts are the workaround for the currently affected image.

[titro]

Yeeessss man. That was the cause.

With two bind mounts:

With the child folder:

now its working. Thanks!