@mike I PM’d you the details. Here is a copy, sans the logs, for others following:
As far as my settings, I have 4 Storage folders mounted in Roon, in the format 0.0.0.6\Music All are subdirectories of that same top level network drive (i.e0.0.0.6\Music\Jazz).
The Roon Server NUC and Synology are both hardwired into the same network router.
Not sure if it matters, but I also have that same network drive mounted on my NUC’s file system (also via CIFS) at /mnt/Music.
I’ve noticed some other weirdness with Roon’s perception of the networked filesystem. E.g. a few time when inspecting the filenames I’ve tracks in Roon (via right click, View File Info) I’ve seen Roon report the filename incorrectly as an alphanumeric code, instead of its actual name.
I originally lost my share on my Sonic Transport / Synology NAS implementation. I rebooted the NAS and all was fine. After about 7 hours playing yesterday it suddenly stopped and I saw that the folder was connected and watching for albums in real time but all the music was gone. I gave up and added a USB drive to the sonic transport whilst this all settles down. The Synology DS3611XS has been rock solid and I have not manually rebooted it for three years until this weekend.
Sonic Transport - Sonic Orbiter, another sonic orbiter, Microrendu, two Chord Mojos, Synology DS3611XS and second backup Synology DS3611XS, Dropbox database backup. All on build 196.
I would add that until second outage the new release looks wonderful and is working really well. You have also done a great job responding so quickly to all the support issues a release like this throws up. You guys are all doing a wonderful job so no problem waiting a little while for a fix.
I should have mentioned my similar setup to @mike when I PMed him my logs and config. My NUC mounts my Synology music share as /media/music. Both NUC and Synology wired to the same close-by Netgear ProSafe switch.
OK, we found the issue, and unfortunately there is no fix, only a workaround.
The problem is that the Linux kernel, with mount.cifs options of ‘nounix’ has a bug a share can’t be mounted both with and without the ‘nounix’ option. The result is what you have seen here, and something we have been able to reproduce outside of Roon, on multiple different Linux versions and platforms.
Roon has to mount with the ‘nounix’ option as it ensure better compatibility with Windows shares (got user complaints about missing files when they would normally be mangled by smb).
Now, you have 3 options to work around this bug:
stop mounting twice and let Roon do your mount exclusively. Nothing changes in Roon, the only change is outside of Roon.
Stop mounting twice and you do the mount completely yourself. Change the location of the storage folder inside Roon to be whenever your mounted it. Just ignore that the “add network share” exists inside Roon.
Mount the share with the ‘nounix’ option outside of Roon. Nothing changes in Roon, the only change is outside of Roon.
Thanks, @danny, that explains it! The reason I had the separate mount was so that I could have a cron job stop Roon, rsync the Roon db to a folder in the SMB share, and restart Roon. But now that Roon has backup built-in, I can get rid of the cron job and the separate mount. Update: I’ve got rid of the separate cron backup and mount, I’ll report tomorrow how it goes.
Update: after removing the separate SMB share mount, Roon Core has stayed up and clients can connect correctly. It looks like the diagnostic and work-arounds were correct, thank you, now I can go back to just enjoying the music!
