NFS Insufficient Access

I use NFS to share files between a Mac and an ARMX6 machine.
The Mac directory is /Users/Shared. I can drag and drop into a filer window in either direction.
Occasionly I have to use chmod to adjust the permissions to allow read/write/create, but usually it works well.

But, here is a curiosity, something on the Mac does not like StrongHelp manuals.
All attempts to copy a StrongHelp manual into /Users/Shared are met with an “Insufficient Access” message.

I have tried putting the StrongHelp file into a zip, changed its type to Text, or Absolute, to no avail.
The copy starts then fails leaving a DEAD DEAD DEAD file marker in the directory.

It is not a serious problem because if I copy the manual to PCloud and from there to the Mac it works,
but it would be good to know what is going on.

But, here is a curiosity, something on the Mac does not like StrongHelp manuals.
All attempts to copy a StrongHelp manual into /Users/Shared are met with an “Insufficient Access” message.

Out of interest, could you try copying it with a *Copy command rather than the Filer?
F12 command prompt *Copy MyStrongHelpFile NFS::MyMount.$.WhereEver.MyStrongHelpFile ~C
Or, if you can’t be bothered typing all that go Configure→Filer→Make file operations multitask and untick/Set for a moment.

Try doing the copy before you load StrongHelp (taking out of run at boot if necessary), in case it’s something to do with the manuals being image filing systems.

I’m using NFS to a disk on a Linux Raspberry Pi, and don’t had any problems copying manuals with or without StrongHelp loaded, including ones currently open in StrongHelp.

*show StrongHelp*
*
*
*copy RAM::Q_Ram.$.Toolbox tbox
  Copy file RAM::Q_Ram.$.Toolbox as NFS::macshare.$.zjunk.tbox
  (Y/N/Quiet/Abandon) ? y
0 files copied, total 0 bytes
Insufficient access
*
*copy RAM::Q_Ram.$.TextFile7 t7/txt
  Copy file RAM::Q_Ram.$.TextFile7 as NFS::macshare.$.zjunk.t7/txt
  (Y/N/Quiet/Abandon) ? y
File RAM::Q_Ram.$.TextFile7 copied as NFS::macshare.$.zjunk.t7/txt, 413 bytes
1 file copied, total 413 bytes
*

StrongHelp not seen at Boot.
Copy fails as before.

What is the host filing system? Does MAC OS require a known file type extension to work as in the second copy.

I get a similar problem with all files over 4096 bytes. Using Sunfish works fine.

[using *Copy *]
StrongHelp not seen at Boot.
Copy fails as before.

And what access permissions do they have in RISC OS? Looking at my StrongHelp manuals some of them have ’L’ock and various do and don’t have public ’r’ead. Unless as druck says the file extension is significant, a StrongHelp manual is just a file (same as a text file) when StrongHelp isn’t loaded.

I get a similar problem with all files over 4096 bytes. Using Sunfish works fine.

Same suggestion to you: does copying not via Filer Action do something differently? If so, check your NFS server runes. That has the hallmarks of permission problems. And by “problem” I probably just mean “done differently to Sunfish”.

There does appear to be a size component to this issue. A ‘large enough’ file does give the “Insufficient access” error but the file has arrived on the Mac with the expected permissions but in the RISC OS Omni window it is displayed as an untyped file. Removing the comma separated file extension number on the Mac and refreshing the Omni window does then show the file correctly typed. Downsizing .html to .htm on the Mac was also required.

The Mac NFS runes are as laid down by the Bresink NFS Manager long ago on the grounds that it actually worked which is more than could be said of any user attempts.

*copy and ‘drag and drop’ both do the same.

After a bit of trial an error I found this combination worked for all files.

mkdir testfolder
sudo chown nobody:nobody testfolder
sudo chmod 777 testfolder

Then this line in /etc/exports. Change network and mask to match your network.

/Users/username/testfolder -alldirs -network 192.168.1.0 -mask 255.255.255.0

sudo nfsd restart

I’m not certain if this is related, but I came across it the other day:

A key point to be aware of, to avoid “Insufficient access” errors, is that the RISC OS NFS client doesn’t support current user authentication protocols.

https://www.riscosopen.org/content/documents/git-linux-cli-nfs

I’m not certain if this is related, but I came across it the other day

Only that it then goes on to say

This means that it always creates new files and directories with Unix user-ID (UID) 32767 and group-ID (GID) 9999, and its access to existing files and directories are only permitted to the extent that a user with that UID or GID would be.

I’ve long had

anonuid=1000,anongid=1000

(insert your own UID and GID) in relevant entries of /etc/exportfs in order to ensure that written files get UIDs and GIDs appropriate to the user that the shared files belong to.