· I have migrated from RoonOnNas to Roon on Docker (Synology). After restoring from my backup, my alternate album groupings now are lost. My tags have migrated, so the database came through. However, I had to manual enable the music folder in settings, and when my local files were scanned again, they are all newly added and I lose my metadata edits from the backup. How can I ensure I get all this work I've done over the years back?
Thanks for reaching out. Can you please confirm if Roon saw two copies of the media files at any point? Did you have both the old folder and the new folder simultaneously enabled? I would advise restoring the backup once more, and ensuring Roon only sees one copy of the files:
When I restored from backup, the Music Folder was disabled, and there was another folder below that had some error on it, which I removed. I had Music Folder then route to where the folder is in my Synology’s file system (hasn’t moved since last backup or ever), and that the docker compose mapped to
Rename the “RoonServer” folder to “RoonServer_old”
Reinstall the RoonServer App from our Downloads Page to generate a new RoonServer folder
On the Roon Remotes, press “Use another Roon Server” and connect to the new database
Now, restore the Backup. What do you see in Settings → Storage? Try to delete any erroneous storage locations before mapping to the correct one. We’ll watch for your response.
This is what I got, and what I got earlier. I made the Music Folder point to the downloads/music shown below (which is also what the docker compose maps to), and deleted the bottom folder, which is when I made the ticket. Let me know what to do next to solve. Thanks
I followed your instructions a couple days ago and posted what I see. Can I continue to get support here? I need the old folder to be Music Folder and have my album groupings carry over.
Thanks for sticking with us, and for your patience so far! Not having your saved edits for your library is definitely frustrating, so I empathize with you wanting things fixed asap!
We were able to further analyze a fresh Roon Server diagnostic report, and saw that the problem seems to be tied to a storage backend ID mismatch. Roon tracks your music folder not just by path, but by an internal UUID tied to each storage location. The logs show two distinct backends:
ac269566 — your old RoonOnNas installation, path /Music — released/removed on April 28 at 21:14:43, dropping all 5,930 tracks
29bdcae6 — your new Docker "Music Folder," also pointing to /Music — but it's a different backend ID, so Roon treated it as brand new
First, don't re-edit anything yet. Every manual edit you make now is on the new backend and makes recovery messier.
Here are some next steps in troubleshooting:
Step 1: Restore from the most recent pre-migration backup
Your best path back is to restore from a backup that was made before you removed the old folder on April 28. The database from that backup has all your edits linked to the old backend ID (ac269566).
When restoring, the key is to not let Roon add a new music folder — instead, you want to configure it so the existing folder entry (with the old backend ID) resolves to your current Docker-mapped path.
Step 2: After restoring, edit the folder path, don't re-add it
After restoring from backup:
Let Roon start up with the folder still showing as disabled/unavailable (do NOT delete it)
Click the three-dot menu → Edit on that old folder entry
Navigate it to your current Docker music path (/downloads/music or wherever it's mounted inside the container)
This lets Roon re-associate the existing backend ID with the correct path — your edits stay intact
Step 3: Verify your Docker volume mapping is consistent
The logs show Roon sees files at /Music inside the container. Make sure your docker-compose.yml volume mount is stable and consistent, e.g.:
volumes:
- /volume1/downloads/music:/Music
The container-side path (/Music) must match what Roon’s folder entry was configured to watch.
