We are writing summer 2019 and still Sonos only supports SMB version 1 for the Music Library share.
This is not acceptable.
A file share running SMB1 is extremely vulnerable to all the variants of cryptolocker virus that exists today. File share servers (NAS, Windows, Apple OS) can only support one version of SMB - so you cannot from the same box have one file share (for Sonos) using SMB1 and the other file shares using SMB2 or SMB3. This way Sonos puts each and every file share at serious risc - just because they don’t update their file share protocol to comply with this century.
And for the record - the “solution” through PLEX is not a solution. Unstable at best.
Page 6 / 12
That would indeed be odd, since both of those run on your local device or the server,and not on the limited memory of the Sonos equipment.
Well one of my speakers is the new Play One which Sonos said we needed to support Airplay and other features. I imagine implementing Alexa is a little more memory demanding than adding an SMB2 stack.
Userlevel 7
+22
Been saying that for many years, no Sonos update in sight.
Easy solution to the security issues is use a NAS to SMB v1 gateway so your NAS can run in secure mode but Sonos can see your music through the v1 gateway.
I did it on a Raspberry Pi, a Zero W is a good choice.
Thanks Claus. Unfortunately it is not working with my beta version.
Well one of my speakers is the new Play One which Sonos said we needed to support Airplay and other features. I imagine implementing Alexa is a little more memory demanding than adding an SMB2 stack.
Actually no, Alexa is an app that can easily run on the current Linux kernel. SMB is s system service that is tightly integrated into the current kernel. Going to v 2 or 3 requires a newer kernel, as well as porting all the Sonos patches and tweaks. Not fast or easy and you don’t find Linux kernel programmers cheap either.
They have a Windows client they regularly update. There is no reason they couldn’t do a secure proxy through their own software without additional configuration or accommodation by their users. Windows programmers are not rare, nor necessarily expensive. Again, Sonos is a “premium” product and they charge accordingly for those products. So I get it, you think we should all roll out our own hardware to address Sonos’s unwillingness to address well know, long existing security flaws. So noted, I respectfully disagree. We can agree to disagree.
Additionally, it’s the software on the speakers, and not the desktop/mobile controller that is accessing the music on the NAS. Hence the oft referred to memory issue for an updated kernel that supports a higher version of SMB on the early players/speakers.
Userlevel 7
+22
For folks like me that have neither Windows or a Mac running, neither are a good option.
The Pi fixed my issues for a few bucks and a couple watts of power, no other solution comes close here.
I don’t think we should roll out our own hardware to fix a Sonos option. I just don’t see another viable option for NAS users.
I’ve been bitching about the Sonos SMB v1 issue since about 2008. Not seen any result.
I have abandoned any hope of seeing a Sonos solution and dealt with the issue as the only viable alternative.
Hundreds of posts here have had no impact, so don’t hold your breath.
Particularly for a SMB v2 fix for S1 systems although a dedicated Sonos Music NAS or Gateway in a Boost case would be really neat for S1 folks. Easy to just stuff a Pi in there and ship it too.
I am looking for a resolution to the SMB1 fiasco. It appears that SYNOLOGY is going to disable support for SMB1 when DSM V7.x is released. I have multiple SONOS, NetGear NEOTV550 and now Zappiti media players that require SMB1 and they will not work with latter versions.
I just purchase the Zappit OneSE4K HDR in December 2020 and will try to return it back to Amazon since it appears that it cannot be updated to support a newer version of SMB. None of the reviews of the product mention that the product required SMB1.
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.
Userlevel 7
+23
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?
No. On a PC Sonos install an http server (SonosLibraryService.exe) that reads the local file system. The speakers do http GET calls to that. PC local libraries hasn’t used SMB in a year or three.
controlav,
If I have local music files that are only accessible via an HTTP service running - a service that is part of the Sonos controller install - how is it that the software is never, ever, REQUIRED?
How do the speakers get access to those local files without a SONOS http service running? Are the speakers caching music when I turn my PC off? Clearly SONOS is running a service that allows the speakers to access those bytes AND the PC is required to be running for those bytes to be available to the speakers.
I would like to propose a test for your assertion that “Sonos does not, and will never, REQUIRE a controller to be alive and running in order to play music.”.
Please test this on your local setup and share your results:
- Install the controller software on a PC of your choice
- Add local music files to your controller software and music library so that the speakers can access that music.
- Turn off your computer.
- Play music from your library on your SONOS speakers.
I will await your results.
Userlevel 7
+21
I’d be interested in trying the HTTP sharing if someone wanted to develop a Linux server for it.
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!
10.1.1
I have to agree, we all want a solution. It’s safe to assume S1 will never get one though.
For S2 the worry is that Sonos is focussing on Streaming music over locally stored tunes, and given they have supplied a workaround for SMB, they may not even have this on any development list.
controlav,
If I have local music files that are only accessible via an HTTP service running - a service that is part of the Sonos controller install - how is it that the software is never, ever, REQUIRED?
The service and controller application are two distinct things. Whether or not the service is installed when the controller is installed is irrelevant.
How do the speakers get access to those local files without a SONOS http service running? Are the speakers caching music when I turn my PC off? Clearly SONOS is running a service that allows the speakers to access those bytes AND the PC is required to be running for those bytes to be available to the speakers.
This is correct, but you are now talking about a service rather than the controller app.
I would like to propose a test for your assertion that “Sonos does not, and will never, REQUIRE a controller to be alive and running in order to play music.”.
Please test this on your local setup and share your results:
- Install the controller software on a PC of your choice
- Add local music files to your controller software and music library so that the speakers can access that music.
- Turn off your computer.
- Play music from your library on your SONOS speakers.
I will await your results.
If your music library is located on a NAS or some other computer, it will work just fine. If the music files are on the PC you just turned off from power, it won’t. A better test would be replace step 3 with ‘close the Sonos controller program’ or even ‘uninstall the Sonos controller program’ for the case where the PC hold the music files.
Presumably, that means you think I’m a troll. That’s not the case.
But, I don’t enjoy discussions with someone that’s being intentionally obtuse. I guess that makes me a troll.
Regardless, I still don’t understand why this software issue couldn’t have been resolved outside of the domain of the speakers themselves - if Sonos is responsible for running an HTTP server that serves local music files to the speakers, that HTTP server could be configured to proxy bytes off of an SMBv2/3 share.
I’m happy to drop out of this conversation as there seems to be a toxic culture here. I guess that I needed to spend more time learning nomenclature and system architecture before asking a question.
Otherwise, a basic question becomes a syntactical journey on why mobile devices can’t support something entirely unrelated. It seems you lot have invested a bunch of history here and it’s not a healthy place to pose an honest query.
Userlevel 7
+21
Presumably, that means you think I’m a troll. That’s not the case.
But, I don’t enjoy discussions with someone that’s being intentionally obtuse. I guess that makes me a troll.
Regardless, I still don’t understand why this software issue couldn’t have been resolved outside of the domain of the speakers themselves - if Sonos is responsible for running an HTTP server that serves local music files to the speakers, that HTTP server could be configured to proxy bytes off of an SMBv2/3 share.
I’m happy to drop out of this conversation as there seems to be a toxic culture here. I guess that I needed to spend more time learning nomenclature and system architecture before asking a question.
Otherwise, a basic question becomes a syntactical journey on why mobile devices can’t support something entirely unrelated. It seems you lot have invested a bunch of history here and it’s not a healthy place to pose an honest query.
Lastmuel, my apologies. Seems i was too hasty.
The trouble is you assume the app does some work for the system once music is playing. In reality it does little, which is why you can close it without the stream stopping. It’s just a remote control to the speakers when playing from a music share. If there was a simpler way it would have been put into effect ages ago. The firmware on the speakers does all the heavy lifting and for the older speakers the space for adding smb 2 or 3 was insufficient. I’m sure I’d Sonos knew this 10 years ago their architecture would be different.
S2, and newer speakers has doubtless opened up options and we now hear SMB upgrades are on the cards it’s great news.
And again my apologies, there have been a lot of previous cases of people signing in just to troll on issues, mainly not being able to play music direct from ios devices. They post a load of negative posts only to disappear. Look back at some of the negative posts at the beginning of this thread gives you an taste too.
Userlevel 7
+17
That would be great! Any news about the 65k limit?
bockersjv,
Thanks for the response.
I’m now aware that my original assumption that the Controller was what serves local files was incorrect.
It is interesting, as to an end user, it isn’t obvious that the Controller (GUI) software is a separate piece of code than the HTTP server that provides music files to the speakers. They are, after all, installed together.
I have to say, with knowledge of the distinction between the two pieces of software, I believe my original premise stands.
I don’t see why support for brokering network file shares through the HTTP server that’s already running on a local PC couldn’t be added. This would certainly be an easier engineering task than trying to get a larger Linux kernel loaded into the older speakers. And, it would have the benefit of working with the investment that folks have already made into old and newer hardware.
It would also mean that it’s possible to avoid running a Raspberry Pi with flawed software - which seems to already suffer from the “additional wireless hops into the music path” problem.
Same as all people here.
It’s very strange that Sonos doesn’t solve this SMB2 compatibility for S2 products…
It lasts for a while, and soon DSM7 will be realesed in final version, and problem still here.
I stopped to buy Sonos products since I installed DSM 7 beta, and if there is no solution (not the SMB1 patch) I will make a cross on this mark !
I want to use my Sonos with my Synology without using an insecure filesharing protocol. Is that really such a tough ask?
While you’re at it, please provide the extra memory needed to update the Linux kernel on all older product, so that it can manage the updated kernel that is able to handle newer versions of SMB. I assume sending someone to my house with the chips necessary, with the capability of opening each speaker and replacing the memory chips should be simple, correct?
Workaround:
Activate NTLMv1 on NAS File server settings:
But this is not recommended, because insecure.
I’m just hoping Sonos doesn’t just drop SMB sharing and make the whole problem go away. That would be the easy path, couple edits to the source code and push an update and POOF, no more SMB complaints.
Perhaps sensible for those individuals bothered by this to lock their systems down tightly….
I’m just hoping Sonos doesn’t just drop SMB sharing and make the whole problem go away. That would be the easy path, couple edits to the source code and push an update and POOF, no more SMB complaints.
Perhaps sensible for those individuals bothered by this to lock their systems down tightly….
Remain on S1 and your system will be frozen, safe and sound.
I’m just hoping Sonos doesn’t just drop SMB sharing and make the whole problem go away. That would be the easy path, couple edits to the source code and push an update and POOF, no more SMB complaints.
Perhaps sensible for those individuals bothered by this to lock their systems down tightly….
Remain on S1 and your system will be frozen, safe and sound.
Not necessarily…. Who knows what controller kit Sonos will force to ‘retire’ next by stopping supporting it? Better to stay in control - lock off now and only update if you’ve carried out a risk assessment ;-)
Userlevel 7
+22
If Sonos did drop SMB v1 for security reasons I can’t see any way they wouldn’t do it for both S1 and S2 systems.
If they would publish the HTTP information I’d be busy getting a Raspberry Pi version up and running. Both as a server and as a gateway to a NAS running other protocols.
Page 6 / 12
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.