Thanks for tour reply.
I don’t think that’s the problem in my case.
You always start with /share - and better leave out the /DataVol1, as this is just an alias name or logical name for a volume. Try:
/share/M_Media/Container/roon
M_Media is the name of a mounted top-level folder? If you are still confused, feel free to share a screenshot of File Station showing the volumes and mounted top-level folders.
Thank you so much for your help, I figured it out and got it working now. I found the naming a little confusing. 
Hi all, am on unraid and was using the docker from @mackid1993 which worked really well. Made the transition to the new docker image with no apparent initial issues other than a mapping issue where, similar to a previous post, two mounts were required to the same folder to satisfy the mappings from the backup. Some songs will be marked as unavailable unless I map both. Songs don’t double up when navigating albums etc but do double the total counts of albums/tracks in the main screen. I don’t really care but if there’s a logical way to sort then open to suggestions. May just export my playlists start from scratch and rebuild but will see.
I do however now see that, in my smart playlists, anything that was hearted now isn’t. Does anyone else see that at all? Could be just something I screwed up (likely), but just mentioning if it’s some sort of weird edge case that may have cropped up.
Just to follow up myself I think in my situation I must have added a library reference when I last switched docker images without realising and not being able to replicate that exactly caused the issues I experienced. After waiting a while in a playlist Roon actually prompted "Improvements"which meant paths were fixed (though not favourites). Nevertheless just decided to tidy everything up for the official docker image - is quite refreshing going through the library again annd build a few extra playlists! Everything works for me in terms of functionality, Arc via Tailscale etc.
I recently migrated from the community image to the official one, but backups don’t seem to work for me now. Investigating a little bit:
Backup fails due to symlinks in /Roon/database/ — FileNotFoundException
Version: 2.67 (build 1661) production
Backups fail silently in the UI (“Error backing up database”) on the official RoonLabs Docker image. After digging into
/Roon/database/RoonServer/Logs/RoonServer_log.txt, found this:
Warn: [broker/backups] unexpected error doing backup on FileBrowser.Entry: / : /RoonBackups:
Sooloos.SynchronizationContextThreadException: In Broker:Media
—> …
—> System.IO.FileNotFoundException: Could not find file ‘/Roon/database/RoonServer/RoonDotnet/RAATServer’.
at Interop.ThrowExceptionForIoErrno(…)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, …, Boolean failForSymlink, Boolean& wasSymlink, …)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_1.b__1(String file, Boolean needs_copy)
The file exists — but it’s a symlink:
$ find /Roon -name “RAATServer”
/Roon/RAATServer
/Roon/app/RoonServer/Appliance/RAATServer
/Roon/app/RoonServer/RoonDotnet/RAATServer
/Roon/database/RAATServer
/Roon/database/RoonServer/Appliance/RAATServer
/Roon/database/RoonServer/RoonDotnet/RAATServer ← symlink
$ ls -la /Roon/database/RoonServer/RoonDotnet/RAATServer
lrwxrwxrwx … RAATServer → /Roon/app/RoonServer/RoonDotnet/RAATServer
It looks like the official image symlinks binaries from /Roon/app/ into /Roon/database/. The backup code walks the database directory, hits RAATServer (a symlink), and
.NET’s SafeFileHandle.Open is called with failForSymlink: true — which throws FileNotFoundException on symlinks rather than following them. Backup aborts.
This affects both NFS-mounted backup destinations and paths inside the container filesystem — the failure is in file enumeration, before any write happens.
Note that I did restore my library from backup when migrating images, as that was the correct path to migrate, as far as I could tell.