RISC OS / Mac shared drive

@ John

My firewall GUI is limited. I can’t see any reference to port numbers or NFS

There won’t be. Depending on the version of your mac OS those ports may already be opened, if in doubt you can add them manually (via the GUI). For testing you can simply disable the firewall temporarly.

To your specific problem, if the firewall is disabled and you still get that error, can you check if you have the RPC service running please?

To do that, on your mac, type:

rpcinfo

It should show you all the info about your current RPC status.

It’s worth trying.

Another thing worth trying is, on OmniCLient, instead of using the mac FQDN, in the server name field, try to use the IP, sometimes home routers are not configured correctly to resolve local names, so using the system’s IP can help figuring out what is going on.

Another thing I am seeing in your configuration is, you have used a local user directory (Users/riscman/), it may be worth using /Users/Shared instead, there are extra protection when sharing directories for a local user and that may be also causing problems. I’d suggest that you can configure exactly what you want once you’ve established a working connection, just my 0.2c

Again, at the very minimal, you should get the directory in readonly mode, so something is going on on your setup…

HTH

I’m not a mac user, but it is common to have udp transport protocol disabled by default
in modern nfs servers. Try with this text file:

Protocol: NFS3
Server: <server ip, or hostname if it is already in Hosts file> 
Export: <path to exported dir>
Transport: tcp

Set the type of this file to “Sunfish” and click on it after executing or “seeing” !Sunfish.
You can also try enabling udp in your server configuration.

OmniClient’s NFS has issues managing the permissions of “nobody” user, I sent a bug report
some days ago:

https://www.riscosopen.org/tracker/tickets/622

And it uses udp by default also.

Note that these clients only support nfs2 or nfs3, make sure your server is not serving nfs4 only.

Note that these clients only support nfs2 or nfs3, make sure your server is not serving nfs4 only.

This was going to be my suggestion, too. ISTR errors like the ones John quotes above when I hit that issue a while back.

If you click ‘FS List’ on the OmniClient menu the nfs server should show up in the ‘Network servers’ window.

Yes! a bit of light at from further up the tunnel.
macmini is now showing in the list of Network servers

Note that these clients only support nfs2 or nfs3, make sure your server is not serving nfs4 only.

   100003       2     udp       0.0.0.0.8.1              nfs        root
   100003       3     udp       0.0.0.0.8.1              nfs        root
   100003       2     udp6      ::.8.1                   nfs        root
   100003       3     udp6      ::.8.1                   nfs        root
   100003       2     tcp       0.0.0.0.8.1              nfs        root
   100003       3     tcp       0.0.0.0.8.1              nfs        root
   100003       2     tcp6      ::.8.1                   nfs        root
   100003       3     tcp6      ::.8.1                   nfs        root
   100003       2     ticotsord /var/run/nfs.ticotsord   nfs        root
   100003       3     ticotsord /var/run/nfs.ticotsord   nfs        root

It looks as if it is running 2 and 3 only

<It is now necessary to specify full paths for NFS to share and not just what the Finder shows.

Haven’t tried this yet but will do so next.
@David Pitt How did you find out the full Posix path names?
MacOS tries hard to hide the full names of files.

It looks as if it is running 2 and 3 only

Yes macOS still runs by default NFS 3 (not 4), to use 4 you need to pass a specific configuration, so that shouldn’t be the problem.

How did you find out the full Posix path names?

In my case I do not need to type the full path, however, given you are using /Users, then your full path should be:

/Volumes/Macintosh\ HD/Users/...

Or whatever you have called your boot disk, by default on the mac it’s always called “Macintosh HD” (If so, don’t forget NFS requires a "\ " for the space)

HTH

How did you find out the full Posix path names?

Posix???
The form required by Mac’s NFS is here

Insert /System/Volumes/Data before /Users.

This is macOS version dependent so :-

What version of macOS is in use?

I don’t remember exactly when I had to make the change.

MacOS tries hard to hide the full names of files.

It is a bit obscure.

I do use the Bresink NFS Manager on the grounds that it worked, having failed with manually creating files. It does now default to the ‘right’ form of path.

My history is here and here

The developer of NFS Manager has put in the effort to unknot macOS’s NFS to make it easy for me so I have purchased a license, it is only fair to do so. There is a demo mode, which I have made good use of.

The Mac is complicated, I needed help. If one knows what one is doing then …

Works here!

Some more progress. I reverted to short form path ie from
/Users/myuser/Public
and OmniClient is mounting the directory. I don’t have write access to anything but will try setting the permissions again.

This might all go wrong again because I have accepted an invitation from the Mac to upgrade the OS to Sonoma 14.2.1 – it is estimating 23 hours to complete the 9GB download.

and OmniClient is mounting the directory.

Nice work! For the write access make sure the user that you’re using to log in has write access permissions on the shared path. If it’s mapping your user to “nobody” then one way to run a quick test (highly insecure!!!!) is to chmod 777 the directory you’ve shared (just Public) and test.

As a side note: you can tell macOS to which user you wish to map all unauthenticated users.

HTH

It only took two hours not 23 to install Sonoma.
It appears to have worked with no drama, except, and wouldn’t you just know it. It tells me that macFUSE is out of date and will not work with this new level of OS.
Until now I did not know what macFUSE did, or I had forgotten. It is open source software that makes it possible to use non-native filing systems including of course NFS and pCloud.

Until now I did not know what macFUSE did, or I had forgotten. It is open source software that makes it possible to use non-native filing systems including of course NFS and pCloud.

JFYI: You can use NFS and pCloud on a mac without macFUSE. pCloud have their own client app, that can manage all the syncs and mount remote folders. NFS both client and Server are native on macOS. Did you mean NTFS ? (The Windows NT FS), If so there are solutions for that as well, worst case macFUSE will be updated soon.

https://osxfuse.github.io/

@Paolo – do you know of a definitive, or comprehensive or at least an adequate source of documentation for the contents and syntax of the /etc/exports file for a mac?
I have been searching and reading on the web for hours and have only encountered scrappy and out of date documentation.

@ John,

do you know of a definitive, or comprehensive or at least an adequate source of documentation for the contents and syntax of the /etc/exports file for a mac?

Hummm… all I can think of are some old books on administering macOS, you may check on amazon maybe? I have them somewhere in a box at my storage, so not able right now to check for titles.

As a quick help for you, The mac NFS supports only a subset of the typical NFS options. Here are the supported options as of Sonoma latest version:

-ro To specify that you want to share as readonly

-alldirs To allow a client to mount every object contained in your shared directory

-sec To specify a string (":" separated) of supported authentication protocols like krb5, krb5i, krb5p etc...

-network To specify which network is allowed to access a shared directory

-netmask To specify which network mask for the -network protocol

-maproot=user Specifies that the remote root user should be mapped to the specified user. You may specify either a username or numeric user ID. 

-maproot=user:[group[:group...]] Specifies that the remote root user should be mapped to the specified user with the specified group credentials. If you include the colon with no groups, as in -maproot=username:, it means the remote user should have no group credentials. You may specify a username or numeric user ID for user and a group name or numeric group ID for group. 

-mapall=user Specifies that all remote users should be mapped to the specified user. 

-mapall=user:[group[:group...]] Specifies that all remote users should be mapped to the specified user with the specified group credentials. If you include the colon with no groups, as in mapall=username:, it specifies that the remote user should be given no group credentials.

On earlier versions you could also use:

-kerb To specify the IP of the kerberos server for user authentication (not sure if this still works)

For more features, or to enable the NFS4 you need to configure it using the /etc/nfs.config file. But for RISC OS this is not needed, so I think you’re not interested about it.

HTH

@Paolo thanks for the documentation.

The good news. The following setup works.

Mac M1 mini
  /etc/export
    # NFS shares
    # 21.12.2023 JR on macmini
    # note Public has permissions 777 and is shared
    /Users/riscman/Public -network 192.168.1.0 -mask 255.255.255.0  


RISC OS
  Omni - mount
    NFS,Public,O,macmini,/Users/riscman/Public,nobody,,  

OmniClient mounts the shared directory Public and I can read, write and create files and directories.

But, there is always a but, the bad news will follow in the next post.

The good news. The following setup works.

Nice!

But, there is always a but, the bad news will follow in the next post.

Tell me about it! XD – sure, if I can be of help…

I read this:

The access privileges for users and groups are controlled by the permission settings of each single file and folder,
not by settings for the share. A share can only define access restrictions for computers.

AFAICT it is true. It would have saved me a lot of grief if I had known this.

Yes, that’s correct.

Althought if NFS4 has a bit more in depth security than NFS3. But in the case of RISC OS we can only use NFS2 and 3, so that doesn’t matter.

The key is in the “FS” of NFS Netwrok FileSystem. Plus on Linux things are a littl emore complicated because of the custom ACL on top of the traditional ACL. But luckly you are usign macOS which is a bit more userfriendly.

BTW I also showed you the quick and dirty test (chmod 777) which clearly gives away where the security is placed.

If you use -mapall=riscman that should force all users to use your riscman user privileges, not sure if this could be of help to you.

If you change this setting, beside of having to run “sudo nfsd update” you’ll also need to re-mount the shared folder, JFYI.

HTH

Here is my /etc/exports file with various attempts to define shares
All but one command is commented out.

# NFS share
# 21.12.2023 JR on macmini

# next command works -
# note1 - Public has permissions 777
# note2 - can't have this line and /Users/riscman simultaneously
# /Users/riscman/Public -network 192.168.1.0 -mask 255.255.255.0  

# next command works (for user nobody but not riscman or 501)
/Users/riscman -alldirs -mapall=501 -network 192.168.1.0 -mask 255.255.255.0

# next command fails - 
#/Users/riscman  -mapall=501 -network 192.168.1.0 -mask 255.255.255.0 (rw)
# showmount: cannot retrieve info from host: localhost: RPC: Program not registered  

# next command works (for user nobody but not riscman or 501)
# note1 - (rw) removed from end
#/Users/riscman  -mapall=501 -network 192.168.1.0 -mask 255.255.255.0

#/Users/riscman  -network 192.168.1.0 -mask 255.255.255.0

I would like to mount /Users/riscman as user riscman or uid 501. I can mount it
with user nobody, but most files are read only and some directories won’t open.

For example trying to open DeskTop gives message “insufficient access”
This still happens after a chmod 706 Desktop. (It shows as LWR/wr in the RISC OS filer)

I could set permissions 777 for all folders and sub-folders as I have done for Public,
but this does not seem appropriate for my main mac userid.

btw -alldirs does not seem to have any effect.

@ John

I would like to mount /Users/riscman as user riscman or uid 501. I can mount it
with user nobody, but most files are read only and some directories won’t open.

That is what -mapall is for, if you use the following:

/Users/riscman -32bitclients -alldirs -mapall=riscman -network 192.168.1.0 -mask 255.255.255.0

It should map all users to riscman local user. I need to double check if nobody falls also in this category. I added -32bitclients, because NFSv3 cookies are 64 bits. RISC OS DDE C should be ok, but given I did not have a look at the NFS source, this option might help, it will keep the cookies 32 bit like on NFSv2.

Login a user with RISC OS is going to be tricky, because I don’t think there is a way for Omniclient (or SunFish) to support kerberos. So, you’ll probably will have to stick to nobody. I will double check this in the morning tomorrow and post an update if I find something.

btw -alldirs does not seem to have any effect.

-alldirs allow a client to mount any objects within the shared path, so, if omniclient supports it, if for example you have a subdirectory called “foo” in your /Users/riscman, then you could mount just foo using /Users/riscman/foo as a path for Omniclient.

HTH

Thanks Paolo – I have a better understanding of what is going on now.
It seems that mounting a share with a user of riscman is too difficult.
So, for the moment I will stick with user nobody.

@David Pitt, does the NFS Manager software allow you use use your mac user
in the omni mount or does it give the equivalent access via user nobody?

In order to give “nobody” the same access as user “riscman” requires changes
in a lot of places. The following are all involved to some extent:
file permissions, extended attributes, groups, Access Control Language files,
localisation, and System Integrity Protection.

Provided the file or directory does not have extended attrs or ACL extensions,
there is little problem.
Directories can be opened without “r” permission. while files
can be made readable by isuing a chmod command on the mac.

sudo chmod ugo+r <filename>

I am thinking to do this for the top level directory:

sudo chmod -R ugo+r /Users/riscman

This should grant read access to Bob & Carol & Ted & Alice & anybody else
to all the files in my user directory. (on my local lan)

Ironic is it not that in attempting to increase security the mac is
encouraging behaviour that compromises it.

This still leavs the matter of ext attrs, ACL, and the real pain of localisation.

does the NFS Manager software allow you use use your mac user in the omni mount or does it give the equivalent access via user nobody?

There is an access related issue with Omni as reported in this bug. I have not so far persuaded NFS Manager to sidestep that. Thanks to ‘adr’ for bringing this to light, obviously I assumed user incompetence.

Fortunately there is no such problem with Sunfish. Better still Sunfish is faster the Omni NFS, which can therefore be discarded. (And I prefer LanMan98 to LanManFS.)

That’s the state of things here others may find differently.

NFS Manager does have a free fully working demo mode so it can be tried to see if it does what is required. It just nags a bit.

In the spirit of Peace and Goodwill that is appropriate to this season of Christmas and New Year I have declared a unilateral truce in the Struggle with Apple.

Instead of trying to bend it to my will I am trying to find out what it is willing to let me do.

I can’t speak for SunFish as it does not work on my ARMX6.
So the context is sharing files over NFS using OmniClient.
From the mac mini via the /etc/exports file I am sharing the two folders, that Apple recommends:

/Users/Shared and /Users/riscman/Public.
There is little difference between these two folders. I have them mounted as “macshare” and “macpublic”.

There is no way to authenticate a real user id on Omni with NFS protocol so I am using the id “nobody” which by defaults to read only access.

I would like to be able to manage contents of both folders as if they belonged to the same user.
That is to be able to create, read, write and delete files and folders regardless of what machine I am using.
This is not possible without intervention to change default attributes.

Macmini has full control over objects created on the macmini.
RISC OS has full control over objects created on RISC OS.
What I want is a convenient way of changing and updating permissions to allow cross platform operational symetry.

On RISC OS in a TaskWindow

*> NFS
*> chmod -R 777 /
permisions are set with warnings for objects not owned.

Alternatively from the RISC OS GUI:
from “macpublic” Select all and Set Access details to Public read and Public write tick Recurse then press enter.
Skip any errors for files in macpublic that belong the mac user.

Now the RISC OS objects are fully editable from the Mac, including Deletion.

It is not as easy for the reverse direction.

$> chmod -R 777 Public
sets permissions for files owned by riscman and gives a warning for others.

Now from RISC OS or Mac it is possible to modify any files in Public.
However the Mac prevents RISC OS from deleting any files that originate on the Mac side.
I got a solution to this problem using a group allow list from the Apple support sight but it did not work for me. I suspect it requires NFS4 not the NFS3 Omni uses.

The only way I have found to allow deletion of mac origin files is to change the file owner from “riscman” to “32767”
From a terminal on the Mac:
bq. $> sudo chown -v 32767

This works and it can be done recursively but is very clunky.
If the file is owned by id=32767 then it can be deleted from RISC OS and also from the Mac as the Mac has sudo powers.

The number 32757 is the user is/owner id that Omni gives to objects created in the mount “macpublic” and in “macshare”.
This is true for my ARMX6 and the Qube machines and persists over power off and reboots.
BUT I don’t know if it is true under all circumstances and can be trusted.

As to the the original question back at the start of the thread:

is there a recommended way to get a shared drive working between a Mac and a native, ie not emulated RISC OS machine?

I know the answer and am a sadder and a wiser man.

The number 32767 is the user is/owner id that Omni gives to objects created […] BUT I don’t know if it is true under all circumstances and can be trusted.

That is the user ID (UID) used for the user ‘nobody’ by RISC OS NFS, search for “UID” in the OmniClient chapter of the RISC OS 5 User Guide around page 180ish.

There could be 3 possible solutions:

• Use the -mapall mount option that Paolo mentions
• Run an authentication server which maps user names back to UID, put that in the Authenticator box in OmniClient
• Put the shared folder(s) into a group, add UID 32767 to that group, chmod the folder(s) to give the group appropriate permissions

Remembering I don’t have a Mac, so these are general hints from use of Unix, which might have Mac equivalents.

@Sprow thanks

• Use the -mapall mount option that Paolo mentions

This option appears to make no difference to file access of RISC OS files from the Mac

• Run an authentication server which maps user names back to UID, put that in the Authenticator box in OmniClient

This looks to be the proper way to go but I don’t know how to do it.

• Put the shared folder(s) into a group, add UID 32767 to that group, chmod the folder(s) to give the group appropriate permissions

The Mac has blocked all my attempts to implement this. Basically it will not allow a user to have a uid of 32757.

I think the best way forward is to abandon the Mac as a file server for RISC OS and go for a separate NAS file server.
ISTR someone further up this thread suggesting just this!

Now , The question is Which NAS? home brewed with spare Raspberry Pi or commercial box like Synology DS118.
Here is a fresh can of worms.

The Mac has blocked all my attempts to implement this. Basically it will not allow a user to have a uid of 32757.

I’ve not been following all of this in detail, but if you need to access the share with a specific UID and GID, have you tried using Sunfish as the RISC OS client instead of Omni? With that, you can set the two IDs the first time you connect to a share, to whatever values that share expects.

The question is Which NAS? home brewed with spare Raspberry Pi or commercial box like Synology DS118.

I’m currently using a Synology DS220j. It just works. Lanman98 connects reliably, every time, and Windows also connects. Both run automated backups. Both start off with Wake-on-lan, and the device goes to sleep again after 20 minutes of inactivity. That way, most of the time, it’s invisible on the network, so someone hacking in via the wireless LAN won’t know it’s there.

I’m holding off on one of the offered updates however, as it’s to SMB2, and I don’t want to take a risk of SMB1 ceasing to work. That would mean diving into the mire of Unix user/uid access, that I’ve failed to get working in the past.