[BUG] Not possible to restore backup

[javier-cr]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When attempting to restore a backup, this does not actually succeed. The UniFi interface will indicate the backup has been uploaded and restore is in progress. The controller HTTP site goes offline, and in the meantime, Mongo logs indicate new collections/indexes/etc. are being created. However, once the container comes back up, no backup has been restored and a new install is present.

Compared this behavior with a new install of the controller on macOS, and the same backup files are restored successfully without any issues.

Note: I am using a reverse proxy (Caddy), however, the issue is reproducible without it.

Expected Behavior

A backup should be successfully restored.

Steps To Reproduce

In these steps, we spin up a docker compose stack (UniFi + Mongo), make some changes so there's a difference from the default install, and take a controller backup. Then, we tear down the environment, spin up a new one, and attempt to restore the backup we took (this does not succeed).

1. Bring up containers using docker-compose file.
2. Once the UniFi controller container is up, navigate to the controller interface, and proceed thru the steps to create a new site.
3. Modify a couple settings (such as Site Name, etc.), then take a backup of this site.
4. Bring down the compose stack, and ensure any volumes that were created are removed.
5. Re-create the compose stack.
6. Once the UniFi controller container is up, this time, choose Restore backup and select the backup file that was just created.
7. Proceed thru the pop-up confirmation dialog.
8. Wait for the container to restart.
9. Observe that the backup has not been restored, and that a new install is present.

Environment

- OS: Docker 24.0.2 // Synology DSM 7.2.2-72806 Update 4 (latest)
- How docker service was installed: Synology package (Container Manager)

CPU architecture

x86-64

Docker creation

services:
  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:9.3.45
    container_name: unifi-network-application
    restart: unless-stopped
    depends_on:
      mongo:
        condition: service_healthy
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TZ}
      - MONGO_USER=${MONGO_USER}
      - MONGO_PASS=${MONGO_PASS}
      - MONGO_HOST=${MONGO_HOST}
      - MONGO_PORT=${MONGO_PORT}
      - MONGO_DBNAME=${MONGO_DBNAME}
      - MONGO_AUTHSOURCE=${MONGO_AUTHSOURCE}
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - unifi_data:/config
    networks:
      externalnet:
        ipv4_address: ${IPV4_ADDRESS}
      caddy-unifi:
      unifi-internal:
    healthcheck:
      test: curl --fail -k https://localhost:8443 || exit 1
      interval: 60s
      retries: 5
      start_period: 20s
      timeout: 10s
  mongo:
    image: mongo:4.4
    container_name: unifi-db
    restart: unless-stopped
    environment:
      - MONGO_INITDB_ROOT_USERNAME=${MONGO_INITDB_ROOT_USERNAME}
      - MONGO_INITDB_ROOT_PASSWORD=${MONGO_INITDB_ROOT_PASSWORD}
      - MONGO_USER=${MONGO_USER}
      - MONGO_PASS=${MONGO_PASS}
      - MONGO_DBNAME=${MONGO_DBNAME}
      - MONGO_AUTHSOURCE=${MONGO_AUTHSOURCE}
    volumes:
      - /volume1/docker/unifi/init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
      - unifi_mongo_db:/data/db
    networks:
      unifi-internal:
    healthcheck:
      test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet
      interval: 10s
      timeout: 10s
      retries: 5
      start_period: 40s
volumes:
  unifi_data:
  unifi_mongo_db:
networks:
  externalnet:
    external: true
  caddy-unifi:
    external: true
  unifi-internal:

Container logs

[migrations] started
[migrations] no migrations found
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: 9.3.45-ls99
Build-date: 2025-07-31T15:03:35+00:00
───────────────────────────────────────
    
*** Waiting for MONGO_HOST unifi-db to be reachable. ***
Generating 4,096 bit RSA key pair and self-signed certificate (SHA384withRSA) with a validity of 3,650 days
	for: CN=unifi
[custom-init] No custom files found, skipping...
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "Thread-11" java.lang.IllegalStateException: org.springframework.boot.web.servlet.context.AnnotationConfigServletWebApplicationContext@613c829c has been closed already
	at org.springframework.context.support.AbstractApplicationContext.assertBeanFactoryActive(AbstractApplicationContext.java:1227)
	at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1260)
	at com.ubnt.service.ooOO.Ö00000(Unknown Source)
	at com.ubnt.ace.Launcher.Ò00000(Unknown Source)
	at java.base/java.lang.Thread.run(Thread.java:840)
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "Thread-11" java.lang.IllegalStateException: org.springframework.boot.web.servlet.context.AnnotationConfigServletWebApplicationContext@2f6f7113 has been closed already
	at org.springframework.context.support.AbstractApplicationContext.assertBeanFactoryActive(AbstractApplicationContext.java:1227)
	at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1260)
	at com.ubnt.service.ooOO.Ö00000(Unknown Source)
	at com.ubnt.ace.Launcher.Ò00000(Unknown Source)
	at java.base/java.lang.Thread.run(Thread.java:840)
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "Thread-12" java.lang.IllegalStateException: org.springframework.boot.web.servlet.context.AnnotationConfigServletWebApplicationContext@5ca01e01 has been closed already
	at org.springframework.context.support.AbstractApplicationContext.assertBeanFactoryActive(AbstractApplicationContext.java:1227)
	at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1260)
	at com.ubnt.service.ooOO.Ö00000(Unknown Source)
	at com.ubnt.ace.Launcher.Ò00000(Unknown Source)
	at java.base/java.lang.Thread.run(Thread.java:840)

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[don-reis]

I am also experiencing this behavior with a new deployment today on K8s.

Upon initial setup, I tried to push the configuration from backup using the "Restore Server from a Backup" link on the "Name Your UniFi Network Server" screen. After confirming the restore, I get the message "Backup restoration is in progress. Your Network application will reboot during this process.". This lands me on a "Restore Server" screen; I use the "Upload Backup File" link to again attempt restore. Again, I get the message "Backup restoration is in progress. Your Network application will reboot during this process.". After a few moments, it reloads the "Restore Server" screen. Infinite loop from there.

I can go ahead and "Create New Server Configuration", and the admin UI comes up. From the admin UI, I can again attempt a restore (Settings > System > Backups > Restore), where after confirming the restore, the "Restoring backup..." bubble appears in the top right corner. The UI stalls here and does not self-refresh. Eventually, I refresh the browser, and I'm back to square one, needing to attempt restore or initial configuration again.

I ensured my existing, and this new deployment, were running identical UNA v9.4.19 before creating the backup.

If you find this thread trying to resolve this issue, my problem was with authorization on the NFS mount for /config. Data was being created during the restore and configuration processes, but they were getting created on the mount with a restricted user/group/umask. Example: data directory created as nobody/nogroup/755. Once the initial configuration was created, if I adjusted the umask on the data and logs directories, restoring was possible.

If you find yourself with this issue, check your container has sufficient rights on its /config backing volume.