2

Both server and client are cent os 7.0

My data VM has a exports file:

/data   10.75.0.0/24(rw,sync,no_subtree_check) 10.50.1.0/24(rw,sync,no_subtree_check,no_root_squash)

My client has a fstab:

10.50.1.248:/data/archive/images /export/images nfs rsize=32768,wsize=32768,actimeo=0,bg,intr

Sure enough that client whose user is arc can ls /export/images but if I try to cd into there and touch a file:

[arc@megamcachine images]$ touch somefile
touch: cannot touch ‘somefile’: Permission denied

Now the id of that user on the data vm is:

id arc
uid=1001(arc) gid=1001(arc) groups=1001(arc),10000(canwrite),10001(tron)

The id arc on the client is:

 id arc
uid=1001(arc) gid=1001(arc) groups=1001(arc),10000(datawrite),10001(tron)

I am not sure what I am missing. I had another machine that was mounting this nfs mount and those users work just fine...(a caveat those users are all in the users and groups that own these files) but arc is in datawrite (canwrite) so not sure where the permission denied is coming from. If I goto my data vm that is exporting the NFS mount and su as the arc user I can write in the /images folder no issue.

Arc user can write to disk on the server itself:

[arc@35M_DATA images]$ touch somefile
[arc@35M_DATA images]$ ls -lh
-rwxrwxr-x.   1 tron datawrite 9.6K Apr  1  2021 q4list
-rw-rw-r--.   1 arc  datawrite 0 Nov  8 11:58 somefile     <---
drwxrwxr-x. 411 tron datawrite 12K Nov  7 17:15 tcam
drwxrwsr-x.   3 tron datawrite 4.0K Sep 29 18:12 tmp
drwxrwsr-x.   2 tron datawrite 4.0K Oct 25  2011 ytgold
[arc@35M_DATA images]$

[arc@35M_DATA images]$ ls -ld
drwxrwsr-x. 257 tron datawrite 12288 Nov  8 11:58 .

From client:

[arc@ecamera-icc images]$ ls -ld
drwxrwsr-x 257 500 datawrite 12288 Nov  8 09:58 .
[arc@ecamera-icc images]$
Codejoy
  • 67
  • 3
  • 13
  • this could help https://serverfault.com/questions/812813/nfsv4-user-mapping/812829 + http://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+with+AUTH_UNIX . If you want a "quick'n dirty fix", using protocol v3 should work for your case. – A.B Oct 29 '21 at 14:28
  • I would be down to try the 'quick fix' is that in the export on the server or the mount on the client? guessing on the mount with a nfs3 – Codejoy Nov 01 '21 at 15:02
  • I tried on the client: mount -t nfs -o vers=3 192.168.1.10:/data /mnt/data then exited root and was my arc user again. Still touching a file in /mnt/data/ gave a permission denied. So maybe something more on the server? It is centos7 can I force it to do nfs3? – Codejoy Nov 01 '21 at 19:40
  • Seems my idea was wrong. Sorry no other idea – A.B Nov 01 '21 at 20:13
  • no worries, thanks for the attempt. Could still be a security issue but I am flummoxed since the GID/UID all match best I can tell. – Codejoy Nov 01 '21 at 20:40
  • Can you write into `/data/archive/images` as `arc` on the server? Add the result and the output of `ls -ld /data/archive/images` to the question. – Nasir Riley Nov 02 '21 at 06:05
  • I added the results of that to the question, I was able to write to same folder on the server as the arc user. – Codejoy Nov 08 '21 at 17:02
  • Well I do not know what changed, but I rebooted the server that was serving that nfs mount and now all of a sudden the client is happy and can write to it all. *Shrug*. The reason why I rebooted the server was I realized it was set to DHCP and I went into /etc/sysconfig/network-scripts to give it a static IP address. Rebooted and it worked. So not sure if it was something to do with a dynamic IP (Which didn't change) or all the user adding I did or what not needed a reboot. But I am happy. – Codejoy Nov 11 '21 at 17:29

0 Answers0