Network access to Win10

When I still had a Windows PC, I always used NFS to connect it to the RISC OS machines. That’s quite a while ago, but searching the web for ‘nfs server for windows10’ gives plenty of hits, so it should be doable.

To Dave (I forgot how to quote)

Microsoft implement NFS, just not everywhere they should. Windows 10 is nothing more that a glorified mobile OS, hence my relectance to move from Windows 7. All of that is another story though.

Windows 10 comes with an NFS client but Moonfish (here) will not work with it. Whether that’s the fault of the client or Moonfish I know not. On Windows 10, ‘showmount’ identifies the the export on my RISC OS system but will not mount it.

I also have an NFS server that runs on Windows 10 but Sunfish just crashes when attempting to use it (browse) so I can’t use that. Maybe that’s a 26/32 bit issue, will have to check that.

Will look at scp but NFS or SMB are prefered.

When I still had a Windows PC, I always used NFS to connect it to the RISC OS machines. That’s quite a while ago, but searching the web for ‘nfs server for windows10’ gives plenty of hits, so it should be doable.

Probably Windows 7 then :)

As mentioned in my previous post, I have the NFS capability, client and server, on the Win 10 box, it just won’t play the game. It maybe the same ‘domain joined’ issue, as with LanMan98/Omniclient.

on the Win 10 box, it just won’t play the game.

At the risk of writing mis-remembered rubbish… I seem to remember two versions of NFS, i.e. NFS and PCNFS The former authenticated using UID/GUI pairs, while the latter uses PC username password/pairs. I wonder which Windows10 is implementing. I don’t think there’s a way for RISC OS to connect using UID/GID.

I don’t think there’s a way for RISC OS to connect using UID/GID.

The Moonfish config for an exported directory provides the ability to specify the UID/GID, which I have done, and I have also added the same UID/GID to the Windows 10 registry, so that shouldn’t be the issue.

I say shouldn’t but I suspect it will be some kind of authentication/authorisation/identification issue.

Hi Mike,

There was some discussion on a similar issue with Windows 10 and Samba and Colin kindly made available a modified LanMan module to provide a reporter log of issues to help resolve them.

You could try that to help resolve why your one Windows machine will not connect via Samba.

Colin kindly made available a modified LanMan module to provide a reporter log of issues to help resolve them.

Tried those for the domain joined windows machine. No joy. I suspect the issue is simply the fact that it is domain joined.

Tried Moonfish from the WORKGROUP only machine and no joy with that, so at least it’s not the domain join stopping that from working.

Tried those for the domain joined windows machine. No joy.

Did it give any information in the Reporter window?

Tried Moonfish from the WORKGROUP only machine

Tried that from my Win 10 machine using the built NFS client as well to Moonfish and no success.

Did it give any information in the Reporter window?

It did give info. Initially, double clicking the debug module reported ‘No netbios scope ID set’, then when that cleared the reporter window had various text lines. I’ll have to re-run it later to be precise. One line that may be significant was something like ‘hostname not known to us’ where hostname was the real hostname, or something like. Omniclient and LanMan98 both work with the non domain joined machine though.

Tried that from my Win 10 machine using the built NFS client as well to Moonfish and no success.

Not just me then :-)

One line that may be significant was something like ‘hostname not known to us’

That rings a bit of a bell. If I remember, the hostname in Lanman must be identical to the name the host itself thinks it is, and must map on RISC OS to the correct IP address. In other words, it’s not just being used to find the IP address, but also to somehow authenticate to the host. Might be worth checking the case of the name at each end.

I could be wrong though.

Also if it is login in to a domain is it also setting up things and/or altering and locking down access/services etc.

The thing is, the config on the RISC OS side is constant. This config works with the same physical PC, but when booted into Windows 7, that is domain joined.

I’m no expert but I might try a bit of ‘wiresharking’ to see if anything obvious reveals itself.

why not just use an FTP server for access only on the local network?

ftp would be an option, much like scp, but I would prefer the simplicity of drag and drop between locations. Afterall, this is 2021, it should be that easy :-)

The Lanman/Omniclient issue clearly is a Windows 10 domain / netbios issue. It works well with Windows 7.

Something has obviously changed. Most likely a security concern on the part of MS.

As LanMan98 is now open source, does anybody know the location of said source?

Ok, so using !FTPc on RISC OS, and wsFTP on Windows? That gives you drag and drop if the server is a third computer. If the FTP Server is the Windows computer, setup for a single directory tree then you have drag and drop within Windows Explorer, and !FTPc on RISC OS.

Just a suggestion, makes sense to me as it is the IP network File Transfer protocal.

All valid and no doubt workable. Just not as simple as it should be (on the Windows side).

Hi Mike,

As LanMan98 is now open source, does anybody know the location of said source?

I would suggest contacting RISCOS Developments

They own LANMAN98 and there is also a bounty to improve LanManFS

So, wireshark to the rescue. User error, i.e. mine.

I have unused but active interfaces on different networks, on this new Win 10 install and it was one of these on which the netbios broadcast was being answered.

Anyway, disabled those, all good now.

Thanks to all those who helped.

Hi Mike,

Excellent news and glad you have got it sorted and also given us another potential thing for others to check in future when they encounter difficulties.

They own LANMAN98 and there is also a bounty to improve LanManFS

Ok. I thought it was open source now. The bounty is interesting, I wonder if anybody is working on it. I don’t have the RISC OS knowledge personally but it might be something to study on.

I thought it was open source now.

The source is available, and can be obtained from PlingStore.

It’s not Open Source, because there’s absolutely no licence information in the download and so there’s no way to determine the legality of doing anything with the software. Hopefully, RISC OS Developments will resolve this at some stage, but for now it’s not that useful in terms of anyone working on it.

The source is available, and can be obtained from PlingStore.

I did get the application from PlingStore, which is where I saw the info about it being open source. There is no source code included in the download though (although the info page states that there is).

The source code was removed temporarily due to Steve’s queries on specific licence. I actually reached out to Steve to discuss which licence we should use around the start of the year, but apart from an acknowledgement (much appreciated), I haven’t received further correspondence (to be fair, I haven’t had time to think about it either).

In the absence of anything else, I’d like to propose we use the Mozilla Public Licence (MPL) 2.0. This lies in a mid-ground between the Apache and GPL/LGPL licences.

You can read more at https://www.mozilla.org/en-US/MPL/2.0/FAQ/

Put simply, MPL requires that any changes be kept open source (ie. so that we can get changes fed back into the main branch) but doesn’t poison anything else that the code touches (so it could be included in the OS without polluting the OS licence). It differs from Apache in that Apache allows the code to be taken and modified and distribued without feeding stuff back, closed source, whereas the MPL licenced files would need to be kept open source, which I think is important in LM98.

Unlike GPL/LGPL, only the MPL-licenced files are controlled by the licence, so MPL code can be staticly linked to non-MPL code.

On the surface, that seems like an OK licence to me, but my experience of open source licences is quite limited. Does anyone have any objection to this?

Just out of interest, have you looked at CDDL? It’s supposed to be a bugfixed version of the MPL licence and it is already in use within RISC OS.

Plus, CDDL is incompatible with GPL so code can’t be sneaked off that way; whereas the MPL specifically allows MPL code to be “relicensed” as GPL if necessary to satisfy the vital nature of GPL.

I actually reached out to Steve to discuss which licence we should use around the start of the year, but apart from an acknowledgement (much appreciated), I haven’t received further correspondence (to be fair, I haven’t had time to think about it either).

Replying was somewhere in the pile under stuff like fixing the boiler, finishing off the next issue of The WROCC¹, things for the theatre, getting moving on Zap, and a load of other stuff as well. Sorry.

I was actually going to suggest looking at the MPL 2.0 (having spotted that PipeDream uses it, and followed Stuart’s links to see what it was about), so it looks like you’re already on the same page anyway.

¹ That was this evening’s plan, until I spent this evening finding out why there’s a pool of water on the kitchen floor under the boiler.

I don’t want to get lost down the license rabbit hole so MPL sounds ok to me.