Installing ROCK fresh on a new NUC. Trying to drop the codec in the appropriate folder, Windows asks me for credentials. Of course I did a search on this and guest - guest does not work. Any suggestions are highly appreciated, as I am stuck now. Thanks!
What version of Windows? Based on the answer you might have to do one or both
- Try turning on SMBv1 access in Windows which is Done under Windows Features
AllowInsecureGuestAuthmight need to be activated. See Post “Trying to install codecs on new ROCK install but having network issues - #8 by Tim_Rhodes”
I’d start with 1 first, and if that doesn’t work try 2.
1 Like
(deleted, misread)
1 Like
I seem to remember that when I installed a new Windows machine some time ago I was able to connect with the username and password guest/guest and didn’t need to enable SMBV1 (which I had to do in the past).
Do you want to try that first
Option 2 did the trick, thank you. Annoying that I would have to do this every time I had to access it from Windows (11), but hey, probably that won’t be a lot.
Thanks!
Off to routing Arc to work again now.
1 Like
guest guest didn’t work unfortunately
1 Like
You’d enable AllowInsecureGuestAuth once in the Registry, not every time
Yeah, but I set it back to the original setting, as the op suggested for security reasons.
1 Like
Security questions always need to take into account the scenario. What can be necessary for the NSA offices doesn’t have to be at home. Do you have untrusted actors on your Windows machine who would take advantage of the guest/guest access to steal or delete data? Probably not. (And if you do, you probably have bigger problems).
It’s of course a problem in an Office setting if everyone has access to everything by guest/guest, and that’s what Microsoft is mainly trying to discourage
Aha, but I am just a noob following online advice on security. Will set it back, thanks!
That said, it would be nice if Roon OS file access could be more secured in principle by adding an account with a password and disallowing guest/guest. If only to prevent mishaps in a larger family or nosy children, etc.
But this would be the SMB server side managing access and only allowing file access to people who have the password.
In the case of your Windows client, all that the default of AllowInsecureGuestAuth being set to OFF does is preventing users on this one Windows machine from connecting to any servers that only offer guest/guest. However, as long as Roon OS only offers guest/guest, anyone with a different computer on your LAN can access the ROCK anyway. So disabling this just on your Windows has very little effect in a home setting.
I think implementing 1 also enables 2 anyway which is why it works. Nothing to do with smb1 really.
So my advice would be to use 2. It’s then just one security change rather than two.
For what it is worth I avoid having to do either on my windows devices by mounting the ROCK share via my nas and exposing that to windows instead.
I got ARC working again, through my network routing rules.
Connecting to my nas music folder is a pain though, somehow I can’t get Roon to connect to the network share.
Had it up and running immediately through the nas name, no credentials, just a smb share. Then I rebooted and it forgot the share, couldn’t connect anymore. Now I am connecting straight to the ip address with a newly made user account on the nas shared folder and it seems to working again. Strange.
@RexManning, I would still recommend resetting it to zero. How many times do you copy codecs anyway?
@Suedkiez, you’re raising valid questions, but you don’t want to find the answers the hard way.
Yeah, but every case must be evaluated by its necessities. As they say, the most secure computer is encased in concrete at the bottom of the ocean. We find the balance between what we really need and what we can bear.
In the Roon OS case, I’m all for a facility allowing tighter access rules for the Samba/SMB server. However, as long as Roon OS exposes itself to everyone on the LAN by guest/guest, disallowing the access only from one particular Windows client gains little in most scenarios.
Another one: do I backup to my NAS (which I just set it up to do), or is it best practise to backup to a usb drive attached to the nuc?
Since copying codecs to ROCK is a once-in-a-blue-moon operation, I don’t see anything unbearable to reset it.
It’s not about ROCK, it’s about the particular Windows client. If you allow guest SMB connections on it, in theory, you allow it to connect as guest and send unencrypted data to any server, not only to ROCK. Yes, outbound SMB should only be enabled for private connections in the firewall and chances are your ISP is blocking port 445 anyway, but then again, why would you even want to worry about all these? It’s just defense in depth.
Defense in depth (computing) - Wikipedia
1 Like
Either is fine. You could also do both. Redundancy of backups is always good
1 Like
Thank you!
And then that’s fine, reset it. But I responded to someone finding it annoying
And there’s potentially more to access on a ROCK like an external USB disk
The part where anyone on the LAN can freely access the ROCK is about ROCK. This can be a problem or not, depending. And disallowing it on the one Windows does not solve this part, is my point
True. And entirely irrelevant if one doesn’t have other servers on the LAN that allow guest/guest where this would be a problem, and if one can trust that other LAN users don’t try this on the internet.
If one does need to restrict guest/guest on clients, then one should do so on all clients, not just the one. Which, again, is a matter of the specific installation.
Just saying that creating an annoying restriction on one machine may not be worth it if other, related, possibilities are not closed as well