I recently switched from using Rygel to minidlna ( https://help.ubuntu.com/community/MiniDLNA  can’t vouch for the guide, I use Debian]) it seems a bit quicker. Mind you I use it for video rather than audio …. the Sonos I drive from a NAS (Qnap) so it has all sorts of protocols under the covers … without digging around and tracing it’d be hard to spot which one I’m actually using . (I know, when I first got the SONOS it was SMB , which pained me a little)

For S2 systems with their larger memories there are a lot more possibilities than there are for S1 gear.

Worst case I’m keeping a master copy of Raspberrian (Raspberry Pi OS) well backed up so I’ll be able to reinstall it on my Pi music servers at need. Don’t need the latest OS for a system well locked down behind a good firewall.

While a good firewall is certainly useful (I have multiple, stacked ones) sadly with modern “appliances” it affords little/no protection.  My Home Hubs. nest, Sonos devices all “call out” to their manufacturers , thus creating a NAT (iptables established) relationship though the firewall.  If you think about it, the fact that Sonos, Google et al are able to apply updates to their boxes through your firewall, without you granting them an incoming port rather makes the point.

My Sonos took to un-pausing and playing loud rock music (AKA Music)  at random points on it’s own (yes I sent diagnostics to Sonos) which I’m assuming was due to some operations somebody (my hope is Sonos) were doing on the device. Short or running wireshark 24X7 and catching it happening, I could not see a way to spot the cause (from outside the Sonos)

I wasn’t talking about Sonos or other devices calling out but a local SMBv1 server that has no reason to call out and can easily be prevented from doing so should it for some reason attempt it. The Pi, the Linux OS and the SMB server are easily restricted to the local LAN.

Dealing with IOT stuff that calls out is an interesting problem but with a bit of networking research you can block a good bit of it, or redirect it to a local service if that makes sense. It is easy to block a lot of the Sonos Internet chatter and you see no loss of functionality for most of it and little loss for a bit more. The core stuff of course can’t be blocked if the system is to remain functional.

The Sonos being activated by something is usually best dealt with by sending Sonos a diagnostic and asking them to look at it. They can usually find the issue quickly. If you want to look at it locally it should be as simple as adding a rule to your firewall and logging packets that trigger it.

Well SONOS have been giving priorities to bugfixes, features etc... which is fine.

But it's all fun and jokes for them until some catastrophe happens about SMBv1 on their systems.

To be honest I have no clue about security and hacks. But a lot of times when problems luke these arise, the company will be throwing all kinda excuses and showing all kinds of reasons why they can't do something. Then something goes horribly wrong and it hits the news. Then within a month there will be a fix for the problem.

And "no". I am not hoping for them to remove all SMB options cuz i also have a private collection on my NAS.

I am just sad that even though many users are having this problem, companies will just show all the bottlenecks about "why it can't be done".

Yet Sonos have proven to be able to achieve a lot of things that other companies are unable to achieve.

Sonos does not support latest versions, however with Synology you can do thisAs a last resort, you can go to DSM > Control Panel > File Services > SMB > Advanced Settings > Others to tick Enable NTLMv1 Authentication. This will lower the security level but allow legacy devices/applications to authenticate via NTLMv1.

This feels like the last straw for me vs sonos.

They just don’t care about those of us who like to use our own NAS stored music libraries anymore.

Or, there are technical reasons as to why this is hard, and they’re working on figuring out how to make it happen. Just because they’re not really saying anything shouldn’t always mean you need to assume the worst. 

I’ve been asking for SMB v2 since the mid 2000s, wish Sonos offered it but the lack is such a minor issue I just can’t get too upset over it. You can solve the security issues for a few bucks using a Raspberry Pi Zero W as a NAS to SMB v1 gateway.

I’m wondering just how much Sonos is motivated to put the newer SMB issues ahead of other stuff that will sell far more Sonos gear. Fixing it when they go to a new kernel in S2 is a no-brainer as it comes with the deal, along with a huge number of other fixes and improvements. The issue is storage and memory, the old Sonos gear just doesn’t have it. After the pain of the S1 S2 split it makes no sense for Sonos not to move towards a newer kernel but that is not fast, easy or cheap.

I’ve been running Sonos for 10+ years, and yes it’s surprising that they only support smb1. 
 

I read on another thread that if you have Plex running, you don’t need to use SMB at all.  I just shut off smb1 on my Synology and boom.  Now I just browse via Plex in Sonos and forget about “music library” direct access. 
 

problem solved - Plex ftw

They are working on a later smb version.  It’s safe to assume it will be for S2 only though.

I hesitate to say this, but my Amp and Ones appear to be talking to my Synology NAS using SMB3 now.  All devices and controllers are running S2 v13.4.

Release notes for S2 v13.4.1 confirm support was added for SMBv2 and SMBv3 shares, installed it yesterday and it has been running great against a Synology backed library. I am very pleased that this has been finally added, getting SMBv1 out of environments is great for security!

https://support.sonos.com/s/article/3521?language=en_US

There may be some glitches with the SMB v3 addition, several topics here on them.

I’m happy to have SMB v1 gone at long last and will happily live with the glitches until Sonos fixes them.

Zero issues with SMB v3.

It appears that Sonos does now work with SMB2.

See post by  Sotiris C of the 14th December on this  thread:

Since over a year ago when SMB1 was dropped by ubuntu (for sound security reasons) I’ve been struggling  to get my library of CD quality (16bit 44.1KHz FLAC) files to play on my Sonos.   I tried Plex - this handles  the art workwell but  for some reason the FLAC playback is unreliable,   (I Tried reinstalling plex re-registration, nothing solid I could  find that would fix the  issue,  Some tracks would never play some  tracks fine even from the same rip\encoding job.  All the while MP3 to Plex to Sonos works fine.)

This morning I reconfigured my library with new share and bingo I’ve got access to my library on sonos again.  Very Happy,
 

Kit list Ubuntu 20.04 LTS for the library share.

Sonos Play3,  Beam.  Controller on iOS and windows.

All upto date as of today. Sonos App 13.4.1, Sonos OS S2,

I’m using Sonos v14 on a PC, android, and a bunch of older and newer sonos play 1/one devices.

Years ago, since I don’t trust enabling SMBv1 from my Synology NAS, I set up a power efficient laptop to copy my music library to, and left that running 24/7 just to serve sonos music media files.

After updating to v14, I thought I’d try removing my local library from sonos, and renaming the folder just in case it could still ‘see it’, and have added my synology served media without enabling smb v1.

IT’S WORKING!!! So minimum SMB protocol set to v2, maximum SMB protcol SMB3. Transport encryption mode is client defined, and enable server signing is force. Enable opportunistic locking is ticked, and enable smb2 lease is ticked. Enable SMB durable handles is not ticked.

I do also have NFSv2 to v4.1 enabled, but when I disabled NFS as an experiment, then Sonos can still play the music. When I disable SMB, it can’t.

So,  SONOS SUPPORTS SMB v2!!! Hooray!!! (And possibly v3, but I can’t enable only v3 on my Synology)

Just went through this pain. Brought up a new Synology box. Super hard to get Sonos to recognize it. Not only do you need SMB1, you also need NTLMv1. Works fine now.

Moral of the story:
1) Sonos makes you turn on two ancient protocols that servers and security pros hate.

2 Synology can be configured to work.

now - what about that horrible STP protocol we need to use on our switches? Blech.

I’m using SMB2 on my SYNOLOGY.

This was resolved a long time ago. I’m also using SMB2. In synology settings, go to file services, SMB. Enable SMB service. I have checked WS-Discovery, if that matters. In advanced settings, General, Maximum SMB3, Minimum SMB2, Transport encryption mode as client defined, enable server signing as fore, enable opportunisitic locking is checked, enable smb2 lease is checked. Then clear your SMB cache, reboot synology and sonos, and try again.  You should not under any circumstances have SMB1 enabled! MASSIVE security issues with SMB1.

Refer: 

Curious as to why you’re pointing to this same thread?

It’s not a link to this thread per se, but to a post above where it’s detailed that SMB1 is now in fact no longer required for Sonos.

My Sonos (S1) system was unable to find my SMB share until I turned on SMB1 and NTLMv1. Then it worked find. Does this statement “this was resolved long ago” apply to S1 systems? Because with the stock Synology setup I could easily connect to the music library from windows, using the same account that Sonos uses. But the Sonos could not see a share until I turned on SMB1, and then it could see the share, but could not access it until I turned on NTLMv1.

This is of course with a fully updated Sonos system, and fully updated Synology.

Only S2 supports SMB versions greater than SMB1.  The S1 kernel was created well before any other versions existed, and cannot be updated due to size issues.