1.3 update totally borked: CIFS shares go AWOL [resolved]

Latest update: I killed the 1.3 Core-Synology CIFS connection from the Synology Connected Users panel, and everything came back, both with the Mac and Android apps. Definitely looks like 1.3’s Synology CIFS share handling gets into a bad state. Never saw this with 1.2.

Hey @Fernando_Pereira – can you let us know how things are looking with Build 196?

@support Not improved. After I updated to 196, Mac would not see the core, and Android connected to the core but reported an empty library. I killed the core CIFS connection from the Synology connected users panel. After restarting the Android app, it connected to the core and saw the library correctly, but the Mac app is still not seeing the core. Killing the core>Synology CIFS connection again, or clearing the SMB cache, did not revive the Mac app. Update: Rebooting the Mac revived the Mac app. Looks like the Mac app gets stuck in a persistent failure state that can only be reset by rebooting the Mac.

@support Further details: when I got back to my Mac client this morning, it reported that the library was (again!) empty. Killed the core>Synology CIFS connection. Library came back. Clearly there is a problem with the establishment and maintenance of the core-to-library-on-Synology CIFS mount. What can I do to help you fix this problem, which is really messing up with my ability to use and enjoy Roon?

Hey @Fernando_Pereira – thanks for your patience here. We’re discussing your issue and trying to understand what makes your setup different from the many thousands of stable Linux Cores we’re seeing on 1.3 using similar configurations.

Generally speaking, these are some of the most frustrating issues to resolve – when 98% of people in a given configuration are having no issues, problems with the remaining 2% are almost always environmental – a network setting, a bad cable, a failing hard drive, etc. Sometimes it’s a combination of a bug on our side combined with something unique on site, but it’s almost never something simple.

We have a long track record of working at these kinds of issues until we pinpoint the problem, no matter how long it takes, so thanks in advance for your patience.

First off, I’d like to get a look at the logs from your Core. Can you zip up the logs folder from your Core database and send me a Dropbox link to the whole folder? It would be great to know a rough time frame for when your storage configuration last went awry, too.

Can you also let me know the Settings you’re using to mount your Synology? Obviously, I don’t want your log in and password, but a clear sense of the address you’re typing and steps you’re taking would be helpful, as I’d like to make sure the testing we’re doing in house matches what you’re doing as closely as possible.

Thanks again @Fernando_Pereira – looking forward to resolving this soon!

1 Like

My Roon server keeps losing it’s connection to my music stores, so no music appears in my library. The Storage settings menu shows DirectoryNotReady for each store. Here is a screenshot:

This happened after I first upgraded to 1.3, and it has happened with each subsequent upgrade. I’m currently on build 196.

Resetting the Synology fixes the problem temporarily, but after a few hours it is broken again.

My Setup:

  • Roon Server (1.3 build 196) running on Ubuntu 16.04.1 on an Intel Skull Canyon (i7) NUC.
  • Using music library stored on a Synology DS1815+ (with latest software).
  • 4 Music Folders. ~ 3500 albums.
  • Roon Client (1.3 build 196) running on MacBook Pro, 10.12.3.

I have a similar setup, same problem. The easiest temporary workaround that does not require a NAS reboot is to go to the “Connected Users” widget and kill the frozen CIFS connection(s) from Roon Core by clicking on the (-) (wrong way sign) icon. Roon Core then reopens the connection and everything works again, for a while at least. My hunch is that the connections freeze when the NAS hibernates because the new Core software is not handling occasional latency/timeouts properly and marks the connection as not ready rather than retrying the connection.

Thanks Fernando. Where is the “Connected Users” widget?

I appreciate your help.

On the main page of the Synology browser interface, there’s a “Widgets” icon on the top right of the control bar. If you click on that, you can select widgets to be displayed, including the “Connected Users” widget. If you hover the mouse pointer over the user name for a connection in the widget, you get a pop-up with the IP address that opened the connection, which allows you to confirm if that’s the connection from your Roon Core. See the attached image.

Hey @Matthew_Soldo – can you look over my post above, and get me some logs as well? These issues sound related, so I’ve merged the threads here.

Thanks for your patience!

1 Like

Sent you the info you requested (logs + NAS config) as Google Drive links (don’t have Dropbox).

Yet another baffling failure. Controlling the core from my Mac, playing on one of my systems. But Android app (build 196) on my Nexus 6P Android 7.1.1 is stuck trying to talk to the core. After clearing app data, I get “Choose your Core” with the actual core, but it gets stuck in “Initializing…”. But the core is still speaking to the Mac app, which shows everything as working. Rebooted the phone, and the core shows up as ready.

I’m forming a more complete theory of these failures: core state transitions are not being tracked correctly by client apps, with the result that the apps believe the core is not ready when it is actually ready.

1 Like

Yes I believe you are right . I have same problem .

@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).
  • Here is a screenshot of my settings: https://www.dropbox.com/s/vwi9qeivb0c32rb/Screenshot%202017-02-05%2022.52.56.png?dl=0
  • 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:

  1. stop mounting twice and let Roon do your mount exclusively. Nothing changes in Roon, the only change is outside of Roon.
  2. 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.
  3. 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.

1 Like

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!

1 Like