NFS mapall user and group broken for mv

I have an odd issue since migrating from a RHEL NFS server to TrueNas.

I have a media mount where I use mapall to make sure all files are written as the correct user on the remote NAS Server. This is restricted to a couple of IP addresses - for example


With this old setup I could mv or cp a file onto the NFS mount and ultimately it would have the uid/gid of 2001.

Under TrueNas I’ve tried to setup the same configuration via the webui which results in the following entry in /etc/exports.


with a TrueNAS NFS mount

  • “cp” everything appears to work correctly, but results in the wrong umask of 600.
  • “mv” the file retains the uid/gid of the original user on the source machine running Fedora.

With my old RHEL NFS server both CP and MV preserved the anonuid/anongid values and the correct umask.

Any ideas as I’d prefer to not use a CIFs mount for this mult-user share.

Are you copying from fedora to TrueNAS?

mv generally just relinks a file. It does not alter file permissions in any way (and shouldn’t).

Yes I’m moving or copying a file from Fedora based laptops to the TrueNas servers.

I need a way for multiple users to copy files to the server, and ultimately have the same user own the files on the remote share. This worked fine in the past, but I’m having weird permission issues with TrueNAS

So for cp… what umask are you wanting?
Is there a way of setting this after the copy?

Ah, I had assumed you your referring to an actual server-side mv which would invoke a rename.

Ok it looks like my default umask on Fedora has changed from 022 to 077 which explains the CP issues.

With a copy from Fedora → TrueNas I can chmod the file later, but I’ve now fixed the default umask back to something sensible for home use.

Moving files from Fedora → Truenas is weird as despite using mapall the uid is being preserved, and once the file is on the server I can’t chown/chmod the file as I no longer have permissions.

Can you be specific if you think there is still a problem…

Yes I believe there is an issue. With mapall I’d expect that when writing a file to NFS via mv or cp the uid would match the mapall uid.

This is only happening with a “cp”

It’s a bit surprising… under the cover, both are copy commands that get turned into writes.

I wonder if your client is issuing a different write command option to try to preserve the original owner.??

What client OS? Can you verify with another OS?

In the meantime… it looks like cp is the better option.