SMB2 (or SMB3) support must be supported NOW!

That might work if you assume that Sonos hasn’t made the change out of spite, rather than a forced  business decision.

If you read the thread, it’s relatively certain that the issue has more to do with available memory on the devices to contain a Linux kernel that’s been updated to use higher versions of SMB. Not some sneaky desire to repress people like me who play from their NAS almost exclusively. 

This doesn’t sound like a plausible reason for not supporting SMB v2/v3. 

IF Sonos needs to have SMB v2/v3 support at the kernel level, there is probably a way to backport the patches that add support into the kernel they’re currently using. Crazier things have happened. 

However, not everything must be implemented at the kernel level. There’s absolutely no reason that they could not use an SMB client implementation that runs in userland. Many programming languages have third party (or even first party) SMB client library implementations. I have no doubt that Sonos could swap out their current SMB integration with one of these. 

This issue reeks of either incompetence or indifference, neither of which is acceptable when it comes to a company selling hardware this expensive.

I don’t think, @PudgyChicken, that you understand what has been discussed. There is no additional memory space in which they could store a backported version of the kernel. The current kernel appears to have taken all available memory. 

And there just isn’t any spare space on the devices at all, inside or external to the kernel, without removing features. 

Now, if you’re talking S2 devices, that’s a whole different beast, and I could agree with what you’re saying. Which, if you read the thread, we’re all hoping at some point they’ll do. But, as @controlav  and others have pointed out, the amount of folks that want this, while vocal,  is relatively small. It may not be financially intelligent to do that work, which is likely both extensive and costly. It may behoove them to put their limited resources elsewhere, as there are already several solutions, as described in this thread. 

Respectfully, I completely understand what has been discussed. There’s a big difference between backporting a singular feature from a future kernel and upgrading to an entirely new kernel. This is a common practice in applications with very specialized kernel requirements. 

I should have been a little more clear in that I am specifically referring to S2 hardware here, as S1 is considered to be frozen in terms of its featureset. However I am sure that at some point in the last decade or so of people asking for this feature it could definitely have been implemented.

I have to disagree, however, that doing this work is not financially sound for Sonos to undertake. This is the type of feature request that I would have assigned to some zealous summer interns. They get good experience: working with the codebase, integrating a feature, going through the hardware validation process, working with QA, staging changes, seeing their code go live, etc. Meanwhile, I get some brownie points from the community for fixing something that they’ve been asking about for more than a decade at this point. Not to mention the fact that interns are a lot cheaper than senior engineers. 

Perhaps there’s a better point to be made here, however. There are an infinite number of ways in which Sonos could have ameliorated this issue before it got to this point, leveraging technologies that we know the players already have integrated.

For example, why can’t I use a HTTP share on a NAS to host my content? Per the developer documentation on supported audio formats, most file formats the devices can play require HTTP/HTTPS as the transport method. 

Also, why on earth is DLNA/UPnP support so abysmal? Looking through these forums there are myriad issues of people setting up DLNA servers and never having them show up in the app (yes, especially when the flags are set to show  UPnP Servers / Media Servers in the system settings).

Abandoning NAS users who have invested in Sonos hardware is an extremely poor choice. File sharing from Windows / MacOS does nothing to help those who use commodity NAS devices from vendors like Synology. Sure, they could get another device that connects to the NAS and is running 24/7, but the whole point of a NAS is that you DON’T need to have your PC running full time to access your data. 

Plex is a fine choice, except for the fact that 1. the Plex media provider in Sonos has some legitimate issues, 2. casting from the Plex app requires a paid subscription (and also has its fair share of significant issues), and 3. it requires users to install, configure, and maintain an extra system that they don’t care about and most definitely don’t need.

The easiest way for Sonos to shut up NAS users is to just implement a REAL solution already.

Apache supports running as a fileserver right out of the box!

While I do respect your Raspberry Pi solution and agree that it will work for many people, I am concerned about less technical folks like my dad who aren’t savvy enough to set up that sort of solution. The onus here should be on Sonos to provide a solution, it should not be on us to work around their deficiencies!

Any news about supporting a newer SMB version?

Nope, the only reaction that I get from Sonos Support is that they have registered my complaint and that  they are going show it to the Product management team.

No guarantees if or when something will change.

You can go for a “fix” using Docker. Most Synology’s can run it. 
 

have a look here:

When you do be sure that SMB is read only for the use that logs in AND that the data is mounted also read only. So… when a bit locker or something else wants to change your music it will not possible to do so Please do not comprise your NAS security by chasing the security to “lower settings”  

I’ve got it running, works great. 
 

and yes… at the end Adonis should fix this, but they do not seem to be in a hurry… they advertise Plex as a solution… hope they will take this seriously and come with a fix from Sonos!

This is really unsecure, please add support for NTLMv2 asap. :(

I spent half an hour looking for why I couldn’t add my music library and discovered that it’s because it requires smb v1 on the NAS.
Reading this forum put me into increasing disbelief that a) there were trolls saying pull support for NAS (why do you even bother?) and b) there seems to be some excuse that it’s somehow hard to use a current kernel with smbv2/3 support. It’s not and from a security standpoint it’s ridiculous that an old kernel is being used.

For those who are struggling with SMB and don’t want to compromise security on their NAS…

There is already the idea to use a Samba Docker (the one I’m also using), but… for those wo want another option/solution… It look and works impressive, I’m playing with it at the moment.

You can install a docker with Navidrome (https://www.navidrome.org/docs/installation/docker/) or install it differently. To integrate Navidrome with docker you can install bonob SMAPI. When you do that you can add a service in the Sonos App and access all your music without SMB :) A nice extras is that each family member can have it’s own login and favorites section within the service.

More info about bonob can be found here: https://github.com/simojenki/bonob

The both together look like Subsonic, although I’m not 100% if I’m correct since I never installed Subsonic (only read about it).

Maybe this is interesting for some Sonos owners since there is no Samba/SMB security issue in any way.

Look on the other thread. Sonos have acknowledged they are working on smb 3 support. No timescales but it’s good to know pots coming.