Hey @Sevenfeet,
Thanks for writing in and for sharing your report! From a fresh Roon Server diagnostic report, we can see that every time Roon tries to enumerate backups from /RoonBackups, it throws a Critical NullReferenceException inside GetRestoreItems:
Critical: scx: System.NullReferenceException: Object reference not set to an instance of an object.
at RoonBackup.Backups.GetRestoreItems(...)
This happens consistently; it’s not a transient error. Roon can see the /RoonBackups mount (it lists it in the file browser), but when it tries to actually read the backup structure inside it, the code crashes immediately.
Some additional thoughts on this:
Roon’s backup format is very specific. It doesn’t just look for “a folder.” It expects this exact nested structure:
/RoonBackups/
└── /
└── /
├── backup.json ← REQUIRED
└── ... (other backup files)
What you currently have in FileStation is:
/RoonBackups/
└── 084f10e3-0fb2-ba7d-faf3-0701931e2888/ ← just one folder
The NullReferenceException in GetRestoreItems is almost certainly triggered because backup.json is missing or the subfolder hierarchy is wrong. Roon reads backup.json to understand the backup set, and if it can’t find it, the object it tries to use is null.
- Open that GUID folder in FileStation and look inside. You should see another GUID subfolder, and inside that, a
backup.json file plus files like RoonServer.roonbackup or similar.
- If the folder contents look like just a bare copy of files without that
backup.json, the backup copy may be incomplete or from an incompatible format (e.g., copied from a QNAP backup app rather than Roon's native backup).
- If your old Roon install (the
.qpkg version) saved backups to a different path, make sure you're copying the right folder — the one Roon itself created, not a system-level backup of the QPKG data directory.
With that, we also see both /Roon and /RoonBackups are mapped to the same ZFS Dataset
The logs show something unusual:
/RoonBackups → zpool1/zfs26
/Roon → zpool1/zfs26 ← SAME dataset!
Both volumes are backed by the same ZFS dataset. This is almost certainly a misconfiguration, they should be separate. It’s possible the QNAP Container Station volume mapping is conflating them. This could cause subtle filesystem behavior that confuses Roon’s backup scanner, though it’s secondary to the structure issue above.
What to do: In your Docker Compose, confirm the host paths are genuinely different on your NAS — /share/Container/roon vs /share/Container/roon-backups should be separate folders on the filesystem.
I’d confirm the ZFS dataset split In QNAP Storage Manager, verify that /share/Container/roon and /share/Container/roon-backups are actually separate shared folders, not the same one with a subfolder alias.
Then, restart the container and try the restore again. After fixing the structure, restart the roonserver container, then in the Roon app go to Settings → Backups → Restore and browse to /RoonBackups.
Let me know if any of the above help! 
