I have the Rivo + with Volumio 3.795 and it will not connect to my music library over my Ethernet wired network. The NAS is running on a Windows 10 PC, which has and is accessed easily and without errors by my Bluesound Node 2i on the same network. The NAS is just standard Windows 10, accessible to anyone on my LAN with no password. The initial error message was THE SERVER IS DOWN, or NOT MOUNTED. It is not down. Node 2i sees it. I have seen others on the forum with these problems, which they fixed by adding the parameter “vers=1.0”. I tried this and same result.
Standard Win10 NAS protocol uses SMB 3.1.1. So I put “vers=3.1.1” in the options field of Advanced options in Volumio. Now, instead of an error message, it came up saying “this drive requires a username and password” asking me to fill in credentials. There is no username or password set up for this NAS.
I submitted this problem with screenshots to Volumio tech support, and the response I got was as follows:
“Setting up a NAS can sometimes be challenging…I highly recommend opening a thread on community.volumio.org, where users with similar setups may be able to share their experiences and solutions. I’m sorry we couldn’t provide a direct fix in this case, but I hope the community can offer valuable insights.” Well, I certainly hope that is the case! I am a little disappointed that Volumio showed no interest in investigating whether they might actually have a problem on their end. Again, this is a very simple standard Win10 NAS with SMB protocol, and it creates no problem for the Bluesound Node 2i, which has been playing music from this NAS for three years.
Any suggestions would be appreciated. Without the NAS my Rivo + loses a good piece of the functionality that it is supposed to provide.
Hi, you are entitled to premium support, please create a support ticket.
@SimonE Seems like he already done that, and was directed to the community.
Please read my post carefully and you will see that that has already been done. Support can’t help and suggested I post here.
Thank you very much for the detailed suggestions. Much of that I had already done, using a R/W Windows SHARE to everybody. I did use the exact IP address in Volumio and it apparently “sees” the SHARE but is wanting credentials that don’t exist. Interesting that you got vers=3.0 to work. I tried 3.1.1, because that is the actual version, but I’ll try 3.0. The guide mentions:
"Giving access to “Everybody” is not enough though as Windows 11 forces password protected sharing. Therefore went to Control Panel → Network & Sharing Centre → Change advanced sharing settings. Opened “All Networks” and disabled “Password-protected sharing”
If that applies to Windows 10 also it could be the problem. But I still don’t understand why Bluesound streamer does not have this problem, and credentials were never needed to get it working. That suggest to me that Volumio could put in a little effort to broaden the compatibility of Volumio OS with Windows.
Again many thanks for your efforts.
I’ll report back if I get it working.
Here is another thread with info about network sharing setup with Windows.
Even though this was for Windows 11, it might be the same for Windows 10 with all their bad documented updated magic.
This to me is a bit short cornering.
You can’t hold Volumio responsible for network connectivity to a NAS or different machine. Every OS has it quirks. The network mapping is pretty well designed, but as user you need to have some knowledge how it works between different OS’s.
Apologies, replied too quickly. Hope you get it sorted.
Technical Overview: Connecting Volumio to Windows 10 SMB Share
Hi @DavidWind,
Thanks for the thorough breakdown — this is a common challenge when using Volumio with Windows-based SMB shares, and it’s worth unpacking why it behaves differently from devices like the Bluesound Node 2i.
Summary of the Issue
You’re running Volumio 3.795 on a Rivo+, trying to connect to a network share hosted on Windows 10 over Ethernet. The share is fully open to local users — no password, “Everyone” permission, and other devices (like your Node 2i) connect without issue. Yet Volumio throws a variety of errors depending on the vers= parameter used in mount options.
What’s Likely Happening
This issue stems from how Windows 10 enforces SMB protocol security, and how Volumio (a Linux-based OS) interacts with those shares using mount.cifs. A few technical points to highlight:
1. Windows Defaults Changed Over Time
Even though the folder is shared to “Everyone,” Windows 10 often still requires authentication unless:
- The network is set to Private
- Password-protected sharing is disabled under:
Control Panel → Network and Sharing Center → Change advanced sharing settings → All Networks → Turn off password protected sharing
Otherwise, Volumio gets rejected for trying to connect anonymously — prompting the “requires username/password” error even when none are configured.
2. Protocol Version Mismatch
Windows 10 uses SMB 3.1.1 by default. However, Volumio (via the Linux cifs driver) may not always negotiate 3.1.1 cleanly — especially when guest access is in play.
Using vers=3.1.1 can sometimes result in unsupported protocol errors, or fallback behavior where Volumio assumes authentication is required.
3. Why Bluesound Node 2i Works
Devices like the Node 2i use commercial SMB client stacks that:
- Automatically detect the correct protocol version
- Seamlessly attempt guest access
- Fall back to DLNA if needed
- Mask these connection steps from the user
Volumio, on the other hand, gives users direct control over SMB mounting via options — which is powerful, but requires more manual configuration.
Suggested Steps to Resolve
A. Check Windows 10 Settings
Make sure these are set:
- Network type: Private (not Public)
- Sharing: The folder is shared with “Everyone”
- Permissions: “Everyone” has at least Read access
- Password-Protected Sharing: Must be disabled under:
Control Panel → Network and Sharing Center → Change advanced sharing settings → All Networks → Turn off password-protected sharing
B. Use Tested SMB Mount Options in Volumio
When adding the network drive in Volumio’s UI, expand Advanced Options and set:
vers=3.0,sec=ntlm,guest,uid=volumio,gid=volumio,noperm
Explanation:
vers=3.0: More broadly compatible than3.1.1sec=ntlm: Older but compatible authentication modeguest: Explicitly request guest (unauthenticated) loginuid/gid: Ensures Volumio has permission to read filesnoperm: Avoids permission issues when Linux can’t read Windows ACLs
If you prefer to test this from the command line (use ssh into Volumio):
sudo mkdir /mnt/test
sudo mount -t cifs //192.168.x.x/ShareName /mnt/test -o guest,vers=3.0,sec=ntlm,uid=volumio,noperm
DLNA as an Alternative
If all else fails, Windows Media Player can expose the music library via DLNA. Volumio supports this natively and will discover shared libraries automatically under the Media Servers section. It doesn’t require SMB credentials at all.
Closing Thoughts
This isn’t a bug in Volumio per se, but more a matter of interoperability between two systems with evolving security defaults. Volumio gives the user full control of the mount configuration, which is powerful but requires precision.
That said, there’s definitely room for improvement — such as:
- A clearer “connect as guest” checkbox
- Auto-detection or suggestion of SMB versions
- More user-friendly error messages when mounts fail
You’re not alone — many users face this exact issue when using default Windows sharing settings. Hopefully this breakdown helps others configure their systems more smoothly.
Kind Regards,
Thanks. I’m working on it!
Wow. That is a most thorough and detailed analysis, and it totally makes sense. I have time to work on this tonight. From an earlier post, I had already concluded that the “password-protected-sharing” option might be the key. The rest of your information is very interesting and makes sense. Thanks for taking the time.
Hi @nerd,
Disappointedly, the above had the same results. I confirmed that the NAS is shared to “everyone”, and I even changed the “read” permission to “r/w”. As it turned out, password protection was already turned off. I have some screenshots of the process.
The scan that happens automatically when adding a drive failed.
So I entered the parameters here.
Volumio asked for credentials as before. As someone else mentioned, I just added anything at this point.
No other messages from Volumio, just returned to this screen showing the NAS as not mounted.
Other than playing around with other version numbers, I’m kind of at a loss. The Bluesound Node continues to play music from the library. Weird.
Hi @Wheaten
I respect your opinion, but I don’t agree. You can’t expect the average streaming customer to have that kind of technical knowledge. There are a lot of very technical people, and the information I got from @nerd included knowledge of Unix command line parameters, which I never would have known about otherwise. And in spite of all of it, it’s still not working. I have played around with all of the parameters I can find on the Windows side, including the ones people suggested here. So if you have any further practical suggestions, that would be great.
That’s why we are trying to help. 
Remote debugging of network related issues is very hard to accomplish, as you see on the extensive reply form @nerd.
WIndows 10 is almost EOS which is also not helping to provide support, as most people moved to windows 11.
To anyone encountering issues with Volumio not being able to connect to a Windows 10 shared folder, especially when guest access or no credentials are used, the root cause often lies in how Windows 10 handles SMB authentication and protocol negotiation by default. These settings have tightened significantly in recent versions of Windows, often blocking unauthenticated clients like Volumio by default.
Here is a comprehensive list of Windows Registry changes that can be made to ensure compatibility. Each change is followed by an explanation of what it does and what to expect after applying it.
1. Allow Insecure Guest Authentication
This setting enables Windows to accept guest connections from SMB clients that do not supply a username and password. Without this, Windows may refuse access, even if the share is marked as accessible to “Everyone”.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Key:
AllowInsecureGuestAuth (DWORD) = 1
Expected result: Volumio can attempt a guest SMB connection and will not be immediately denied with a “credentials required” message.
2. LAN Manager Authentication Level
This setting determines what authentication protocols Windows will allow. The default on modern Windows is NTLMv2 only, which blocks some Linux CIFS clients trying to use NTLM or guest authentication.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Key:
LmCompatibilityLevel (DWORD) = 1
This value allows Windows to accept LM, NTLM, and NTLMv2, offering broader compatibility. For most situations where Volumio does not send credentials, level 1 is sufficient. Higher levels may reject the connection.
Expected result: Authentication attempts from Volumio using NTLM will be accepted, rather than blocked.
3. SMB Protocol Version Controls
Windows supports SMB versions 1, 2, and 3, but SMB1 is disabled by default. Some embedded clients may attempt to negotiate older versions. Enabling SMB2 and SMB3 ensures modern compatibility. Enabling SMB1 is only necessary if the client specifically requests it.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Keys:
SMB1 (DWORD) = 1
SMB2 (DWORD) = 1
SMB3 (DWORD) = 1
Set these as needed. If you do not want to enable SMB1 due to security concerns, omit it.
Expected result: Volumio’s CIFS client can successfully negotiate a supported SMB protocol version (such as SMB2 or SMB3). Without these keys or with incorrect values, you may see “protocol not supported” errors in logs.
4. Disable SMB Signing Requirements
SMB signing adds security but is not supported by all clients, and guest sessions often fail when signing is required. Disabling signing can improve compatibility.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Keys:
RequireSecuritySignature (DWORD) = 0
EnableSecuritySignature (DWORD) = 0
Expected result: Volumio can complete the SMB handshake without being forced to use an unsupported signing mechanism.
5. Disable SMB Encryption
Encryption is used in some versions of SMB3, but not all clients support it. Disabling encryption can prevent negotiation failures during mounting.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Key:
EncryptData (DWORD) = 0
Expected result: Volumio can complete SMB mounting without being blocked due to encryption requirements.
6. Enable Plaintext Passwords (Optional)
Only necessary if the client tries to send unencrypted credentials. Not typically needed for Volumio, but worth testing in difficult cases.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Key:
EnablePlainTextPassword (DWORD) = 1
Expected result: If Volumio sends a password without encryption, the server will still allow it.
7. Workgroup and NetBIOS Configuration
This section ensures Windows and Volumio are on the same workgroup and that NetBIOS resolution works for hostname-based connections.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Keys:
EnableProxy (DWORD) = 1
EnableLMHOSTS (DWORD) = 1
NodeType (DWORD) = 1
Workgroup (REG_SZ) = WORKGROUP
NodeType=1 enables broadcast-based name resolution, which is suitable for simple LAN setups. WORKGROUP should match the workgroup defined in Volumio’s SMB configuration.
Expected result: Volumio can resolve the hostname of the Windows PC, and Windows will respond to requests over NetBIOS.
8. Define Null Session Shares
If you want a particular share to be visible and accessible by unauthenticated clients (like Volumio), add it explicitly.
Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Key:
NullSessionShares (REG_MULTI_SZ)
Value: list of share names such as
Music
Media
Expected result: The named shares will be visible and mountable without credentials.
9. Restart Services or Reboot
After making the above changes, restart the SMB-related services or reboot the system.
Command:
net stop lanmanworkstation
net start lanmanworkstation
net stop lanmanserver
net start lanmanserver
Expected result: Registry changes take effect, and SMB sessions from Volumio can now connect with guest access and appropriate protocol support.
10. Mount Options in Volumio
Once Windows is configured correctly, use these advanced mount options in Volumio:
vers=3.0,sec=ntlm,guest,uid=volumio,gid=volumio,noperm
Or from SSH:
sudo mkdir /mnt/test
sudo mount -t cifs //192.168.1.X/Music /mnt/test -o guest,vers=3.0,sec=ntlm,uid=volumio,noperm
Expected result: The share should mount without prompting for credentials and without protocol errors.
This set of changes comprehensively addresses all known Windows registry controls that influence SMB connectivity and guest session handling. If the mount still fails after these changes, it’s advisable to inspect Volumio’s logs for mount.cifs errors, which can further indicate where negotiation or authentication is breaking down.
If, after applying all of the above settings, Volumio still refuses to mount your Windows 10 share - despite your registry looking like a Christmas tree of legacy compatibility - then congratulations:
you’ve officially made your PC more welcoming than a 1998 cybercafé, and it still won’t share its files.
At that point, it might be time to consider that Windows File Sharing is less of a “feature” and more of a trust exercise between operating systems that don’t particularly like each other.
As a last resort, enabling DLNA on Windows Media Player is like giving up on polite conversation and just shouting your music across the room. Volumio will usually hear it.
Kind Regards,
Darn you honor your name.
Just out of curiosity… Wouldn’t it be way easier to add a user with credentials (in windows) to access the share?
Ah, the eternal question: “Wouldn’t it just be easier to add a user with credentials?”
Believe me - I’ve stared into that same abyss of logic and whispered “surely that’s all it takes.” But alas, I am Nerd by name and by constitution - denser than depleted uranium and forged in the kiln of unnecessary complexity.
Yes, creating a user with a password, setting permissions, and calling it a day would absolutely work…
But where’s the romance in that? Where’s the thrill of spelunking through 17 layers of the Windows registry to convince it that maybe, just maybe, it’s okay to share a folder with a headless Volumio player on your LAN?
Besides, credentials are so mainstream. Real nerds forge NTLM compatibility with sheer stubbornness, a hex editor, and a TCP dump.
In short - yes, it would be easier.
But if easy was the goal, they wouldn’t have named me Nerd. They’d have called me Larry.
Kind Regards,
haha, point taken. Now I am mind travelling to the early 90’s. Leisure Suit Larry…
Try a username guest and with a blank password.
Ignore!!! The way this thread initially dispalyed on my browser. I missed the fact that there had already been many responses to the thread.