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 1 / 12
Userlevel 1
So I should buy another device because sonos can't update past a protocol that's been deprecated for over 5 years? Any buy adding another device I create a major well-known security hole in my network?
Seems like amateur hour. Just add support for v2/v3 from any of the zillion of libraries that support it. Likely even a modern version of whatever they are currently using. Seems like major laziness to me.
Is it really so odd that the same people who spend thousands on even a small home audio system would also happen to spend a few hundred on a home NAS?
Seems like amateur hour. Just add support for v2/v3 from any of the zillion of libraries that support it. Likely even a modern version of whatever they are currently using. Seems like major laziness to me.
Is it really so odd that the same people who spend thousands on even a small home audio system would also happen to spend a few hundred on a home NAS?
I'm a concerned they stop supporting NAS completely, let alone latest security.
Userlevel 1
From a simple user perspective, the fact that only SMB1 is supported is a complete joke.
Userlevel 1
Maybe Sonos does not need more than a software option: A.) System has older devices with limited memory and thus limited to SMB1 and B.) Newer devices only with more memory and SMB2/3. If Option A was default then those who so wanted could upgrade devices and get SMB2 over NAS. I would go for that ASAP if Sonos gave me the option. Currently I'm very reluctant to purchase any more Sonos equipment as I'm worried that Sonos will not continue to support NAS with the latest security features; rather focusing on streaming only. As an early adopter of Sonos I am a bit annoyed that part of the original core functionality is starting to be obsolete... I'm not interested in work arounds with a Rasberry PI, PLEX or something like that.
I bought my NAS solely to supply my own music to Sonos.
Even with Deezer etc there are songs that aren't available to stream.
We don't have computers running 24/7 so it would be a pain if Sonos stopped supporting NAS drives.
I was hopeful the S2 OS (12.0) would support this out of the box, but it appears not.
Shame, as I still cannot access my music library from Sonos it’s back to Plex/MacMini for me. That combination works extremely well.
Userlevel 1
Even with S2, Sonos does NOT support SMB2. This is very disappointing! I would like to know the reasons from a Sonos representative!
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
+22
Tick me off too, a fair amount of what I like to listen to isn’t available from streaming sources.
Support for SMB1 is removed from Synology DSM 7. Many folks might update their NAS, only to find Sonos can no longer connect. SMB1 is being removed from lots of platforms due to security issues, and with all the hacks / ransomware out there, it will stay removed. We need a clear ETA for Sonos to support SMB2 / SMB3.
Using Sonos with Synology DSM7 is fully supported, no work around needed.
DSM7 has SMB1 support, but NTLMv1 login support is now disabled by default.
Just need need to go to: Control Panel → File Services → SMB → Advance Settings → Others → Enable NTLMv1 authentication (it will warn that is vey insecure), and then Save.
Baa! I’m still on S1 :-(
Yes, I know S1 isn’t getting updates, but it’s still a shame it can’t be getting security updates.
The kernel S1 is built on predates SMB 2, and there's no way to update the kernel given the memory limit.
Userlevel 7
+14
Hello everyone, thanks to the introduction of our S2 platform, we've now added support for SMBv3. Sonos S2 devices will use the highest version of SMB supported by your NAS device. To access this update, you may need to manually change the configuration of your NAS device.
Absolutely. They have different CPUs and different hardware abilities and are built with different toolsets. It is all built from the same source tree, but there are different conditionals that control exactly what ends up in each device’s flash image.
Which is standard procedure for embedded systems. In my line of work, it is all determined by pragmas and make files. However, each application still needs the core code, and if that core code doesn’t fit on the hardware, something has to give.
Only the tiny percentage of NAS users
As a dedicated NAS-user, I have to ask: do you have any source for this remark?
Userlevel 1
Only the tiny percentage of NAS users would even notice.
I think you will find a lot of Sonos fans store their music on a NAS.
Whilst most of the planet is trying to cut down energy use, Sonos is suggesting that people leave a PC running just to serve some music occasionally ... that sucks.
I find it insane that this still an issue and there has been no official response from Sonos. I am sure we have all invested a good deal of money into our systems.
Has anybody opened a support ticket to get an official response?
Userlevel 1
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.
Userlevel 1
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.
Userlevel 1
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!
Userlevel 7
+23
There is another possible solution for NAS users: someone needs to implement the Sonos REST service as used on PC and Mac. I’ve had PMs with a couple of folks explaining how to do this, but no-one seems to have done it so far.
Userlevel 7
+22
Knowing what Sonos is actually doing has always been hard, almost impossible now that they locked us out of almost all internal data.
I think both S1 and S2 are still on the same old kernel, can’t prove it though. If you dig through the Sonos GPL documentation you might find evidence of their direction.
I’m sure the S2 will migrate to a newer kernel, maintaining the old one is likely getting more and more difficult. Once migrated it would actually be difficult to force many of the new native protocols back to the antique versions S1 is limited to. When is hard, times are grim and free money to do things is short everywhere, the change will not be cheap.
Memory in Sonos comes in two basic flavors, persistent code/data storage, where the data like music index and playlists live and the programs downloaded from Sonos that run the hardware reside when the device is powered down and random access memory where the programs are run and transient data stored, all that is blanked at power down.
There are charts around that show the amounts of memory in the different devices and versions. The main take-away is the S1 stuff has much less of both types of memory than the S2 stuff.
The lack of memory has forced Sonos to make some hard choices pre-split, removing stuff some customers really liked in order to add new stuff that more customers wanted. With the S2 split they can keep adding to the S2 gear while leaving the S1 alone and not aggravating the S1 owners.
Userlevel 7
+23
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.
The Windows client already includes SonosLibraryService, which is a proxy designed specifically to avoid the SMB problem. SMB is not required when sharing files from Windows (or Mac) devices, this is purely a NAS issue.
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).
Page 1 / 12
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.