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 10 / 12
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?
Userlevel 7
+23
@lastmuel you are entirely mistaken. The controller is required to set up the link between the library and your speakers, yes. Once set up it is the speakers that read the files over the network, and have the SMBv1 limitation.
The controller is a remote control. It does not participate in playing music at all. (Unless using AirPlay or Android-on-this-device). It is not required once the music has been started.
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?
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,
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.
Userlevel 7
+23
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?
You don’t appear to understand the roll of the Controller: it is a remote control. It does not participate in music playback (exceptions listed above).
Sonos does not, and will never, REQUIRE a controller to be alive and running in order to play music. That is an anathema to its whole design. Speakers are where the brains are, they get the music (from file shares, music services and each other).
The controller does not “serve the bytes of local files” (exception listed previously).
You are proposing using the controller as a proxy between file shares and speakers: we know this is not possible on iOS for example (which is why play-from-this-device was removed) and would be a huge battery burner on Android. It also adds additional wireless hops into the music path (adding unreliability as SonosNet and Ethernet are not options there), through devices that are not designed for continuous high-power use (ie mobiles).
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.
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.
Userlevel 7
+21
All
Sonos have confirmed they are looking into SMB upgrades. See this thread:-
Danny, you can stop feeding now ;)
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.
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.
I didn’t see it as a trolling case personally. Perhaps a matter of semantics, but the incorrect idea that the controller software is involved in the delivery of music to the speakers is a common one I get that you’re intermingling the Sonos software for control and software/service is involved with delivery of local libraries, and that difference is irrelevant to you...but lack of clarity on the role of the Sonos controller software has caused much confusion in other discussions.
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.
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.
Userlevel 7
+23
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.
For sharing files on a PC, it makes sense that the PC is powered on, and running the http server. No-one needs to be logged in though, and certainly no controller needs to be running.
For sharing files from a NAS however, requiring that a PC also be powered on to run the http server as a proxy, seems sub-optimal. Else why even use a NAS: put the files on the PC in the first place.
The “correct” solution would be to run the Sonos http server on the NAS itself. This is not difficult technically, but no-one seems interested enough to do this.
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.
2 years after this post SONOS have still not resolved this issue. They forced us to upgrade to V2 products to “enable new functionality” but their customers security apparently isn’t important to them. BlueSound do recognise the issues with SMBv1!
Userlevel 7
+21
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.
2 years after this post SONOS have still not resolved this issue. They forced us to upgrade to V2 products to “enable new functionality” but their customers security apparently isn’t important to them. BlueSound do recognise the issues with SMBv1!
Sonos have confirmed they are working on the issue and plan for SMB 3 support. No date has been given, nor is that likely to be given until it arrives.
I suggest you go with Bluesound if it is that vital to you. Not sure what the forcing was for S2 is about, none of the new functions affects the prime music playing functions, it was more to support new devices from what i can see, as well as Dolby Atmos
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.
Userlevel 7
+17
That would be great! Any news about the 65k limit?
I want to use my Sonos with my Synology without using an insecure filesharing protocol. Is that really such a tough ask?
I want to use my Sonos with my Synology without using an insecure filesharing protocol. Is that really such a tough ask?
Did you see my comment below?
“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.”
I join the requirements to introduce support for SMB2 and SMB3. 2022 is coming soon!
I join the requirements to introduce support for SMB2 and SMB3. 2022 is coming soon!
Read the thread, particularly the post above yours. It’s already here.
I join the requirements to introduce support for SMB2 and SMB3. 2022 is coming soon!
Read the thread, particularly the post above yours. It’s already here.
I guess biggest issue here is NTLMv1 not really SMB versions. My Sonos speaker cannot access Synology as NTLMv1 is security risk.
EDIT: When I’ve enabled SMB v3 on Synology (by default it was up to SMB v2 only) actually I can again connect to Synology.
I got my Synology already working with SMBv2 for a while and shared my experience in this post
I got my Synology already working with SMBv2 for a while and shared my experience in this post
Could be. If you disable smb1 then Sonos speaker auto connected to smb2 (obviously). What I did is left smb1 and risen the maximum smb to smb3. Speaker auto recognized it and connected to smb3. Later on I completely disabled smb1 and all continued to work.
So, to solve Sonos to Synology interconnection either disable smb v1 or allow smb3 as maximum smb allowed. This worked to you or latter to me.
Page 10 / 12
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.