[Investigating] RoonOS 3.0 (272) anonymous SMB access still possible

Just installed RoonOS 3.0 (272) EA to try out the new SMB security features.

Aparrantly, anonymous access still works. I can log in (Client OS: MacOS 26.4.1):

  • as guest (anonymously, without user/pw)
  • as registered user “guest” without password
  • as registered user “guest” with a random password
  • as registered user “guest” with password “guest”

According to the release notes, only the last option should be possible.

smbutil statshares -a via terminal gives the follwoing results:

                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.1.1
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_CURR_SIGN_ALGORITHM       AES_128_GMAC
 

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 just installed the new Early Access build 274 and can confirm that the issue pointed out above still is present.

This was to be expected because the release notes don’t mention this bug having been fixed yet.

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.

It does say “Connected as: Guest”, though:

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?

No surprise at all - Microsoft changed the security requirements for SMB access some time ago. See:

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.

It’s early access and not final code - that’s the whole point of EA. We get to kick the tyres and suck our teeth over it.

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…

Then beware of installing the latest EA build of RoonOS 3.0. Write access via iOS is not possible at the moment.

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”.

The choice was made by Roon Labs years before Microsoft decided to disallow it. And it is currently baked in - we can’t change it for ourselves.

As I said earlier, RoonOS 3.0 is a work in progress - we’ll just have to wait and see what Roon Labs do with this.

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.

I’m talking about RoonOS - not RoonOS 3.0.

RoonOS is used by the Nucleus (and later by ROCK). The Nucleus was introduced in 2018.

You’re aware that this is the early access section of the forum and the thread title explicitly deals with Roon OS 3.0? :slight_smile:

Sigh - yes I am. This conversation is going nowhere.

You two guys are talking past each other

Chronologically:

  1. RoonOS v1 and v2 chose anonymous access before Microsoft made it a problem (what Geoff meant)
  2. Microsoft made it a problem and forced users to allow it explicitly
  3. 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…