Skip to main content

I’ve been noticing lately on my fileserver failed SMB access attempts which I’ve tracked down to two of my Sonos Play:1 speakers.

Warning     SMB    Deny SMB1 host (security limitation).    Failed to log in

I solely use S2 and the online documentation indicates that Play:1 is supported.

https://support.sonos.com/en-us/article/sonos-s2-compatibility

Why are these speakers still attempting to connect with SMBv1? Do they try v1 and if that fails, try v2, etc?

I tried removing all music library shared folders from the S2 application and re-added them; still happening. I don’t see any Sonos configuration options to force SMB versions.

Sonos OS: S2

Version: 15.3

Build: 72240060

Might be helpful if you were to include a diagnostic, so the forum moderators have hard data to look at. Or call Sonos Support directly, which would likely be faster than waiting for a forum moderator to have time to look at the situation. 

And no, there’s no ‘setting’ in the controller to force a particular version of SMB, but I would be very tempted to force a reload of the OS on those particular speakers by unplugging them from power for at least a minute. It does seem odd that they’re trying to connect with SMB v1, when you get an answer, would love it if you were to post an update here. 


I have recently unplugged both speakers as I replaced them in my surround setup (Arc+Sub) with new Era100s and moved the Play:1 speakers, one to each of my kids’ rooms, so they were powered off for 15+ minutes each.

I submitted diagnostics through the Sonos app and will reach out to support directly in the meantime.

Thank you for the reply!


Always worth making the suggestion, when it’s not clear one way or the other.  ;)

Make sure you call in with that diagnostic number,  they don’t look at random diagnostic submissions. 


Interestingly enough, I just got off the phone with Sonos Support who informed me that all Sonos speakers only use SMBv1. I’m fairly certain that is not true since I have multiple generations of Sonos speakers, but not all of them are experiencing this issue. Kinda disappointing from support.

 

Also:https://support.sonos.com/en-us/article/release-notes-for-sonos-s2?language=en_US

 

13.4.1

Release date: 12/07/2021

Sonos products can now connect to local music library shares using SMBv2 and SMBv3.

 


Agreed, sounds like the rep was either misunderstanding, or misinformed. S1 uses only SMB and NTML v1, but S2 uses SMB v2 or v3. I’ve blocked SMB v1 on my WD NAS, but have never looked to see if there were connection attempts from the Sonos. 95% of what I listen to is from that NAS, and it’s been working fine since S2 came out. 

Post that diagnostic number here. The forum moderators have support experience, I think, and while are often busy with moderation duties, might be able to take a look, since they have the ‘magic Sonos access’ to the diagnostics. 

I’m still wary about this being a Sonos issue, though. It seems odd to me (with no special knowledge) that Sonos is even attempting to reach out with SMB v1 using the S2 client. But, I’m not looking at what you are, either.
 

Please, keep us posted here ;)


I found that I could flip my SYNOLOGY NAS between SMBv1 and SMBv2 while music was playing. without any issues.


The diagnostic number is 871851211. Thanks again for the input and suggestions. I’m pretty sure a recent NAS (qnap) upgrade disabled SMBv1 and then I started seeing the access issues in the server log tied to IP addresses that I was able to trace back to the Play:1 speakers.

The latest two attempts were this morning around 5:47:16am. Also to note, whether relevant, is that I have an alarm set to go off at 5:45am that plays a random song from a set playlist. So 2 minutes and 16 seconds after the alarm starts playing the first song, there is an SMBv1 access violation, maybe trying to look up the next song?

 

Thanks again!


Hi @fache 

Welcome to the Sonos Community!

Could you please post a screenshot of your NAS drive’s settings page? Specifically, the one referencing SMB options? Please also include the page that shows which software version your NAS is using. Thank you.


 

Hi and thank you!

 

Attached snapshots of NAS Firmware version, log, and SMB configuration. To note, there have not been any additional instances since. There were a couple instances prior, but did not save those logs.


Hi @fache 

Thanks for supplying those - I’ve passed them on to the engineer that requested them.

You don’t see this error anymore? As in, it’s not 100% reproducible? If so, this will be helpful to know, so please clarify, if you don’t mind. Thanks.


So I found the older logs and it appears to be more than just the Play:1 speakers. Also have logs showing a Sonos Arc, Playbar, and two Play:1 speakers (matched via IP address) with failed logins via SMBv1 starting on April 13.

I have not however figured out a way to replicate the issue. Continuing to try different things and will comment back if I discover a repeatable method.

 

 


Looking further, it appears that right before a SMB failure, the speakers attempt to login as a guest before using actual assigned user credentials

This is a Sonos Arc below:

 

 


Hi @fache 

Thanks for the additional info.


Hi @fache 

I spoke to an engineer about this and it seems the question isn’t “why are the speakers connecting to the NAS with SMBv1” but more, “why are the speakers failing to connect to the NAS using SMBv2/3 on their first attempts”. Meaning, the speakers will fall-back to using SMBv1 if the connections using the higher versions of SMB fail.

Some possible explanations include:

  1. Sonos is currently connecting to different access points. If these points are wired, great. If not, the quality of the backhaul connection could be an issue.
  2. Multiple access points are sitting close to most of the Sonos products. This suggests there might be too much interference. Reducing the amount of APs might help.
  3. We have unknown MAC addresses across these access points - as we don’t know what these devices are, we don’t know if they might be using features such as QoS (Quality of Service), for example, which could cause problems.
  4. Not high, but, we have an average of 18% + interference on these units (wireless/electronic signals related).

When you add the fact that the issue seems to be inconsistent, I’m inclined to put this down to local network conditions, possibly interference. We have a Reducing Wireless Interference help page that should be of assistance.

It may also be an idea to disable the Guest account on the NAS. Where Sonos pulls the credentials from in order to access your NAS can depend upon where/how the network share was added to Sonos - you may see different results depending on whether you are pointing Sonos to a mapped network drive or to a specified network location.

Lastly, if your NAS drive is not connected via ethernet, I highly recommend it.

I hope this helps.

 

 


Thank you for the detailed response!

I am running an Orbi mesh network and all Sonos speakers are wireless, but the NAS is wired into a hub which is wired back to the main Orbi router. We do have multiple satellites due to the layout and building materials of the house (wireless does not seem to like terracotta tile), plus an additional need to act as bridges in some cases for wired devices in specific areas.

I thought I had disabled any/all guest access to the NAS, but given the logs it appears something is getting through. I found an additional setting in advanced network options that seems to restrict guests/anonymous users from viewing shared folders via SMB and will see if this reduces the flags in the logs. It was set to Disabled, but I have it now set to Enabled (strict).

I set up the music library using the Windows desktop version of the Sonos app and configured to direct network share locations, not mapped locations/drives, which prompts for user credentials to complete.

I guess the one lasting facet is wondering why Sonos is seemingly attempting to access the NAS as a guest/anonymous first when it does have proper credentials configured, but perhaps this particular SMB setting will prevent it.

Upon further searching, it does seem that QNAP has many inquiries as to why a guest account exists and whether it can be truly disabled. While it is not configured or activated as a User account via NAS UI, I found guest in the /etc/passwd file on the NAS, but on a positive note, the guest account is not accessible via SSH.

 

Thank you all again for the support!

 

 

 


Hi @fache 

Fingers crossed!

It’s probably fine, but simply because I have on occasion come across systems that are not quite set up ideally, I’ll just mention that with mesh satellites, you want to place them where the WiFi signal is good, but where the additional node will add WiFi coverage to a location that doesn't already have it. Some people place their mesh nodes in locations where the WiFi is bad, which means that the nodes themselves get bad backhaul connections, resulting in any devices connecting to that node having inherited communication problems that they are not made aware of.

You are most welcome!


Just FYI,

Happened again today after making the SMB change (seems to have had no effect), this time from my Playbar that is sitting on the same shelf open air 2 feet from an Orbi Satellite, one that is actually wired back to the Orbi Router. One difference is that this time I had linked the Playbar to a Sonos Move speaker and noticed that I was able to queue up a song with my iPhone Sonos S2 app, it started, then stopped playing and showed an error accessing the music file, had to press Play again on the app, and it started and stopped again with another access error, then pressed Play on the app and it continued with no further issue, which seems to align with the following log warnings.

 

 


Another thing I just noticed is that SonosNet Channel is set to Channel 11 and greyed out (not possible to change) while my 2.4ghz Wireless channel on the Orbi is also set to Channel 11. Reading that this may cause interference, but unsure. Gonna try changing wifi channel and see if the behavior improves.


Hi @fache 

You are unable to change the SonosNet channel because SonosNet is not in use. It also therefore does not interfere with your WiFi, so is nothing to worry about.

In addition, only your Arc and Playbars are using channel 11 - the rest are on 5GHz (channel 48 at the time of the diagnostics).

You could, of course, try SonosNet by connecting one (not an Era) device to ethernet, though I would recommend changing the SonosNet channel straight afterwards (once a couple of minutes have passed and all rooms show in the app). If this makes any rooms disappear, go back to channel 11 to pick them up again and try once more.

I hope this helps.


Thanks for the information around SonosNet! Makes sense that it is likely not interfering since none of my speakers are currently wired. Good to know that only enables if a speaker is wired, but generally doesn’t seem required.

So the bad news is that I went to change the 2.4ghz channel from 11 to 1 after a wireless scan suggested as the cleanest and the Orbi router never booted back up (has power, won’t boot); finally died after ~6 years in service. The good news is that I was able to find a replacement and spent a few hours setting everything back up and the network actually feels refreshed; everything feels a bit snappier.

Will continue monitoring before messing with SonosNet.


Quick update… I have not had any additional SMBv1 log entries since the last one on May 4th before replacing the wireless router. Whether it was the router itself or the wireless channel causing interference, my Sonos speakers appear to be working much better.

Thanks again for the support!


Hi @fache 

That’s great news! Happy Listening!

Also, thanks for updating the thread!