Does anybody else considers this extremely obsolete usage of SMB 1.0 in order to install codec on ROCK?
The point of ROCK is to have it as an appliance. So that I don’t have to open up command lines and run some obscure commands. And DEFINITELY not lower my security level on my machines.
If I want to open up command lines I can install Roon on dockers. Or on VMs. Or, god forbid, on a proper Linux/Windows/Mac machine.
There is no need for SMB 1.0 on ROCK. The only need there is is to allow anonymous/guest share access (if needed).
I need to install codecs on ROCK. To do that I need to enable SMB1.0 on my Windows machine.
Well, Q.E.D.
Just as a note to the OP:
I have Rock on Nuc, I do not have SMB 1.0 enabled on my Windows 10 machine and I have no issues accessing the OS drive over the network I have even mapped to drive for easy access.
I do have SMB Direct enabled (SMB 3.x support) whether that makes difference or not I do not know. But maybe that would help you?
I am not an “expert” in SMB protocol so… YMMV and all that.
No you don’t, Roon OS has supported SMB 2 for years. What you need to do is re-enable anonymous guest access on the Windows client because Microsoft recently disabled this by default
Nobody considers this problematic because ROCK supports SMB 2.0.
No you don’t. Nor does that linked article even remotely suggests doing that. It talks about SMB signing. That’s something else entirely.
You have interesting concept of “proof”. This is what smbclient tells me about the Data share on Nucleus+ (and therefore ROCK will be identical):
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
Data
SERVER_NAME nucleusplus
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_2.002
SMB_ENCRYPT_ALGORITHMS AES_128_CCM_ENABLED
SMB_ENCRYPT_ALGORITHMS AES_128_GCM_ENABLED
SMB_ENCRYPT_ALGORITHMS AES_256_CCM_ENABLED
SMB_ENCRYPT_ALGORITHMS AES_256_GCM_ENABLED
SMB_CURR_ENCRYPT_ALGORITHM OFF
SMB_SIGN_ALGORITHMS AES_128_CMAC_ENABLED
SMB_SIGN_ALGORITHMS AES_128_GMAC_ENABLED
SMB_CURR_SIGN_ALGORITHM AES_128_CMAC
COMPRESSION_IO_THRESHOLD 4096
COMPRESSION_CHUNK_LEN 262144
COMPRESSION_MAX_FAIL_CNT 5
WRITE_COMPRESSION_CNT 0
WRITE_CNT_LZ77Huff 0
WRITE_CNT_LZ77 0
WRITE_CNT_LZNT1 0
WRITE_CNT_FWD_PATTERN 0
WRITE_CNT_BWD_PATTERN 0
READ_COMPRESSION_CNT 0
READ_CNT_LZ77Huff 0
READ_CNT_LZ77 0
READ_CNT_LZNT1 0
READ_CNT_FWD_PATTERN 0
READ_CNT_BWD_PATTERN 0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
FILE_IDS_SUPPORTED TRUE
DFS_SUPPORTED TRUE
SESSION_RECONNECT_TIME 0:0
SESSION_RECONNECT_COUNT 0
--------------------------------------------------------------------------------------------------
If you read the above, you’ll come to the conclusion that the negotiated version is SMB 2.
I’ve had to add a registery key on my Windows 11 Pro NUC to be able to access \rock from Windows Explorer.
Even as sole user and admin I apparently didn’t have rights to make the kind of connection required to access my ROCK NUC.
But now I can access Rock and drag and drop my music or codecs with Windows Explorer.
It took me longer to fix this than to install Rock from scratch.
SMB is notoriously insecure. The Windows folks have recently changed the defaults to make it more secure - that’s what you were running into.
I eventually gave up.
I couldn’t connect to the data directory through windows, even though I disabled the authentication flag.
I deployed Ubuntu just to try connecting to the share, succeeded, deleted the ROCK VM and installed a Windows VM for Roon Server.
Works flawlessly. Search feels a quicker.
It even solved an annoyance I had where Roon connected using SMB 2.0 to my NAS and didn’t watch the folders for changes.
SMB isn’t really insecure in LANs.
Disallowing the option to connect to anonymous shares makes sense in work environments but not really in home networks.
The new configuration takes away the owner’s choice to connect anonymously to a share on their LAN. And as the owner is typically the admin on the client, they can change this, anyway, as documented. Making them mess around in the registry doesn’t do anything for security.
There has been a discussion on security concerns relating SMB and guest access to ROCK quite a while ago.
The feature request to add user/password authentication to access ROCK as an option has been raised more than once in the past as well and never been addressed by roon.
I can understand though, why room doesn’t add user/password authentication for either web access or smb access to ROCK system. I assume, they are afraid of the support section of the forum to be flooded with “Can’t access ROCK, forgot password, how do I reset it?”-like requests 
Making it harder for unsers to delete everything from a Roon OS server would be good.
However, my reply here was about the claim that Microsoft preventing anonymous access from the Windows client by default improves security. It doesn’t really, in home LANs.
They said they are working on it. As I noted in the past, adding a user account to Roon OS is probably quite a big change to the security model.
And as you noted, there must be an easy way to reset the PW. However, to satisfy Windows, it would be enough to use roon/roon instead of guest/guest.
I totally understand all sides of the story.
The only times you need to access the data folder is to install codecs or to replace the binaries to early access/move back.
I’m sure there are easier ways to do that that don’t require access through insecure SMB.
are ideas. I’m sure there are better UI/UX designers out there that can solve this issue.
It’s the same with Nucleus, which is a high-priority project.
Users need to be able to upload and organize music in the music storage.
Haven’t thought of ROCK as a NAS.
But that’s another set of problems.
It’s not “as a NAS”. The ability to store music on the secondary internal disk or attached USB disks, to be used by Roon itself, is an inherent value proposition of Nucleus and ROCK.
ROCK ( and Nucleus) devices are most definitely not a NAS but, when fitted with internal storage for music, they require the use of the SMB share to manage that music.
Using a USB attached disk, whilst the use of the SMB share is still an option, the user has another option - moving the disk to a computer (Linux, MacOS, Windows) and using the facilities of that computer to manage the music storage before reconnecting the disk to the ROCK/Nucleus device.
Edit: Sorry. Didn’t see the post by @Suedkiez which said the same thing.
In these usecases ROCK and Nucleus are:
Hence: Network Attached Storage.
But Roon OS doesn’t access the storage over the network but it‘s local to the Nucleus/ROCK.
Exporting a simple SMB share doesn’t turn a device into a NAS.