[SOLVED] NFS mounted by red-only despite correct permissions

skubik · 06-07-2015, 06:49 PM

I've been trying to figure this out all day. Perhaps someone can help shed some light on the problem?

So, I have a RaspPi2 with an NFS (v4) export that I want to mount on my laptop, running Slackware "14.0" (kernel 3.8.11; it was originally installed as Slack64 13.37 and have upgraded various packages via slackpkg, but not the entire thing).
I took special care to ensure that the gid's on the Pi and my laptop match (though it's called something else on my laptop; www2 instead of www on the Pi).

I'm able to mount the NFS export on my laptop, and it *appears* that the permissions are correct (gid on the mounted directory & the directory's contents is 'www2'), and my laptop user belongs to the 'www2' group.

But, all the contents of the directory are read-only to me. I can write to files easily if I'm root (on the laptop), and if I chmod to 777, I'm able to write to the share as my laptop user, but when the directory is 775, I can only read.

Furthermore, I have another box that I recently installed Slack64 14.1 onto, and despite some fiddling with getting rc.rpc started, I'm able to mount and write to the NFS share with no problems at all.

So what am I missing on my "14.0" laptop?

Thanks in advance!

astrogeek · 06-07-2015, 06:52 PM

What does the /etc/exports line for that look like on the pi?

ferrari · 06-07-2015, 08:38 PM

In addition to the /etc/exports line, please show us the client NFS mount point details

Code:

mount|grep nfs

and the user/group ownership of the mount point

Code:

ls -ld /mount/point/directory

skubik · 06-07-2015, 08:39 PM

I only have 1 line in /etc/exports on the Pi:

Code:

/export/project   192.168.0.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check,fsid=0)  10.8.0.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check,fsid=0)

The 192.168.0.0 network is the local ethernet connection and the 10.8.0.0 is part of a VPN connection that I use to connect remotely via SSH.

The mountpoint details on the laptop:

Code:

10.8.0.30:/export/project on /mnt/project type nfs (rw,nfsvers=3,addr=10.8.0.30)

Code:

drwxrwxr-x 5 1995 www2 420 Jun  7 17:17 /mnt/project/

uid & gid are both 1995 on the Pi; and group 'www2' has gid 1995 on the laptop

tdos20 · 06-09-2015, 08:44 AM

What does the bind mount look like on the pi for the /export/project file? I had issues when the bind mount was across file systems.

skubik · 06-09-2015, 11:36 AM

I have the bind setup in /etc/fstab. It goes as such:

Code:

/var/www/project      /export/project    none    bind    0       0

I should also mention that I currently have /var/www mapped to a ramdisk/tmpfs on the Pi (instead of using the slow SD card; I copy the content into /var/www from the SD card).
It is setup in fstab as such:

Code:

tmpfs           /var/www      tmpfs   defaults,size=300M                              0       0

I also tried upgrading my laptop kernel (out of desperation) to 3.10.17; the one that comes with Slack 14.1, as well as updated my nfs-utils package (to 1.2.8; again from Slack 14.1) and it didn't make a difference.

I did, however, notice some items in my laptop's syslog that may or not be related. Figure I'd post them and see if it's a hint of what's going on:

Code:

rpc.statd[764]: Running as root.  chown /var/lib/nfs to choose different user

kernel: [   95.820838] svc: failed to register lockdv1 RPC service (errno 97).

Again, I don't know why I'm able to mount this without any problems on my other Slack64 14.1 box but my laptop will only give me read-only access. I'd expect that if it was a problem with the Pi's setup then I'd get the same result on both systems.

Thoughts?

tdos20 · 06-10-2015, 03:38 AM

for nfs version 3 you don't have to do the bind mount, are you mounting using nfsv3 on the Slack64 14.1 box? Maybe post the fstab for the Slack64 14.1 box is there's any difference..

skubik · 06-10-2015, 11:29 AM

On the Slack64 14.1 box, I'm only manually mounting to test the Pi's NFS export, so no fstab entry. Ditto for the laptop currently as well (once I have something that works manually, I'dd add it to the fstab)

Code:

mount -t nfs 10.8.0.30:/export/project /mnt/tmp/

When I posted the mountpoint details on the laptop, above, it indicated nfsvers=3, which I explicitly used for a bit to try and mount using nfsv3 since it seems everything defaults to v4, but it didn't seem to make any difference.

skubik · 06-10-2015, 11:42 PM

Something I came across is that the uid of the user I'm using to try and edit files on the NFS mount is the same on the Pi and the 14.1 box, but not on the laptop.
That is, on the Pi and the 14.1 box, the uid I'm using is 1001, but on the laptop it's 500.
Might this make a difference with the RPC service?

The gid is the same across all three systems, which is what I'm hoping would allow me to have rw access to the files on the NFS mount (all files are 775).

I'm becoming increasingly desperate to find a solution for this. Any insight or suggestions is greatly appreciated!

astrogeek · 06-11-2015, 12:10 AM

Quote:

Originally Posted by skubik

Something I came across is that the uid of the user I'm using to try and edit files on the NFS mount is the same on the Pi and the 14.1 box, but not on the laptop.
That is, on the Pi and the 14.1 box, the uid I'm using is 1001, but on the laptop it's 500.
Might this make a difference with the RPC service?

The gid is the same across all three systems, which is what I'm hoping would allow me to have rw access to the files on the NFS mount (all files are 775).

I'm becoming increasingly desperate to find a solution for this. Any insight or suggestions is greatly appreciated!

Yes, of course that would prevent the laptop user from writing to the NFS mount.

The laptop user is presumably member of the 1995 group - on the laptop - but NOT on the NFS machine!

I have been following this thread but it never registered that the uid was different on the laptop. Here is what you now say you have:

Code:

Laptop      NFS (Pi)     SW64-14.1
uid=500     uid=1001     uid=1001
gid=1995    gid=1995     gid=1995

So even though the gid is the same, there is no user with uid=500 on the NFS machine who is also a member of gid=1995, so it is read-only for uid=500.

A quick fix might be to create a user with uid=500 on the Pi and add it to the 1995 group.

You should also be able to do that with anonuid/anongid and all_squash. I have never used this but man exports includes the following example:

Code:

/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)

...which will force all uid/gid to 150/100.

You should be able to adapt that, although not sure it will work across NFS3 client with NFS4 server.

tdos20 · 06-11-2015, 05:54 AM

What does the actual fstab on the laptop look like? If you are mounting via nfsv3 you should just be able to do something like this:

Code:

10.8.0.30:/var/www /mnt/project nfs nfsvers=3,rsize=8192,wsize=8192,timeo=14,intr,rw 0 0

if /var/www is exported on the pi

slacktroll · 06-11-2015, 03:54 PM

Sorry for offtopic, but did you try sshfs? it just works!

skubik · 06-12-2015, 12:56 AM

That was it!
The UID was the problem;

Quote:

Originally Posted by astrogeek

Code:

Laptop      NFS (Pi)     SW64-14.1
uid=500     uid=1001     uid=1001
gid=1995    gid=1995     gid=1995

This is exactly right! Because my user on SW64-14.1 had UID 1001 as did the Pi, those two were able to connect no problem. But because my laptop UID was 500, it wasn't authenticated by the RPC service.

I solved this by changing the UID of my account on the Pi and SW64-14.1 to 500 to match my laptop (going through and chowning all my files would have been a pain, whereas the Pi & SW64-14.1 are very fresh installs).

I just tried it and I'm able to edit files on the NFS mount no problem.

Thank you so much to everyone for offering their suggestions!

astrogeek · 06-12-2015, 01:07 AM

Great!

Sorry I did not realize earlier that the uid was not the same - I read the thread multiple times and my brain cell just never registered that fact.

Glad you got it working.