SMB2 (or SMB3) support must be supported NOW!

controlav,

With respect, please go back and read my first post.

If the controller is able to serve the bytes of the local files, why can it not serve the bytes of files on an SMBv2/3 share?

I imagine that the Venn diagram of people that own at least one Sonos speaker, a NAS - but a network that lacks the throughput for this operation looks a little asymmetric.

If the controller is able to add multiple local directories to share via a local HTTP service, it can also add the ability to proxy bytes that aren’t hosted on a local drive. I’ve written this same chunk of code myself. This issue is easily solvable without touching the speaker at all.

Controlav, how do the speakers get access to local music files in a directory on a PC that has the Sonos controller installed? Is the controller software opening a file share on the PC using smb v1?

This discussion is in regards to the Sonos Controller software, correct?

I want to make sure that I’m not confused here. My experience with Sonos and SMB is trying to set up a folder from within the Sonos Controller that runs on a PC. And, that doesn’t seem to work unless it’s SMBv1.

It seems to me that the controller software has the ability to add local folders with music to the controller in a music library.

Presumably, that’s so the controller software can serve the bytes from the local music files to the Sonos speakers via some proxy scheme. 

If that’s the facts here. Why is firmware for the speakers part of this discussion at all?

If the controller software is what’s responsible for delivering bytes to the speakers, who cares what network protocol the speakers support?

If the controller software isn’t what’s actually serving bytes for local music files, why does it exist in the first place?

And if the controller software serves bytes from a local drive, why can’t it broker bytes from a network share on SMBv2/3? Why does the speaker care at all?

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. 

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.

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.

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

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!

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.

Any news about supporting a newer SMB version?

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!

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.