NFS Permission Issues

[oznah]

At this point I have read the manual and searched around and I still can't figure this out. I trying to connect to a FreeNAS NFS export from an Arch Linux box. I setup the export on the NAS and it seems ok. On the nix box I can mount the export but I can't write anything. I also can't chown any of the files. This is on a home network so functionality is more important than security.

Here's how FreeNAS is configured:
NFS export config

NFS service config

ZFS dataset config

Here's the output of a few commands from the nix box to help illustrate:

I can see the export
# showmount -e nas.localnet
Export list for nas.localnet:
/mnt/vol0/data 192.168.23.0

I can mount the export
# mount
nas.localnet:/mnt/vol0/data on /mnt/nas type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.23.10,mountvers=3,mountport=833,mountproto=udp,local_lock=none,addr=192.168.23.10)

Here are the perms
ll /mnt/nas
total 202
drwxrwxr-x 2 root root 22 Aug 18 21:28 iso
drwxrwxr-x 257 root root 259 Jun 15 23:10 music
drwxrwxr-x 271 root root 281 Jun 14 23:55 photo
-rwxrwxr-x 1 root root 9395 Jul 21 22:26 pkgs.txt

I can't write to the nas
# touch /mnt/nas/iso/test.txt
touch: cannot touch ‘/mnt/nas/iso/test.txt’: Permission denied
# sudo touch /mnt/nas/iso/test.txt
[sudo] password for oznah:
touch: cannot touch ‘/mnt/nas/iso/test.txt’: Permission denied

can't change ownership
# sudo chown uid:gid /mnt/nas/pkgs.txt
chown: changing ownership of ‘/mnt/nas/pkgs.txt’: Operation not permitted

Any ideas?

oznah

 

[Yatti420]

Are you connected via guest users? drwxrwxr-x what if u chmod (777) the iso directory so drwxrwxrwx can you now write? Is your user configured in FreeNAS GUI properly?

 

[oznah]

There is no user setup on the Freenas box. I thought when you connected via NFS you connect as yourself (perms are network based) and you should be able chmod/chown the files to whatever perms you desire on the local system. That's been my experience in the past at least.

When I try to chmod files 777, as root or as myself, from the client machine, I get "operation not permitted" error.

Also, when I try and set the write bit for "other" on the zfs dataset, I click save and then check the setting again and the write bit is unchecked again.

 

[Whattteva]

Pretty sure you can set UID and GID mapping when you mount the share and this will set the user/group used on the FreeNAS box on the mounted share.

 

[oznah]

Pretty sure you can set UID and GID mapping when you mount the share and this will set the user/group used on the FreeNAS box on the mounted share.

Is that necessary though? I will if I have to, but this is a home setup where I'll be sharing media files.

 

[Whattteva]

Is that necessary though? I will if I have to, but this is a home setup where I'll be sharing media files.

Well, the file system needs to map it to some user as every operation is always associated to a user. Otherwise, it will not know whether to allow or deny what. A computer system is a deterministic system, it can't read your mind.

Since you don't seem to care about security or anything, you can simply assign it to root user (UID 0) and it will allow everything. That way, you don't need to create any user on the FreeNAS database.

 

[freenas-supero]

Hi guys, same issue here and I can confirm that without creating a user on the freenas box and telling the NFS export to map root (or all but NOT both) as this specific user, I couldnt do anything with the exported share. I too could mount it on the remote client, read but not write.

My issue is that even if I did what I said above, I still cant chown files... oznah, have you made it work yet?

 

[oznah]

I did get it to work, but you're probably not going to like the answer. I rebuilt everything. I started with a new zfs dataset. I then logged into the nas and rsynced from the old dataset to the new. Then I deleted & re-setup all the nfs exports again per the FreeNas docs.

I am pretty sure my issue was that when I originally created the dataset with cifs in mind so I selected "windows" as the "share type". Later I decided I wanted to do nfs so I changed the "share type" to "unix". I don't think it liked that, so I ran into all the issues above. Once I created everything anew, it works no problem.

I hope this helps.

 

[freenas-supero]

Hi there,

you're right, I dont like the answer but if it worked, well, so be it!

I just hate these anomalies. No reasons for it to happen but nevertheless it does. For myself, I rebooted both my CentOS server and the Freeenas server and it seems now I can change the owners of the files as I wish. Dont ask me what changed between the reboot but I didnt change anything myself.

I also noticed that my strange NFS daemon errors (radix node...) are gone (for now.)

Cheers!

 

[Robert Gem]

Hi oznah,

This is only 9 months later, BUT I found this thread while googling for a solution to just your problem. The root cause of your problem (from googling and testing - I'm not that smart !) is that the NFS server (FreeNAS in this case) is exporting its filesystem with the root user mapped to some other user for security - if you want the full details google for "NFS root squash").

The way I set up the NFS share was to set the Maproot user to "root" and the Maproot Group to "wheel" - this way when you have the NFS share mounted and you run something as root (or via sudo) on the client you are also root on the FreeNAS box, and so you can change the ownership of files OK. The other thing you may need to do is to set up the permissions on the root of the share (/mnt/vol0/data in your case) to rwx for User, Group and Other and check the "Apply Recursively" box. Yeah - I know ! This defeats all the security, but in my case and yours the NAS server is on a protected local network and I *just want to use it*.

Don't hesitate to contact me if you have any questions - Best Regards, Rob.

 

[trevmac789]

Sorry this is late to the party, but if someone happens to stumble upon this, I had the same problem as the OP as I ditched Windows for Mint and decided to change my shares from SMB to NFS.

I didn't need to do anything as drastic as burn all my volumes to the ground thankfully as I just built a nextcloud VM and it would have been a pain.

My problem was that although I had changed my shares to NFS and turned off CIFS service, I needed to also change the permissions on my volumes as they were still set to windows permissions. As soon as I flipped them to Unix my mounted shares immediately became writable, yay! Hopefully this will help someone down the road. Almost reminds me of Windows NTFS local permissions and share permissions needing to be in sync. I obviously had a conflict and my desktop CPU melted like V'ger in Star Trek trying to comprehend a paradox ahahaha.

Thanks Oznah for getting me on the right track, it didn't click until I read your post. I had been troubleshooting for a couple of hours and was completely at a loss.