SMB Connection Error in Roon 2.49 on macOS Sequoia with Synology DS1520+ (ref#ETPJO2)

Support
1

What’s happening?

· Other

How can we help?

· None of the above

Other options

· Other

Describe the issue

It looks like Roon version 2.49 (build 1525) under OSX Sequoia 15.4.1 suddenly lost the ability to connect to my Synology DS1520+ via SMB, either trying through smb://ds1/ds1-home or smb://192.168.1.59/ds1-home or \\ds1\ds1-home, I get an "Unexpected error". Synology supports up to SMBv3.1 but maybe Roon is only limited to SMBv2.1, but ensuring max protocol support on my NAS is only 2.1 didn't seem to make a difference. It was not right when I upgraded to that version of Roon or when I recently patched my Synology to DSM 7.2.2-72806 Update 2->3, so can't tell what precisely did it. Restarted Roon and rebooted the server, no difference, and the SAN mounts are working fine through SMB elsewhere so it's not that.

So, right now, I'm accessing my NAS through the non-recommended "/Volume" path. Is there a way to get more precise debug logging to see what it's not liking?

Describe your network setup

Ubiquity EdgeRouter X running v2.0.9-hotfix.7 / Netgear switches of various sources, this is all hard-wired, though I do have WiFi that's been disabled.

2

Hello @sam.habash,

Thank you for reaching out to Roon support and welcome to our community!

I’ve enabled diagnostic mode for your account, and we’ve identified an issue with the mounting path:

04/28 03:37:33 Error: [broker/filsystem/drivelistshares/addsharedrive] error adding share: System.Exception: [cifs/mountconfig] invalid cifs path (post windowsization, missing third backslash): smb://192.168.1.59/
   at Roon.CIFSMountConfig..ctor(String networklocation)
   at Sooloos.Broker.FileBrowser.DriveListShares.AddShareDrive(CIFSConfig config)

To resolve this, please try using the following path for the mount in Roon:

smb://192.168.1.59/ds1-home/

Once you’ve made this change, kindly let me know the timestamp when you do this, so we can check the logs again.

Looking forward to your update!

3

Not a change, as I don’t want to disturb the current mounts, but did try to readd at 7:30AM PDT, same error in the UI.

roon-after-trailing-backslash-add
roon-after-trailing-backslash-add493×682 25.6 KB

4

Hi @sam.habash,

I checked the logs and don’t see any trace of a new mount attempt. Would you kindly try again and update me here.

5

Done, after a fashion.

Roon version 1528 appears to fix whatever bug I encountered…and/or equally as likely, upgrading it also cleared whatever caching was going on to prevent the software from actually trying to mount, given you reported no attempt was made, which was obviously not the case…as you can see from this snapshot, no trailing slash is needed (or warranted) and the mount works again.

roon-1528-update-fix
roon-1528-update-fix757×676 33.3 KB

6

“ds1.local” from this machine resolves to 192.168.1.59…though since it’s a multicast DNS address (.local is reserved for those, you learn something new ever day), standard DNS tools like host/nslookup/dig don’t resolve, it but ping does…

the@arcata ~ % ping -c1 ds1.local
PING ds1.local (192.168.1.59): 56 data bytes
64 bytes from 192.168.1.59: icmp_seq=0 ttl=64 time=0.537 ms

— ds1.local ping statistics —
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.537/0.537/0.537/0.000 ms

7

And here’s the screenshot showing which version I’m running, which you can tell from logs, obviously.

roon-1528-version-screen

I looked at the changelog, and all it said was “various fixes and improvements”…

8

Hrm, spoke too soon, lost connectivity with my server and when it came back, looks like SMB stopped working again. Vadim, can you look in the logs again to see if you see anything from my side. Otherwise, the application isn’t even trying to connect and may just be cacheing the failure.

9

It’s actually NOT solved. Still waiting on Roon Support to take another look…

However, I’m able to work around the issue as Roon default “Music Folder” actually works with how I have things setup, and I’m able to move my “listen.to”/sync folder that I put new music in to a local drive.

10

Since you say your issue is NOT solved, I’ll remove the “Solution” flag, which marked the thread as solved and reopen it for @support to look further.

11

Certainly! Here’s the version formatted for the community, with no emojis and a professional tone:

Hello @sam.habash,

Thank you for the update.

As far as I understand, the initial issue with DNS alignment may be related to an outdated DNS cache or the Bonjour service incorrectly resolving ds1 or ds1-home to ds1.local.

04/30 19:54:37 Warn: [roon/cifs] [roon/cifs] mounting failed: mount_smbfs -N -s -o nobrowse '//ds1.local/fu***ou' '/Users/the/Library/RoonMounts/RoonStorage_f69e3f9200b6bf6a7cbc78828a8a71694f1035ba' [rc:68, output:mount_smbfs: server connection failed: Unknown error: -1]

The last attempt to mount the folder occurred on April 30. Please verify that the folder you’re trying to mount exists on the NAS.

Roon uses CIFS (SMB) under the hood for storage mounting.

Manual Mount with Debug Output

Please try mounting manually from Terminal to get more detailed output:

mount_smbfs -o nobrowse '//the@ds1/ds1-home' /Users/the/mountpoint

You’ll be prompted for a password, and this may provide a more specific error message.

Check Keychain Credentials

Sometimes saved credentials in macOS Keychain interfere, especially if incorrect ones are stored. Since we are using the -N flag, Roon may be using outdated or invalid credentials.

To rule this out, open Keychain Access, search for ds1, and delete any stored SMB credentials for that host.

Try Mounting by IP (Bypass DNS)

To eliminate potential DNS issues, you can also try mounting the share directly using the NAS IP:

mount_smbfs -o nobrowse '//the:yourpassword@192.168.1.100/ds1-home' ~/testmount

Let us know the result of this test, and we’ll be glad to assist further.

12

I was just frustrated, hence the clearly bogus and quite obscene epithet used in the volume name which you saw in logs, but that tactic seemed to have worked.

Okay, as requested:

the@arcata ~ % mount_smbfs -o nobrowse ‘//the@ds1/ds1-home’ /Users/the/mountpoint

mount_smbfs: could not find mount point /Users/the/mountpoint: No such file or directory

Obviously, the mountpoint needs to exist, so I will make it:

the@arcata ~ % mkdir /Users/the/mountpoint

And now mounting manually works:
the@arcata ~ % mount_smbfs -o nobrowse ‘//the@ds1/ds1-home’ /Users/the/mountpoint
the@arcata ~ %

As evidenced by this:

the@arcata ~ % df -k | grep mountpoint
//the@ds1/ds1-home 33722204160 17626505440 16095698720 53% 17626505438 16095698720 52% /Users/the/mountpoint

Manually via the NAS IP works fine too.

the@arcata ~ % mount_smbfs -o nobrowse ‘//the:**********@192.168.1.59/ds1-home’ ~/mountpoint

the@arcata ~ % df -k | grep mountpoint
//the@192.168.1.59/ds1-home
33722204160 17626505464 16095698696 53% 17626505462 16095698696 52% /Users/the/mountpoint

I deleted Keychan Credentials associated with logins for ‘ds1’ or ‘ds1.local’, same result.

IMG_5907
IMG_59071920×1440 204 KB

IMG_5908
IMG_59081920×1440 169 KB

IMG_5909
IMG_59091920×2560 342 KB

One thing I should note is the mountpoint is already locally present, so that should have told you mount_smbfs has no problems…

//the@ds1/ds1-home 33722204160 17626505492 16095698668 53% 17626505490 16095698668 52% /Volumes/ds1-home

I tried another mountpoint, and that fails too (smb://192.168.1.12/Sebaplus) …hopefully you can see that in logs, though before that I tried some of the .local hostnames associated with this resource.

It’s clearly a Roon bug at this point in the way that it is calling mount_smbfs, probably something the software has cached. I figure Roon will try to make its own mountpoint when I try to do it through the UI?

13

Hello @sam.habash,

Thank you for the update and testing.

We’ve discussed this with our senior QA and development teams. The team is investigating some possibilities here and, as soon as that investigation is complete, we’ll be sure to follow up ASAP.

You have our apologies for the trouble here, and we’ve greatly appreciated your patience as we continue investigating this tricky issue. We’ll be in touch as soon as we can.