Cannot Restore Proper Backup on new Roon Server running Docker via QNAP

[Alan_C]

Hi Benjamin

Thank you for your note.

I would prefer to perform a backup restore mainly because of edits and to a lesser extent playlists. I have a Roon Core Backup from 04/25, created just before I encountered the problem we have been trying to resolve. However, when I re-connected the iPad Roon app to the QNAP NAS112F59, it apparently resumed the old backup schedule and created a backup dated 07/07/26 in the container in a folder called roon-backups. When I select “Find backups” in the Roon app, it is the 07/07 backup that is identified. I am providing snapshots of the NAS, including the container, and of the iPad app backup screens.

I should note I also have a backup dated 04/27/26 on a Synology NAS. If you can walk me through a restore from the QNAP 04/25 backup, I would very much appreciate it.

I look forward to your guidance.

Thank you!

Alan

[Alan_C]

I’m attaching a screenshot of what I see when I select “Choose music storage folder” in the app. It appears to be the container folder system. I would appreciate your advice on what to select.

[benjamin]

Hey @Alan_C,

Thank you for the detailed notes and screenshots, they make the situation clear.

Here’s what happened. When you reconnected the iPad app to the QNAP, Roon Server re-activated your old backup schedule and ran a fresh automatic backup early on 07/07 into the container’s roon-backups folder. That’s the backup “Find backups” is showing you.

Roon’s “Find backups” only lists what’s inside the specific folder you point it at, so as long as it’s resolving to that container folder, the 07/07 backup is all you’ll see.

The good news: your 04/25 backup is safe and untouched. It lives in a separate backup folder (the RoonBackups folder containing the set that begins 2f91535b…), which is completely independent of the 07/07 set. The new backup did not overwrite it, and Roon’s retention limit is applied per folder, so nothing was pruned.

To restore from the 04/25 backup, here’s how I’d proceed:

1. Protect your good backups first. In the iPad app, go to Settings → Backups and turn off (or delete) the scheduled backup so no further automatic backups run. As added insurance, use File Station to copy the entire 04/25 RoonBackups folder, including the _roon_backup_root_ file, to a safe spot before doing anything else.
2. Point Roon at the 04/25 backup. In Settings → Backups, choose Find backups / Browse, and navigate to the folder that directly contains the _roon_backup_root_ file and the 2f91535b… folder , that's the RoonBackups folder itself, not the GUID subfolder inside it, and not the container's roon-backups folder. If that share isn't listed in the browser, use "Add network share" in that same dialog to add it (SMB path plus credentials), then run Find backups there.
3. Select and restore. Once you're pointed at the correct folder, the 04/25 backup will appear in the list. Select it and confirm the restore.
4. What to expect. A restore fully replaces your current database with the 04/25 state, so your edits and playlists will return. Anything changed after 04/25 (play history, later edits, settings) will revert, and Roon Server will restart as part of the process.
5. After the restore. Reconnect the iPad remote, re-authorize if prompted, confirm your watched storage folders are still enabled, and check that your streaming services (Tidal/Qobuz) are still signed in. You can then set up a fresh backup schedule if you'd like one.

One quick thing to confirm before you begin: your note mentions the 04/25 backup is on the QNAP and a 04/27 backup on the Synology, but the screenshots show the 04/25 set under a Roon Core Backup/RoonBackups path. Could you confirm which NAS and share actually holds that 04/25 folder? That way we make sure step 2 points at exactly the right location.

Hope this helps!

[Alan_C]

Hi Benjamin,

Thank you for your very helpful reply. I can confirm that the QNAP holds the 04/25 folder with the Roon Core Backup/RoonBackups path. I’ll follow your instructions and hopefully report that all went well.

Best wishes,

Alan

[Alan_C]

Hi Benjamin,

I have tried unsuccessfully to point Roon to my 04/25 backup on my QNAP NAS. All of my efforts on both my iPad and Windows 11 PC have resulted in an error message.

As you can see from the earlier screenshots, the path is NAS112F59/DataVol1/Roon Core Backup/RoonBackups. SMB3 has been enabled on the NAS. The static IP for the NAS is 192.168.1.45. I don’t know whether to include the port (192.168.1.45:XXXXX), which is not the default of 445. I don’t know whether to revert the port to 445. I also considered changing my password for the NAS because it contains special characters. However, I was hesitant to do that since there might be another issue. I should note the NAS has 2FA, for which I use an authenticator app.

These conditions have been present for years and were not a problem for Roon prior to the software upgrade that created the issue we have been working on.

I look forward to your advice.

Thank you!

Best wishes,

Alan

[benjamin]

Hey @Alan_C,

Good news, the logs make this one clear, and it’s a smaller fix than it looks. You don’t need to change your NAS password, and the 2FA and port questions turn out to be red herrings for now. Here’s why.

Every one of your “Add network share” attempts failed at the same spot, with the same internal error: the path you entered had no share name in it. Roon needs at least \server\share, and the strings that were tried (\192.168.1.45, smb://192.168.1.45, smb://192.168.1.45:45179, NAS112F59, etc.) all stop at the server.

Roon rejects the text before it ever tries to connect, which is why the password, the authenticator, and the port never actually came into play. So let’s fix the address first.

A few things to correct in the network-share dialog:

• Use Windows-style backslashes, not smb://.
• Include the share name. DataVol1 is the QNAP volume, not a share, over SMB the share is the folder itself. So enter: \\192.168.1.45\Roon Core Backup and then browse into RoonBackups.
• Drop the port. Roon uses standard SMB (445) and has no field for a custom port; appending :XXXXX gets read as part of the server name and fails. Please set the NAS SMB service back to 445 (or make sure 445 is reachable) and enter no port.
• Put your NAS username and password in the dialog's credential fields, not in the path. SMB uses username + password only, 2FA doesn't apply to it. If your account's 2FA policy blocks the connection, the easy workaround is a dedicated NAS user with no 2FA and read access to that share; that also sidesteps any special-character worries in your main password.

That said, since Roon Server is running inside the container on the QNAP, my stronger recommendation is to skip SMB entirely and let Roon read the backup as a local folder. Two ways:

1. File Station copy (simplest): Copy the entire 04/25 RoonBackups folder, including the _roon_backup_root_ file and the 2f91535b… subfolder, into your container's existing backup folder (/share/Container/roon-backups, which Roon sees as /RoonBackups). Then in Roon go to Settings → Backups → Find backups and browse that folder.
2. Add a volume mount: In Container Station, add a mount such as /share/CACHEDEV1_DATA/Roon Core Backup/RoonBackups:/OldBackups (adjust the left side to your actual volume path), restart the container, and Find backups → browse /OldBackups.

Either way, remember from before: point Find backups at the RoonBackups folder itself, the one that directly contains _roon_backup_root_ and the 2f91535b… folder, not the GUID subfolder inside it, and not the container's roon-backups folder that now holds the 07/07 automatic backup. Restoring will fully replace the current database and restart the server, so once it's done, reconnect your remote and re-check your watched folders and streaming logins.

Give the local-folder route a try first and let me know what the backup browser shows.

[Alan_C]

Hi Benjamin,

Thank you for your advice. I copied and pasted the RoonBackups folder into the container’s backup folder and then browsed to the container’s backup folder in the Roon app. However, the only albums that I see are from Tidal. None of the 2000 or so CD’s that I copied into Roon and none of my playlists are visible. Thanks, again!

[benjamin]

Hey @Alan_C,

Thanks for the update! We were able to review fresh server logs that show what you restored wasn’t your old library, which is why you’re seeing only Tidal. Let me explain what happened and how to fix it.

When you ran the restore, Roon restored this backup:

serial=fda9354b… backup=b_20260715090001

That fda9354b is your new Docker server, and that backup is the container’s own automatic nightly backup, which has only ever contained your Tidal library. So the Tidal-only result is exactly what that backup holds. Your current database confirms it: 3,494 albums and 47,151 tracks, and every one of them is from Tidal. None of your local files are in it.

Why your old backup didn’t show up as a choice

Each time Roon looked inside the 2f91535b… folder (that’s your old, pre-Docker server, the one with your CDs and playlists), it reported that it couldn’t read the backup marker file:

could not read id file: /RoonBackups/2f91535b…/roon_backup: NotFound

Because that marker is missing, Roon doesn’t treat 2f91535b… as a valid backup, so the only thing it offered you to restore was the Tidal-only Docker backup. This usually means the copy into the container didn’t bring the folder’s inner files along completely.

Step 1, Let’s verify the old backup is intact

In File Station, open the folder you copied in and go into 2f91535b-8a8a-cfd9-4d94-3141c020ecd8. Tell me what you see inside. A healthy backup will contain:

• a small file named _roon_backup_ (no "root"), and
• one or more folders named like b_20260425…

If those are missing or the folder is empty, the copy was incomplete, please re-copy the entire original RoonBackups folder again, making sure hidden/system files are included, and confirm _roon_backup_ appears inside 2f91535b….

Step 2, Restore the correct backup

Once that marker file is present, go to Settings → Backups → Find backups and point it at the RoonBackups folder itself (the one containing roon_backup_root). You should now see a backup listed under your old server with an April date. Restore that one. This replaces the current Tidal-only database and brings back your playlists, edits, and history.

Step 3, Reconnect your CD files

Even after the correct restore, your 2,000 CDs will show as unavailable until Roon can see the actual music files. Right now your only local storage is the container’s empty default /Music folder, so the files aren’t reachable. Once restored, go to Settings → Storage and add the folder on the NAS where your ripped CDs actually live (bind-mounting that folder into the container first, the same way the backup folder is mapped). Once Roon scans it, the albums will reconnect to your restored library.

So the order is: verify → re-copy if needed → restore the old backup → add your music folder as storage. Send me what’s inside that 2f91535b… folder and we’ll take the next step from there.

[Alan_C]

Hi Benjamin,

Thank you for your note. I’ve delayed responding as I tried a few things and now need your advice on next steps.

The backups on the QNAP NAS lack the file, _roon_backup_. Fortunately, I alternated Roon backups between the QNAP and a Synology NAS. As seen in the attached photos, Synology has two folder with _roon_backup_.

I deleted and reinstalled the Roon container on the QNAP with the intention of copying the Synology’s backups into the container. Unfortunately, when I reinstalled the container, the old folders were still there.

What should I do next? Do you know a simple way to copy the Synology folders to the QNAP? (In the meantime, I’ve made a copy of the Synology backup on the Synology.)

Thanks again!

[benjamin]

Hey @Alan_C,

Great news in your update, the backups you need are safe and intact, they’re just sitting on the Synology rather than the QNAP. Both GUID folders on the Synology still have their roon_backup marker file, and the one we want is 2f91535b-8a8a-cfd9-4d94-3141c020ecd8 — that’s your old pre-Docker server with the CDs and playlists, and it should hold the April backup set.

So rather than keep wrestling with copying files onto the QNAP (which is where the marker file keeps getting dropped), let’s skip the copy entirely. Roon Server is running in the container on the QNAP, and it can read the Synology’s backup share directly over the network. Since those backups are already valid, Roon should offer the April set right away.

Here’s how to point Roon at it:

1. In the iPad app, go to Settings → Backups → Find backups → Add network share.
2. Enter the path using the corrected format we sorted out last time:
   • Windows-style backslashes, with the real share name — \<Synology-IP>&lt;share-name>, then browse into the RoonBackups folder (the one that directly contains roon_backup_root).
   • No smb:// prefix and no port number, just the plain \server\share path.
   • Put your Synology username and password in the credential fields of the dialog, not in the path.
3. If your Synology account’s 2FA blocks the connection, the easy workaround is to create a dedicated Synology user with no 2FA and read-only access to that share, and use those credentials here.
4. Once connected, browse to the RoonBackups folder. You should now see a backup listed under your old server with an April date. Select that one and restore.

A couple of things to expect:

• The restore fully replaces the current Tidal-only database and restarts the server, so your edits and playlists will come back.
• Your ~2,000 CDs will initially show as unavailable, that’s normal. Roon has your library back, but it still needs to see the actual music files. Once the restore is done, go to Settings → Storage and add the NAS folder where your ripped CDs live (we’ll bind-mount that into the container the same way, and I can walk you through it).

Give the network-share route a try and let me know what the backup browser shows under the old server, if you can grab fresh server logs after the attempt, I’ll confirm it’s reading the April backup cleanly before you commit to the restore.

[Alan_C]

Hi, Benjamin,

Thank you for your note.

Per your advice in #3, I created a dedicated Synology user (RoonBackupAccess) with no 2FA and read only access. I created a password that consisted of only letters (upper and lower case) and numbers, and no special characters. I verified that this user and password gave me access to the folders in Synology. I have attached a photo showing the folders in Synology.

In the iPad app, I went to Settings—>Backups—>Find backups—>Add network share. However, as the attached photo shows, I could not add the network share \\192.168.1.7\Roon Core Backup. Neither could I add \\192.168.1.7\Roon Core Backup\RoonBackups nor \\192.168.1.7\RoonBackups, where RoonBackups is the folder with 2f9153…, f5b703…, and _roon_backup_root_.

Where do I go from here? I hope there is a simple fix.

Thank you!

[Alan_C]

Hi Benjamin,

In addition to the above, I would like to point out that I have been trying to add the network share while my setup has the configuration shown in the photo below. Should I delete that first?

[benjamin]

Hey @Alan_C,

Thanks for the detailed follow-up and the screenshots.

We pulled fresh server logs after your attempt, and the Synology (192.168.1.7) doesn’t appear in them at all, every backup operation the server logged is against the local container folder, not a network share. In other words, the “Add network share” is failing so early that the server never gets as far as contacting the Synology. That’s a promising sign, because it usually points to something small in the address or the setup rather than a credentials or 2FA problem.

Here’s what we’d adjust before the next try, roughly in order of likelihood:

1. The share name has spaces. \192.168.1.7\Roon Core Backup, the spaces in “Roon Core Backup” frequently cause trouble. If you can, create (or use) a Synology shared folder with a space-free name that gives RoonBackupAccess read access, and point at that instead, e.g. \192.168.1.7\RoonBackups.
2. Enter only the share, then browse in. In the path field put just \192.168.1.7<share> and navigate into the subfolders (down to the RoonBackups folder containing roon_backup_root) using the browser afterward. Typing the subfolder into the path itself (…\Roon Core Backup\RoonBackups) is a common cause of failure.
3. Check the Synology SMB settings. In Control Panel → File Services → SMB, make sure SMB is enabled and the protocol range allows SMB2/SMB3. Also confirm RoonBackupAccess has read permission on that specific shared folder, both at the share level and the folder-permission level, since Synology’s advanced permissions can quietly block SMB even when the login works elsewhere.
4. Confirm the container can see the Synology. Since Roon Server is running in the container on your QNAP, it needs to be able to reach 192.168.1.7 on your network. If Container Station placed it on an isolated/NAT network, it may not be able to see your other NAS at all, which would fail instantly with exactly this kind of generic error. If you’re comfortable checking, let me know what network mode the container is set to.

Give that a try and we’ll review another fresh set of Server logs afterward. Thank you!

[Alan_C]

Hi, Benjamin,

Thank you for your note. I’m using your numbering for my response.

1. I changed the Synology shared folder name to RoonCoreBackup (no spaces). RoonBackupAcess has read access using a password without special characters or 2FA to all Synology folders. Inside the folder RoonCoreBackup is a folder called RoonBackups, which contains the actual backup folders, including roon_backup_root.
2. You refer to \192.168.1.7<share>. I don’t know what &lt means. Please provide the exact path to use. I have tried \\192.168.1.7\RoonCoreBackup; \\192.168.1.7\RoonCoreBackup\RoonBackups and \\192.168.1.7\RoonBackups. I have also tried the foregoing with Synology\ following \\192.168.1.7 and other variants.
3. I changed the Synology SMB settings from a minimum of SMB1 to SMB2, and the maximum SMB protocol from SMB2 to SMB3. As mentioned, RoonBackupAccess has read permission to all folders under Synology.
4. In the container, the roonserver docker network says the Mode is “host” and Network is “host.” Connection, IP address, and MAC address are blank.

Thank you.

Alan

[vadim]

Hello @Alan_C

Let’s change the approach. We have had you working on the address format, and that is not where the problem is.

Your Roon Server runs in a Docker container, and a container can only mount network shares if it was created with the specific permissions needed for that. It is an option set when the container is built. From the way your attempts fail instantly, with the Synology never appearing in our logs at all, it looks like your container does not have it. That is why no version of the path will work, and it is why we would like you to stop trying that dialog.

The good news is you do not need it. Your container already has a folder on the QNAP mapped into it for backups, and that is where its automatic backups have been going. If we put your April backup in the same place, Roon reads it locally and no network share is involved.

Rather than guess at the path, please use the one already defined in your own container configuration. In Container Station, open the roonserver container and look at its volume mappings. You are looking for the entry that maps a QNAP folder to /RoonBackups inside the container. Whatever QNAP folder is on the left of that pair is the one to use. If you set the container up from a docker-compose file, the same line is in there under volumes.

There is one more thing that has quietly broken every copy so far. Roon marks a backup with small files named roon_backup and roon_backup_root. Each time you copied a backup onto the QNAP, those files did not come with it, and without them Roon does not recognize the folder as a backup at all. That is why it only ever offered you the Tidal one.

So, in order:

1. In QNAP File Station, open its settings and turn on the option to show hidden files. This is the step that has been missing.
2. In Container Station, note the QNAP folder that maps to /RoonBackups in your roonserver container.
3. In File Station, connect to the Synology and copy the whole RoonBackups folder across, the one containing roon_backup_root alongside the 2f91535b… and f5b703… folders. Copy the folder itself, not just its contents.
4. Place that copy inside the QNAP folder you noted in step 2, next to the existing backup folder rather than inside it.
5. Open the copied folder in File Station and confirm you can now see roon_backup_root next to the GUID folders, and roon_backup inside 2f91535b…. If those two files are not there, the copy failed again and nothing after this will work.
6. In the Roon app, go to Settings, then Backups, then Find backups, and browse to /RoonBackups. The April backup should be listed.

One thing to leave alone: please do not delete or reinstall the container again. Your April backup exists only on the Synology at the moment, and we want it to stay there untouched until this is finished.

[Alan_C]

Hi Vadim,

Thank you for your note. I have completed instruction1 and, I believe, 2. (Please see the attached photos.) Try as I might, I cannot complete instruction 3 despite asking an AI for assistance. If you can help, I would appreciate it. Thank you.

Best wishes,

Alan

[Alan_C]

Hi @Vadim,

Thank you for your note. I completed instructions1 and 2. Regarding instruction 3, it took a while to figure out that to move the Synology folder to the QNAP involved the installing a hybrid mount on the QNAP and assigning new permissions. Completing the screen to set up the transfer also had challenges. However, the hybrid mount is now set up and I have access to the Synology folders on the QNAP. I’m having difficulty completing the final step of placing a copy of the Synology folder in the QNAP folder. I’ll try again tomorrow.

Alan

[Alan_C]

Hi @Vadim,

I’m stuck! When I try to copy the whole RoonBackups folder in Synology, the one containing roon_backup_root alongside the 2f91535b… and f5b703… folders, I cannot place that copy inside the QNAP folder I noted in step 2, next to the existing backup folder rather than inside it. The error message from QNAP reads: [File Station] Failed to copy “/Container/roon-backups/RoonBackups”. Failed to access the file.

I would appreciate your help.

Thank you.

Alan

[benjamin]

Hey @Alan_C,

You’ve done nothing wrong, that error is a limitation of QNAP’s File Station, not your setup. File Station’s copy engine is unreliable when the source is a HybridMount connection, and it tends to fail on exactly the small marker files we need. Let’s bypass it entirely and do the copy from your Windows 11 PC, which can see both NAS units directly.

First, a cleanup step: in File Station on the QNAP, open the folder that maps to /RoonBackups in the container (/share/Container/roon-backups). If a partial RoonBackups folder is sitting there from your earlier attempts, delete it. Then you can disconnect the hybrid mount — we won’t need it.

On the Windows 11 PC:

1. Open File Explorer, go to View → Show → Hidden items and make sure it’s ticked. This is the Windows equivalent of the QNAP step and it’s just as important.
2. In one window, open \192.168.1.7\RoonCoreBackup and navigate to the RoonBackups folder, the one that directly contains roon_backup_root alongside the 2f91535b… and f5b703… folders. Before copying, open 2f91535b… and confirm you can see a file called roon_backup in there. If you can’t see it, hidden items isn’t on.
3. In a second window, open \192.168.1.45\Container\roon-backups. That’s the QNAP folder mapped to /RoonBackups in the container.
4. Drag the whole RoonBackups folder from window 1 into window 2, the folder itself, not its contents. Let it finish completely.
5. Verify from Windows that both of these now exist:
   • \192.168.1.45\Container\roon-backups\RoonBackups_roon_backup_root_
   • \192.168.1.45\Container\roon-backups\RoonBackups\2f91535b-8a8a-cfd9-4d94-3141c020ecd8_roon_backup_
     If either is missing, stop there and tell us, nothing after this will work.
6. In the Roon app: Settings → Backups → Find backups, then browse to /RoonBackups/RoonBackups, note the nesting, since the copy landed inside the folder already mapped to the container. Your April backup should be listed.

One thing to do before you restore: in Settings → Backups, turn off the automatic backup schedule so the container’s nightly Tidal-only backup can’t run partway through.

If Windows refuses to write into \192.168.1.45\Container\roon-backups, that’s a permissions issue on the Container Station folder. Go to QNAP Control Panel → Privilege → Shared Folders, edit permissions on the Container share, and give your admin account read/write.

Let us know if this helps, thank you!

[Alan_C]

Hi, Benjamin,

Thank you for your note.

On my PC desktop, I was not able to drag the RoonBackups folder from the Synology to the QNAP NAS. Using the hybrid mount, I did move the folder. When I tried to select that moved folder in the backup of the app, I received the error message in the 2nd screenshot. I opened the folder and saw that root_backup_root file had not moved with the folder containing the data. I then moved that file into the folder with the data as seen in the 3rd screenshot. Unfortunately, I see the same error message when I try to select the moved folder. I do have read/write permissions in the container share.

This issue began at the end of April when, after a Roon app upgrade, I could not access the Roon core. I don’t know if I remember everything that followed, but I recall that, early on, per your instructions, I created a container. I could not access the Roon core there due to the persistence of a “ghost” core. I was unable to access my account to delete the ghost core. After a number of days, the ghost core issue appears to have resolved because I could connect to the Roon core in the container. Since then we have tried to move my backup as of the end of April into the container so that I can access both my thousands of CD tracks and my few dozen playlists.

I appreciate the help you and your colleagues are providing. I myself have spent hours following your advice. After 3 1/2 months, is there something we can do that will resolve this at last? A new account, for example.

Thank you.

Best wishes,

Alan