RISC OS / Linux file transfer

I’m trying to share files from Linux to RISC OS. I’ve set up an nfs server on Linux, which I can mount fine from Linux. I can also set up an nfs server (Moonfish) on RISC OS, and access that from RISCOS (OmniClient NFS).

But I can’t use NFS to get to Linux from RISC OS :-( :-(

It goes

*Mount -host 192.168.0.1 Test /Test
RPC communication failed on mount (RPC Service not available on remote host (not registered)).

I’ve not used Sunfish because that just crashes.

Actually I can’t access Moonfish from OmniClient. I can see the files in NFS::Test.$, but if I open them I get

Hardware I/O error

I’ve not used Sunfish because that just crashes.

It is only the frontend that crashes, connections can be established, just don’t subsequently touch the frontend.

*Mount -host 192.168.0.1 Test /Test

Nearly, NFS needs to be set as the filing system.

On the Titanium this line found a MoonFish mount on the Raspberry Pi.

*NFS:Mount -host 192.168.1.208 RPi3 /Pi3_Work

HTH

Sunfish on my Raspberry Pi crashes if I use ‘Search for Host’, so I can’t even make a connection.

I’ve tried connecting from RPCEmu on the Linux computer, and from the Raspberry Pi, and Ominclient says the same thing about RPC both times as above.

Sunfish on my Raspberry Pi crashes if I use ‘Search for Host’, so I can’t even make a connection.

The version I have, from here, does at least get that far. It shows its version as 2.05 (08 Jun 2013).

’m trying to share files from Linux to RISC OS

Have you thought to use FTP? It is reliable, relatively easy to set and likely much faster than sunfish/moonfish and works both ways with FTPc

Most Linux systems have a native FTP Server – I have used VSFTPD successfully.

I use samba on linux and LanManFS.

Have you thought to use FTP? It is reliable, relatively easy to set and likely much faster than sunfish/moonfish and works both ways with FTPc

Does it work as a proper filing system?

Is there a guide to setting up and using OmniClient with LanMan and/or NFS? I do a lot of networking on the Windows and Linux side for over 30 years, but I’ve never really got to grips with OmniClient/LanMan and have stuck with Sunfish as it does what I want very well, at least connecting to NAS and Linux boxes. If LanMan is limited to SMB1 then it won’t be a good fit on my network anyway.

Thanks John, FTPc gets through and I can copy stuff over :-)

I did have Samba working from RPi on another installation of Linux once in the distant past, but I must not be setting the server configuration up right this time, and the same with NFS. It is just so frustrating that the server or client will neither tell me what went wrong.

I was about to give up and use USB sticks instead.

I did have Samba working from RPi on another installation of Linux once in the distant past, but I must not be setting the server configuration up right this time,

SMB1, the best that RISC OS can manage, may be deprecated in Linux distros such as Ubuntu. It can be renabled for local use.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#SERVERMINPROTOCOL
https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#SERVERMAXPROTOCOL

Open /etc/samba/smb.conf then add to the [global] section :-

[global]
server min protocol = LANMAN1

then restart samba :-

sudo systemctl restart smbd.service

Works here on Ubuntu 20.04 and 18.04.4

Bingo! Putting that LANMAN1 line in made it pop up right away on Omniclient :=D

I’m using Sunfish now I’ve moved my NAS disc from the router (SMB only) to a Pi4B. Sunfish was a pain to set up, it discovered and mounted ok, but crashed when changing any settings. Luckily it crashed after changing the setting and saving it, so it was possible to complete the process. Now it runs on boot and auto mounts the NAS disc with no problems. This is using the ARMv7 build font end on RO 5.27rc16.

5.27 does seem to be exposing a lot of issues with Wimp programs, which weren’t seen or as bad on 5.24.

Hooray! I’ve finally got through to NFS on Linux.

My /etc/nfs.conf had a line

[nfsd]
...
# udp=n
...

I changed it to

udp=y

then did

sudo systemctl restart nfs-server

and everything suddenly worked :-D

Interesting – sounds like something on your network maybe blocked TCP transfers, but not UDP transfers (ports are the same for TCP and UDP IIRC).

With NFS, UDP is likely to be faster anyway, so unless you have a local network that has many errors and retransmits (i.e. highly-loaded congested Ethernet), UDP should be better.

Thanks to this thread I have managed, at last, to transfer files between my RISC OS and Linux raspberry pi machines. I installed vsftpd for Raspbian and already had FTPc for RISC OS. For ages I was satisfied with moving stuff across on a memory stick, rather dreading the setting up of the requisite software; but my fears were unfounded.

Interesting – sounds like something on your network maybe blocked TCP transfers, but not UDP transfers (ports are the same for TCP and UDP IIRC).

The first port of call for failed communication using a specific IP port between machines on a network where other traffic passes should always be the firewall implementation on the individual machines involved.

Sorry to resurrect such an old thread, but it’s bang on topic.

I recently set up a new installation of OpenMediaVault 7 on Raspberry Pi OS 64 bit. Having got SMB working satisfactorily, I turned my attention to NFS, only to find that it works with Sunfish but not with Omniclient. So I did some captures with Wiresalmon and examined them using Wireshark.

Sunfish uses TCP, and, since it Just Works™, there’s not a lot more to say.

Omni uses UDP. I can’t see any way to configure it differently, and, since later versions of NFS seem to have moved to use only UDP, that would appear to have been a good decision. But the negotiation looks to be faulty:

Omni does a Portmap GETPORT call, V3, UDP, MOUNT, and receives the reply “port 50758”.
Omni does a Portmap GETPORT call, V3, UDP, NFS, and receives the reply “port 2049”.

So far, so good.

Omni does a MOUNT call via UDP from port 957 to port 50758 with V3 procedure NULL, and receives a NULL response via UDP from port 50758 to port 957.
Omni does an NFS call via UDP from port 959 to port 2049 with V3 procedure NULL, and receives a NULL response via UDP from port 2049 to port 959.

What on earth is that about?

Then, apparently having failed to negotiate NFSv3, it seems AFAICS to try to negotiate NFSv2, and fails. More details later, perhaps.

It seems clear to me that this is NOT a firewall issue, nor NFS being restricted to TCP, as all the requests receive what appear to be proper responses.

I’ve tried this with OmniNFS versions 0.74 and 0.73.

Does anyone have any insight as to what’s going wrong, and/or what I might try next?

(I did edit the /etc/nfs.conf file as shown above, and NFS does appear to be running on UDP according to the captures.)