I finally bit the bullet and got a NAS at home; I ended up going the UniFi route to add to the rest of my UniFi gear 🤩. Naturally, the first thing I wanted to do was get my home automation data off my server’s local SSD and onto that new storage.
Everything was humming along perfectly... until I did a routine server reboot.
When the system came back up, I navigated to my Home Assistant URL expecting my usual dashboard, but instead, I was greeted with the "Welcome! Let’s get started" screen. 😱
How did a working NAS setup turn into a fresh install in the time it took to reboot?
The Scenario: The Race Condition
This usually happens because of a simple race condition. When your server reboots, Docker is often faster than the network mount. If the NAS isn’t "there" the exa…
I finally bit the bullet and got a NAS at home; I ended up going the UniFi route to add to the rest of my UniFi gear 🤩. Naturally, the first thing I wanted to do was get my home automation data off my server’s local SSD and onto that new storage.
Everything was humming along perfectly... until I did a routine server reboot.
When the system came back up, I navigated to my Home Assistant URL expecting my usual dashboard, but instead, I was greeted with the "Welcome! Let’s get started" screen. 😱
How did a working NAS setup turn into a fresh install in the time it took to reboot?
The Scenario: The Race Condition
This usually happens because of a simple race condition. When your server reboots, Docker is often faster than the network mount. If the NAS isn’t "there" the exact second Docker tries to start the container, Docker doesn’t wait, it just assumes you want to store data locally.
It creates a new folder on your local drive and starts a fresh installation right there. If you check your mount point, you’ll see the folders exist, but they are just empty "ghosts" on your local disk:
The "Shadow" Effect
This is where it gets confusing. When I browsed directly to the network share in my file explorer, I could see all my files were safe and sound. But back on the server, Docker was already running with a file handle to those local "ghost" directories.
Because Docker started before the mount was ready, the NAS data effectively "covered up" the local folder once it finally connected. But Docker stayed trapped looking at the hidden local version on the SSD.
How to Verify
If you suspect your local drive has "shadowed" your mount, you can run this command to see which physical drive is actually holding that folder:
The "Ghost" Output (Local SSD)
If you see your local system drive (like /dev/nvme0n1p2), you are looking at ghost data on your SSD:
The "Real" Output (NAS)
This is what you want to see. If the NAS is correctly mounted, the output will show the NAS IP:
The Fix: Clearing the Shadows
To get your real data back, you have to clear the local "landing zone" so the NAS has a clean place to land.
- Stop the containers: Run
docker compose down. - Unmount the NAS: Run
sudo umount -l /mnt. - Delete the local ‘ghosts’: Now that the NAS is unmounted, look at the
/mntfolder again. If there are files there, delete them. - Remount: Run
sudo mount -a.
The Permanent Safety Switch
To prevent this from happening after the next reboot, change your docker-compose.yml to use a Bind Mount with a safety check. This tells Docker: "If the source doesn’t exist, do NOT start."
With create_host_path: false, the container will fail to start if the NAS is missing. It’s much easier to fix a mount than it is to wonder where your entire configuration went!
Wrapping Up
Reboots shouldn’t be stressful. By setting these boundaries for Docker, you ensure that your server waits for your NAS to be ready instead of "helping" you into a fresh install loop.
Happy hosting! 🏠🍏