File sharing with Windows 11

The latest update of Windows 11 (22H2) ruined the LanMan connection between my 4té2 and the Microsoft machine. I’ve re-enabled the SMB1 protocol on the latter, but that didn’t help. The weird thing is (weird to me at least), that when I call the computer by its name (in the ‘Server name’ field), the error says ‘Access denied’. But when I enter the IP-address instead, the error says ‘Session refused (NetBIOS name not present)’. This is true for either LanMan or for LanMan98. Does this ring bells?

Vaguely remember issues like this that were caused by things such as a firewall and in one case on a multi-homed windows box where the replies were arriving back on the wrong interface.

I used Reporter on the RISC OS side and Wireshark on the Windows side to trace my problem.

It’s not the firewall. Even if I switch that off, I get the same errors.

@ Paul

Have you checked if the update has disabled support from SMBv1? RO has no client for modern SMB.

Also, it’s very much unlikely that in the future it will be possible to connect RO directly to a Windows 11 (or more recent) systems. Microsoft has started to take security seriously recently.

However, it is possible to configure a Linux (or BSD) system as a server (also on a Raspberry Pi, if costs are an issue) and transform also your Windows system into a client.

Linux Samba Server is capable of talking to RISC OS the way both OmniClient and LanMan like and also talk to Windows 11 the way Microsoft wants it to be. just my 0.5c

Also having a raspberry Pi as a server could help reduce bills a bit, instead of the need to have a Windows machine running (if it’s an Intel Windows system).

If you really can’t put a Pi in the middle, then you can also run an FTP server on your Windows Systsem or try to implement NFS with one of the Open Source clients available.

Another way would be to use pCloud as a shared space between your Windows and your RISC OS (this is a paid solution, talk to Elasar for info). I have used it just to implement dynamic data interchange between multiple RISC OS systems (distributed between different places), and it worked really well.

Hope this helps

I do have the most current Windows 11 and in the windows features the SMBv1 client is enabled – it works.

As for the firewall you need to allow windows file sharing, or simply put your RISC OS machine into a rule allowing everything.

But AFAIK you have to use a host name – IP address might not work (so use a hosts file or a local DNS).

But if the windows PC has a DHCP IP address plus a static one (yes, that is possible) you have a problem since LanManFS/98 can’t cope with that.

Another way to sort all that is to use a decent NAS.

But if the windows PC has a DHCP IP address plus a static one (yes, that is possible) you have a problem since LanManFS/98 can’t cope with that.

Now, would that be static IP on wired Ethernet and DHCP on WiFi?

Hmmm, that could explain the problems I’ve been having with Windows, if so.

My “workaround” was to just run a web server on each machine and point it to a directory to list and share the contents of. Not quite as integrated as a filesystem share, but it worked.

For the mobiles, tablets, etc (plus the PC), I usually just toss files around using Bluetooth. Not terribly quick but it’s supported by everything except RISC OS and the ancient iPad.

For the mobiles, tablets, etc (plus the PC), I usually just toss files around using Bluetooth. Not terribly quick but it’s supported by everything except RISC OS and the ancient iPad.

I use webmail. It is supported on everything whch I have.

But if the windows PC has a DHCP IP address plus a static one (yes, that is possible) you have a problem since LanManFS/98 can’t cope with that.
Now, would that be static IP on wired Ethernet and DHCP on WiFi?

Exactly the configuration I have here. It works with Windows 10, and I’ve just rejected an attempt by Windows Update to install Windows 11, though not for this reason. Now I’m glad I did so. (If it ain’t broke, don’t fix it.)

Have you checked if the update has disabled support from SMBv1? RO has no client for modern SMB.

@Paolo. The latest update still supports SMBv1, which was even ticked already. Apparently those updates remember the previous settings. So, SMBv1 is enabled. Windows11 still connects to my ancient NAS, which is SMBv1 only. But for some reason it refuses my 4té2.

I do have the most current Windows 11 and in the windows features the SMBv1 client is enabled – it works.

@Herbert. Did it work out of the box, or did you have to change some settings?

As for the firewall you need to allow windows file sharing, or simply put your RISC OS machine into a rule allowing everything.

File sharing is enabled for the entire drive. Everyone is owner and has full rights. It has always worked that way.

But AFAIK you have to use a host name – IP address might not work (so use a hosts file or a local DNS).

IP address doesn’t work indeed, but neither does the host name, while that always used to work.

But if the windows PC has a DHCP IP address plus a static one (yes, that is possible) you have a problem since LanManFS/98 can’t cope with that.

The PC has a DHCP address only.

The 4té2 still connects to both my NAS’es (connection to the new one is even extremely fast!), so I’m not completely isolated. But as long as file sharing with Windows should work, I’m very curious why it doesn’t so here…

I use webmail.

Means sending stuff offsite. That might be…undesirable.

@ Paul

You can double check if the Server side is also active by running W11 PowerSHell as Administrator and then type:

Set-SmbServerConfiguration -EnableSMB2Protocol $true

There should be one for SMB1 too, I don’t have a W11 system handy to double check this at the moment, sorry.

Set-SmbServerConfiguration -EnableSMB2Protocol $true

I changed SMB2 to SMB1, but no success. But that was to be expected, since W11 was certainly using SMBv1 already, otherwise it could not have talked to my ancient NAS.

But that was to be expected, since W11 was certainly using SMBv1 already, otherwise it could not have talked to my ancient NAS.

but that’s using the SMB1 client in Windows. Lanman uses the SMB1 server in Windows, which might not be running.

I changed SMB2 to SMB1, but no success. But that was to be expected, since W11 was certainly using SMBv1 already, otherwise it could not have talked to my ancient NAS.

Not sure what you mean by “was to be expected” since that command sets a state, so the error you’ve got is simply because it doesn’t have the specific parameter you’ve tried, nothing to do with previous configurations.

Also the fact that it can access your NAS isn’t particoularly relevant to the problem you are experiencing, because when it access your NAS it’s acting as a client, while when you try to access your W11 from RO it’s acting as a Server. The protocol is the same, but the setting can be different.

For instance the update may have rised the securite on the password transmission, which does not apply when you use your W11 as a client. Am I making sense?

Another test you could try is from your NAS (if it has a CLI and an you can install an smbclient) is to debug what is goin gon with your W11 when a clien ttries to connect.

Another test is disable SMBv1, reboot and then re-enable it again to ensure it gets fully re-enabled.

And finally here there is some info that may be useful to debug your issue: https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/access-denied-access-smb-file-share

Hope this helps

but that’s using the SMB1 client in Windows. Lanman uses the SMB1 server in Windows, which might not be running.

Both Alan and Paolo raised the client/server issue, something that I hadn’t thought about. However, as far as I remember Windows never offered the possibility to set the SMB server and client seperately. It just offers the the possibility to enable or disable the SMB protocol, which – I think – includes both server and client. Anyhow, since Herberts setup still works with the latest Windows update, the SMB server must still be there, I’d say. On the other hand, I’m so ignorant about Windows in general and networking in particular that I may as well have lost my way and talk pure nonsense now.

Another test is disable SMBv1, reboot and then re-enable it again to ensure it gets fully re-enabled.

I’ve done that, several times even, but to no avail.
I also paddled through the debug pages that Paolo pointed at, and blinly followed the instructions, but again: to no avail.
It’s not a disaster, I can still communicate with both my NAS’es as intermediair – and even control the Windows PC through Avalanche, but I’m annoyingly puzzled by the question why LanMan gives an Access Denied error, while it actually should work.

File sharing is enabled for the entire drive. Everyone is owner and has full rights. It has always worked that way.

I suspect this is your issue. Windows 10 and I believe Windows 11 normally enforce additional security to stop you sharing the entire drive for very good security reasons as it’s dangerous especially with the insecure SMBv1. I encountered this when I moved from Windows 7 to 10. I now have specific shares for certain areas usually within the users structure. So you might need to create more specfic shares. I know someone published a longtime ago now a workaround to still allow all of drive being shared in Windows 10.

Also, it?s very much unlikely that in the future it will be possible to connect RO directly to a Windows 11 (or more recent) systems.

Paolo, for reference both ROOL and ROD have been looking into the SMB issue, ROOL have a bounty for LanManFs to be updated to work with SMBv2 and SMBv3. While ROD has looked at getting devlopment done on LanMan98 to support the newer protocols (LanMan98 is I believe now supplied with source code to allow anyone to develop it.

So you might need to create more specfic shares.

I’ve tried that, but again: no success. The same error boxes pop up.

BUT…
I found a way to get access after all, by disabling the password protection for file sharing. Is it possible that Windows has reset that password with the latest update? Actually, I can’t imagine, but there are a lot of things that I can’t imagine that nevertheless just happen, especially with Windows.

Is it possible that Windows has reset that password with the latest update? Actually, I can’t imagine, but there are a lot of things that I can’t imagine that nevertheless just happen, especially with Windows.

I have mentioned this on an earlier message, it is likely that W11 is NO longer accepting unencrypted passwords, which is why you get access denied. So, the password is the same, but RO is trying to send it in a format that is not accepted anymore.

Best to do at this point is to debug with smbclient on a Linux system and look at the connection logs to see what has been agreed between the two.

I have mentioned this on an earlier message, it is likely that W11 is NO longer accepting unencrypted passwords, which is why you get access denied. So, the password is the same, but RO is trying to send it in a format that is not accepted anymore.

That does make sense, and only now I’m beginning to understand it. It certainly explains why connection is still possible when I switch off password protection.

Best to do at this point is to debug with smbclient on a Linux system and look at the connection logs to see what has been agreed between the two.

I’m afraid that that is way beyond my capabilities, that are very limited to begin with. But I’m grateful for all the suggestions above that were able to remove a pinch from my ignorance.