In article <22fff0c059.chris@mytarbis.plus.com>,
Chris Hughes <news13@noonehere.co.uk> wrote:
> I agree, any idea where Omni stores its mount files?

Have you tried looking in Choices: 8)

--
Chris Johnson

In message <59c0ce9082chrisjohnson@spamcop.net>
News <chrisjohnson@spamcop.net> wrote:

> In article <59c0c888c9news@triffid.co.uk>,
> Dave <news@triffid.co.uk> wrote:
> > ** WimpError ** from OmniClient Error : &00012112 Message: RPC
> > communication failed on mount (RPC Service not available on remote host
> > (not registered))
>
> > No idea what that means either.
>
> One assumes an NFS server is not running on the remote machine.

It's most definitely running on my NAS too, as witnessed by Sunfish's
ability to access its drives.

I think the error message is misleading. It says the RPC Service is
not available, which would lead one to think that RPC as a whole is
not working (and inevitably make one suspect no NFS server at all).
But I suspect it means that the particular service that has been
requested via RPC is not available, and I think it's pcnfsd. Then
the next question is why Omni wants to use something that Sunfish
clearly doesn't need to.

I've got too many projects on at the mo, and they're not going all
that well, so I really can't afford to get wound into this one too.
I have a suggestion, though: anyone who might be competent, get
Wiresalmon (run it with alignment exceptions off if you are using a
recent platform - it will be more stable), capture some attempts to
connect, and look at the resulting pcap file in Wireshark. Luckily
the NFS payloads are not encrypted.

David

David Higton <dave@davehigton.me.uk> wrote:
> It's most definitely running on my NAS too, as witnessed by Sunfish's
> ability to access its drives.
>
> I think the error message is misleading. It says the RPC Service is
> not available, which would lead one to think that RPC as a whole is
> not working (and inevitably make one suspect no NFS server at all).
> But I suspect it means that the particular service that has been
> requested via RPC is not available, and I think it's pcnfsd. Then
> the next question is why Omni wants to use something that Sunfish
> clearly doesn't need to.

PCNFS is a separate service to authenticate username/password, which is not
part of the bare NFS protocol. It's old (1980s) and modern NFS servers
don't use it. I don't know if it's something Omni requires but Sunfish
doesn't care about - Sunfish postdates the era where pcnfs was in use.

ISTR pcnfsd being removed from Debian something like 20 years ago, for
example.

I'm not familiar with Omni, but perhaps if you remove any mention of
username and password it won't try and use pcnfs?

Theo

In message <mLf*kV4Hy@news.chiark.greenend.org.uk>
Theo <theom+news@chiark.greenend.org.uk> wrote:

> David Higton <dave@davehigton.me.uk> wrote:
> > It's most definitely running on my NAS too, as witnessed by Sunfish's
> > ability to access its drives.
> >
> > I think the error message is misleading. It says the RPC Service is not
> > available, which would lead one to think that RPC as a whole is not
> > working (and inevitably make one suspect no NFS server at all). But I
> > suspect it means that the particular service that has been requested via
> > RPC is not available, and I think it's pcnfsd. Then the next question is
> > why Omni wants to use something that Sunfish clearly doesn't need to.
>
> PCNFS is a separate service to authenticate username/password, which is not
> part of the bare NFS protocol. It's old (1980s) and modern NFS servers
> don't use it. I don't know if it's something Omni requires but Sunfish
> doesn't care about - Sunfish postdates the era where pcnfs was in use.
>
> ISTR pcnfsd being removed from Debian something like 20 years ago, for
> example.
>
> I'm not familiar with Omni, but perhaps if you remove any mention of
> username and password it won't try and use pcnfs?

Isn't that a paraphrasing of what I said? The problem being that you
then get read-only access.

David

On 26/02/2022 23:21, David Higton wrote:
> It's most definitely running on my NAS too, as witnessed by Sunfish's
> ability to access its drives.

The issue is probably a weird NFS setup on your NAS, which it may or ay
not be easy to solve. An alternative would be to use a Linux Raspberry
Pi as a file server for your RISC OS machine, as SunFish works perfectly
with the Rasbian's NFSd. You don't even need move the storage on to the
Pi, just mount the NAS shares on the Pi, and reshare using NFSd to RISC OS.

---druck

David Higton <dave@davehigton.me.uk> wrote:
> In message <mLf*kV4Hy@news.chiark.greenend.org.uk>
> Theo <theom+news@chiark.greenend.org.uk> wrote:
>
> > David Higton <dave@davehigton.me.uk> wrote:
> > > It's most definitely running on my NAS too, as witnessed by Sunfish's
> > > ability to access its drives.
> > >
> > > I think the error message is misleading. It says the RPC Service is not
> > > available, which would lead one to think that RPC as a whole is not
> > > working (and inevitably make one suspect no NFS server at all). But I
> > > suspect it means that the particular service that has been requested via
> > > RPC is not available, and I think it's pcnfsd. Then the next question is
> > > why Omni wants to use something that Sunfish clearly doesn't need to.
> >
> > PCNFS is a separate service to authenticate username/password, which is not
> > part of the bare NFS protocol. It's old (1980s) and modern NFS servers
> > don't use it. I don't know if it's something Omni requires but Sunfish
> > doesn't care about - Sunfish postdates the era where pcnfs was in use.
> >
> > ISTR pcnfsd being removed from Debian something like 20 years ago, for
> > example.
> >
> > I'm not familiar with Omni, but perhaps if you remove any mention of
> > username and password it won't try and use pcnfs?
>
> Isn't that a paraphrasing of what I said? The problem being that you
> then get read-only access.

Not really. I'm saying PCNFS is the old way to do authentication, which
mostly isn't used any more. There isn't a username/password authentication
that replaces it. NFS is not a user-oriented protocol like SMB, it's
originally designed for machines sharing discs.

Your options are to mount your NFS server with 'sec=sys', which
basically means the server looks at your IP and the user-id/group-id pair
that the client supplies, and uses that to determine what you're allowed.
In effect the client can self-declare its UID/GID and get rights to things.
That only makes sense on a multi-user system where a privileged client
enforces what UID/GID a user presents as - otherwise the client can pretend
to be any UID/GID they want.

Or a newer choice is 'sec=krb5' which uses Kerberos to authenticate users,
but for that you need a Kerberos domain controller etc - I very much doubt
anything on RISC OS supports that, even if you had that server running.

So in practice, using the default sec=sys mode, if you want to have
read/write access you have to allow everyone coming from your RISC OS
machine's IP (or your network, if you want to be less specific) read/write
access, in /etc/exports or your NAS' equivalent config.

As far as UID/GID goes, the simplest is to match the user id / group id of
your own user[1] on the server. That way you will present as 'you' and get
read/write rights to the things 'you' own. It is also possible to present
as root (UID=0/GID=0, ie give me read/write access to everything) but the
root_squash flag is often set at the server end to prevent this.

Theo

[1] If you have a terminal on your NAS that runs Linux, use the 'id' command
which will print the numeric UID/GID values, followed by the list of groups
your user belongs to (irrelevant here):

atm26@nautilus:~$ id
uid=1001(atm26) gid=1001(atm26) groups=1001(atm26),4(adm),20(dialout),24(cdrom),
....

In message <svm2oq$uk9$1@dont-email.me>
druck <news@druck.org.uk> wrote:

> On 26/02/2022 23:21, David Higton wrote:
> > It's most definitely running on my NAS too, as witnessed by Sunfish's
> > ability to access its drives.
>
> The issue is probably a weird NFS setup on your NAS, which it may or ay
> not be easy to solve. An alternative would be to use a Linux Raspberry Pi
> as a file server for your RISC OS machine, as SunFish works perfectly with
> the Rasbian's NFSd. You don't even need move the storage on to the Pi,
> just mount the NAS shares on the Pi, and reshare using NFSd to RISC OS.

The NAS is a Raspberry Pi running OpenMediaVault. Sunfish works with
it, no problem. It looks like the only strangeness is in Omni's NFS
implementation. Not a problem to me, as I didn't want to use it anyway
- I just tried it because someone mentioned it and I thought I'd try it,
having forgotten that Omni ever did NFS.

David

On Tuesday, March 1, 2022 at 2:35:23 PM UTC, Theo wrote:
> David Higton <da...@davehigton.me.uk> wrote:
> > It's most definitely running on my NAS too, as witnessed by Sunfish's
> > ability to access its drives.
>
> I'm not familiar with Omni, but perhaps if you remove any mention of
> username and password it won't try and use pcnfs?

The username/password authentication is only attempted if there's a server entered in the "Authenticator" field in Omni. See page 180 of the RISC OS 5.28 User Guide for details. Using
Server = 10.0.0.99 (its IP address)
Dir = /home/myname
Username = nobody (and a blank password)
OmniClient connects to a FreeBSD NFS mount just fine. Since I trust myself at both ends I then map the user "nobody" to have read/write permissions, otherwise that user ID is stuck being read-only,
Sprow.

On Thursday, 3 March 2022 at 22:18:26 UTC, Sprow wrote:
> On Tuesday, March 1, 2022 at 2:35:23 PM UTC, Theo wrote:
> > David Higton <da...@davehigton.me.uk> wrote:
> > > It's most definitely running on my NAS too, as witnessed by Sunfish's
> > > ability to access its drives.
> >
> > I'm not familiar with Omni, but perhaps if you remove any mention of
> > username and password it won't try and use pcnfs?
> The username/password authentication is only attempted if there's a server entered in the "Authenticator" field in Omni. See page 180 of the RISC OS 5.28 User Guide for details. Using
> Server = 10.0.0.99 (its IP address)
> Dir = /home/myname
> Username = nobody (and a blank password)
> OmniClient connects to a FreeBSD NFS mount just fine. Since I trust myself at both ends I then map the user "nobody" to have read/write permissions, otherwise that user ID is stuck being read-only,
> Sprow.

Just spent the morning getting this to work on my Synology NAS as I was getting "Insufficient access" errors, and so this might help anyone else trying to get it to work.
In Omni to connect, I had to specify the full path for the directory name, including the leading slash.
So in my case: /volume1/Backups
When setting the NFS Permissions the Synology shows you the full path.
And on the Synology I had to set the NFS Permissions to set Squash = Map all users to admin
I needed to do this even when the Privilege was set to Read Only.

The difference with Sunfish, as far as I can tell, is that Sunfish defaults to the UID (1001) whereas Omni uses the nobody UID (32767) because with Sunfish the Squash was set to No Mapping, and in my limited testing it just worked.
I did try the NFS:Logon command but that just errored, although I now realise that the Logon command is aliased to SafeLogon, so I might try removing the alias later on and seeing if that allows me to remove the mapping to admin.

But hopefully that might help anyone else getting Omni NFS to work.

Richard