SMB2 (or SMB3) support must be supported NOW!

Maybe we should start a petition to the CEO? I’m another Synology DMS 7 user with this same issue.

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. 

Controversial I know …but perhaps a very large majority of Sonos customers have now switched to using online streaming music services and that NAS/Local Library users have become very much in the minority, to the extent that there is no ‘mileage’ in developing this feature…🤔?

I have a fair-sized local music library myself stored on a NAS box, however I do find myself using some of the ‘millions’ of tracks/albums/playlists etc; now easily accessible online via the paid/free streaming music services, probably much more often these days. My local library has started to become a little neglected, truth be told.

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 think Sonos should simply pull support for NAS users entirely. Sharing files from PCs and Macs will still work, and NAS users can use Plex and, more importantly, quit complaining about SMB support.

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. 

If they have no desire to support this or want to pull it all together then they need to come clean with their customers.

Agree with @PudgyChicken that leaving this unpatched reeks of ineptitude or indifference- both are unacceptable IMO. 

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.

Good news, the new Samba code needed and the old Samba stuff Sonos uses are both open source as is the kernel so you should be able to easily pull the needed features from the new Samba and stick them in the old version.

Hopefully that will compile into a small enough image that it will fit on Sonos hardware. Also hopefully, you won’t find so many incompatibilities in the ancient Linux kernel Sonos uses and the new Samba that it is a huge problem.

I’d be interested in trying the HTTP sharing if someone wanted to develop a Linux server for it.

Honestly though $25 and a half hour solved my SMB issues so I’m not going to be interested in anything that is much effort.

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!