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 2 / 12
There’s a belief amongst some users that the reason for this was due to the Linux kernel being restricted to the 32 Meg memory on the older devices. We have hope that now that Sonos has indicated the 32 Meg devices are being moved to a “legacy” status, there’s some hope that one of the new features coming up in May will be a new kernel, that while not fitting on a 32 Meg device, will include an update to the SMB protocol for the ‘modern’ devices.
Or, if they’re creating a legacy build, then rather than just freezing the latest bloated build they could strip out all the ‘stuff’ that legacy can’t support anyway - e.g. voice - thereby leaving space for a larger kernel.
Zero bytes of the code on the legacy speakers are used for voice. All voice devices have at least 1GB of memory.
Apart from memory, the oldest devices run old versions of Linux on old CPU types. I know little about Linux, but I would not be surprised if modern Linux versions (that have modern SMB support) do not support the ancient CPUs and hardware in the legacy devices.
Zero bytes of the code on the legacy speakers are used for voice. All voice devices have at least 1GB of memory.
Unless you have access to the code base I don’t see how you can say this… So far, we’ve been told that all kit has to run the same version of software, and that the old kit can’t keep up with the latest requirements…. If they already have different kit working on different code bases, then there should be no problem at all making old and new work together seamlessly.
Unless you have access to the code base I don’t see how you can say this
I worked in the Sonos code base for several years, as the main contractor on the Phish project. I also have extensive experience in Alexa integration.
Zero bytes of the code on the legacy speakers are used for voice. All voice devices have at least 1GB of memory.
Unless you have access to the code base I don’t see how you can say this… So far, we’ve been told that all kit has to run the same version of software, and that the old kit can’t keep up with the latest requirements…. If they already have different kit working on different code bases, then there should be no problem at all making old and new work together seamlessly.
The firmware differs in aspects of functionality. E. g. the ONE would not be operational running firmware designed for the Beam.
Unless you have access to the code base I don’t see how you can say this
I worked in the Sonos code base for several years, as the main contractor on the Phish project. I also have extensive experience in Alexa integration.
So, you’re saying that the different devices run different code?
Unless you have access to the code base I don’t see how you can say this
I worked in the Sonos code base for several years, as the main contractor on the Phish project. I also have extensive experience in Alexa integration.
So, you’re saying that the different devices run different code?
Go to About My Sonos System and you’ll see that your Sonos devices are running equivalent firmware builds.
So, you’re saying that the different devices run different code?
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.
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.
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 have full confidence that SONOS will address this in the future. Maybe we will get a SONOS compatible media app that will stream music on our (Synology) NAS. Meanwhile, it is worthwhile to mitigate the security risks. I am doing this by using a Guest account with only read permissions to the music library folder(s).
Using a guest account helps some but doesn’t mitigate all the SMB v1 risks.
I much prefer to not have v1 enabled on my primary NAS and use a dedicated music NAS or a NAS to SMB v1 gateway to minimize the risk as far as possible.
It depends on your ‘risk appetite’ and how you protect your home network and connected devices.
The Sonos Amp is my first Sonos purchase and it could be the last.
It never occurred to me that any company would release a brand new product that only supports the obsolete SMB1 protocol!
Had this been a cheap bit of Chinese kit I might have forgiven it but Sonos is supposedly a high-end manufacturer with a reputation to protect.
Come on Sonos, get your act together or go home …
It never occurred to me that any company would release a brand new product that only supports the obsolete SMB1 protocol!
Well I think they should just remove SMB support entirely to fix the security issue. PC and Mac users will be fine, as those platforms don’t use it any more. Only the tiny percentage of NAS users would even notice.
The other easy fix would be to make SonosLibraryService.exe use .NET Core so it could run on the Linux systems that most NASs use.
Only the tiny percentage of NAS users
As a dedicated NAS-user, I have to ask: do you have any source for this remark?
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.
Me? No, I have no hard data to support my claim, however:
- The amount of posts on the subject on this forum is small
- Sonos have told us that file-playback is a minority of users (~10%) and I conclude from the Universe that NAS users are a small minority of that minority (because who needs that hassle anyway).
Sonos obviously have actual % data from their analytics, and if NAS users were more than a fraction of the population then a better solution would have already been provided for them.
As many have speculated, we will likely know by May: if SMBv3 support shows up for Modern Sonos devices then we can conclude that NAS usage is important to Sonos. If there is no improvement in SMB support then we can conclude that it is not. Time will tell, and soon.
Me? No, I have no hard data to support my claim, however:
Sonos obviously have actual % data from their analytics...
For those people that leave it enabled….
Sure, but data is data. If the sample size is large enough, then it should be representative of the entire population. There will always be those who prefer privacy over sharing their information, as is their right.
It never occurred to me that any company would release a brand new product that only supports the obsolete SMB1 protocol!
Sonos could support SMB 2 or 3 but they would have to remove other functions from the Sonos system to do it. The upgrade would take a big chunk of memory and it is likely there are more users for the other stuff than for SMB.
Still the whole SMB v1 issue is a nothing-burger as you can add a SMB v1 gateway to any other Linux supported protocol for under $50 and a half hour’s time.
SONOS: Seems like adding docker support for unRAID, Synology, FreeNas, (et. al.) would solve the SMB problem for many NAS users since the music would be local to the docker controller.
As has been previously explained, the consensus is that there isn’t the opportunity to do so in the current kernel being used across all players, due to memory restrictions in the oldest players. We will have to see after the modern/legacy split occurs what path Sonos chooses to make, with the knowledge that it may not be on day one of the split, but some number of updates later, depending on effort, QA testing, and beta testing. Or, frankly, if Sonos feels the urge. We just don’t know.
SONOS: Seems like adding docker support for unRAID, Synology, FreeNas, (et. al.) would solve the SMB problem for many NAS users since the music would be local to the docker controller.
I setup a fresh Unraid server and its default enables NT1 in SMB, so Sonos works without problems. As SMB1 is only a security problem in Windows, this has no downside. Discussion:
https://forums.unraid.net/topic/57317-disable-smbv1-following-wannacrypt0r-attacks/
Really crap is that changing the smb server causes killing all playlists as they now link to an non existing server.
You can still force samba to work with Sonos by editing the smb.conf file and adding
client min protocol = NT1
server min protocol = NT1
ntlm auth = yes
to the global section of that file.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.