This means a SMBv3 connection has been enabled, connection is not encrypted but signed.
BUT: SMB v1, which is considered insecure, is still allowed. Shouldn’t at least SMB v2 be forced as minimum SMB version for security reasons?
Also: There doesn’t seem to be any option to manually set the login credentials through the ROCK web GUI. “guest” / “guest” is quite simple and no big step uo from anonymous access IMHO. It would be nice, if users could set an individual password to enhance security.
I have this, too. I just reinstalled ROCK with UEFI / OS 3.0, and when I connected from my MacBook (macOS 26.5) > Finder > Network to ROCK/Data, I was never asked to supply the guest/guest credentials.
According to Apple, this only occurs when “guest” connections are allowed:
Select how you want to connect to the Mac:
Guest: You can connect as a Guest user if the shared computer permits guest access.
Registered User: Connect to the other Mac using a valid login name and password. If “Only these users” is selected on the other Mac, make sure the login name you’re using is on the list of allowed users.
Just wanted to report, that anonymous (guest) SMB access with read/write permission to the internal drives is still possible with the latest RoonOS 3.0 build 281.
Testing with Mac Finder (MacOS 15.7.9 and 26.6.2), still the same behavior as in my original post.
However, when trying to access rock via smb using the files app on my iPad (iPadOS 26.6.1) i get the following results:
anonymous (guest) access: read only
registered user with user/password “guest”/“guest” (as specified by Roon): no access, wrong credentials
Edit: I also tried accessing rock using Windows Finder (Windows 11) with the following results:
anonymous (guest) access: can’t test this because it’s prohibited by Windows11 security policy
registered user with user/password “guest”/“guest” (as specified by Roon): no access, wrong credentials
Strange, that the SMB Server behaves differently with different clients, but it does.
Probably this has to do with the strange choice of “guest” as a registered username for non-anonymous login while it’s at the same also used for guest (anonymous) access and gets confused at the SAMBA server side in RoonOS?
Correct, i just wanted to give a complete picture here.
For Windows user this means, that you can’t acces your rock device at the moment via SMB at all, so you can’t upload new music to the internal storage, download logs etc.
One more thing: When logging in as registered user “guest” in Mac Finder, it still shows “Verbunden als Gast” (german for “connected as guest”) instead of "Verbunden als ‘guest’ " (connected as user “guest”) which indicates to me, that in the background the login process falls back to anonymous guest login instead of registerd user “guest” login.
So much confusion. Probably a first step to resolve this would be if Roon changed the login credentials for registered user to something easily distinguishable from “guest”, e.g. “roon”/“roon”. This way you could actually easily see wheter you are logged in as guest (anonymously) or as registerd user…
Well - if you don’t keep up with Microsoft futzing around, then yes. But fortunately, this issue is old news to those who read the Roon Labs Knowledge base articles.
Agreed, but RoonOS 3.0 specifically claims to introduce SMB login as registered user and to remove anonymous login as security enhancement and compatibility update regarding standard Widows 11 security policy.
As of now, this doesn’t seem to be functional in the latest Early Access Build 281 and needs to be worked on.
Also agreed. But if nobody points out the errors, they can’t be resovled.
And this is a long standing issue from day ONE of Roon OS 3.0 in early access (build 272 in May 2026) and still hasn’t been adressed.
So let’s hope, Roon doesn’t continue to ignore this and takes the neccessary time to correctly configure smb.conf (5 minutes, maybe 10?) before shipping this as a production release…
If it helps in something, I gave up on connecting via windows a long time ago since access got complicated. Everytime I need to get into Rock share, I do it in IOS. No user, no pw, no stress…
According to the roon help center article linked, Windows security blocks both anonymous access to network shares as well as access with user / password “guest/guest”.
So the choice of user / password “guest/guest” as default (and not changeable) login credentials for RoonOS 3.0 seems rather odd (or maybe even plain stupid?) as it obviously doesn’t solve the Windows security policy issues and still needs the user to disable this policy.
Also, if you ask the AI of your choice whether it’s possible to use an explicit user ‘guest’ for non-anonymous acces to linux SAMBA share, you get a result like: Yes, but it’s strongly discouraged to do so as it conflicts with the default internal ‘guest’ user for anonymous acces and needs some complex configuration to avoid this conflict.
The fix for both of this is quite simple and straight forward: Use a different user / password combination for accessing rock via smb, e.g. “roon/roon”.
I think you’re mistaken here. It’s actually the other way round.
The Microsoft security policiy of not allowing insecure guest logons has been introduced in 2024 and therefore quite significantly predates the release of RoonOS3.0 on early access in May 2026 which introduced the “guest/guest” login. This was not present in RoonOS2.x before.
See for example this forum discussion on the topic from october 2024: Unable to access SMB 1.0 share on Roon Nucleus from Windows 11 (ref#IOMJ3O) . There are many other similar discussions pointing to the same issue. IIRC, the Roon help center article on the matter you linked above was published shortly thereafter or somewhen in early 2025.
So it seems Roon could and should have been aware that “guest/guest” doesn’t work with Windows 11 without tinkering with security policies at the time they prepared RoonOS3.0 for early access testing.
Probably just nobody in EA noticed so far because all existing ROCK users with Win11 had their security policies lowered already way back in 2024/25 to keep access to their existing RoonOS2.x installation possible?
I’m a Mac user and tried accessing RoonOS 3.0 from a Windows machine just yesterday for the first time for testing purposes. Never tried this with RoonOS 2.x before.
Anyway, i’m not here to debug RoonOS, that’s the job of Roon staff. I think i gave enough clues on where to look to resolve this issue and it’s time for Roon to take action.
RoonOS v1 and v2 chose anonymous access before Microsoft made it a problem (what Geoff meant)
Microsoft made it a problem and forced users to allow it explicitly
RoonOS 3.0 is supposed to fix this by having an explicit Samba user named guest with PW guest, which is supposed to be accepted by Windows as not-anonymous because there is an explicit Samba user with that name
This has not really been working since the first OS 3.0 in EA because it is still possible to log in without any credentials (not being forced to use user guest with PW guest) from machines that allow anonymous access.
@Roland_von_Unruh thinks that this is to be expected based on his reading of Roon‘s SMB help page. I.e., he thinks that Windows is expected to interpret a user guest with PW guest as anonymous access and hence will continue to disallow it. (I’m not sure if this is true and I doubt it). On this basis, he thinks that Roon chose guest/guest in 3.0 although they should have known that it wouldn’t solve the problem
Thanks @Suedkiez - the guest/guest user/password has been present since RoonOS 1.0 - it’s not something that has been introduced with RoonOS 3.0 - that’s what I was trying to say…