[SOLVED] NFS share mounting problem

TSquaredF · 03-15-2011, 01:30 PM

I have two computers on my home network, a desktop & a laptop. I use the desktop for a short time every morning & my wife is on & off of it during the rest of the day. I use the laptop for my primary machine & have an NFS share set up on the desktop so that I don't have to duplicate data between the two computers. Both of the machines run -current. Since the recent update to 13.37, my NFS share has been mounted weirdly on the laptop. The folder is shared on the desktop via this line in /etc/exports:

Code:

/mnt/spock      192.168.123.0/24(rw,no_subtree_check,no_root_squash)

The desktop is properly identified in the laptop /etc/hosts:

Code:

192.168.123.8   kirk.enterprise.lan kirk

The share is mounted on the laptop via this line in /etc/fstab:

Code:

kirk:/mnt/spock         /mnt/spock      nfs     noauto,users,rw,hard,intr,rsize=16384,wsize=16384

I have a postconnection script in wicd that mounts the share if the network & desktop are found. I also have a script on the desktop that chowns all directories/files to bill:users & chmods directories to 775 & files to 664. I do not remember now why I set directories to 775, but I had some good reason & it works for us. In the past the share on the laptop had the same owner/group/permissions as were on the desktop. Now the permissions are the same, but the owner group show up as:

Code:

$ ls -l /mnt/spock
total 52
drwxrwxr-x 13 4294967294 4294967294 4096 Dec 28 13:59 data/
drwxrwxr-x  5 4294967294 4294967294 4096 Mar  8 11:50 ebooks/
drwxrwxr-x  2 4294967294 4294967294 4096 Mar 13 14:01 isos/
drwxrwxr-x  2 4294967294 4294967294 4096 Dec 24 16:50 lost+found/
drwxrwxr-x 46 4294967294 4294967294 4096 Mar  3 21:21 music/
drwxrwxr-x 74 4294967294 4294967294 4096 Mar  7 16:40 pictures/
drwxrwxr-x  7 4294967294 4294967294 4096 Feb  5 10:13 sbopkg/
drwxrwxr-x  4 4294967294 4294967294 4096 Feb 25 07:59 slack/
drwxrwxr-x  5 4294967294 4294967294 4096 Dec 24 12:00 tags/
drwxrwxr-x  2 4294967294 4294967294 4096 Mar 13 14:25 transfer/
drwxrwxr-x  9 4294967294 4294967294 4096 Jan 12 14:30 videos/
drwxrwxr-x  4 4294967294 4294967294 4096 Dec 24 12:39 wavs/
drwxrwxr-x 12 4294967294 4294967294 4096 Dec 24 12:39 windows/

Every directory/file on the share has owner & group set to 4294967294. This seems to make no difference to the usability of the share. "cp" copies a file to the share with the above numbers as owner & group. "rsync" does the same, but gives the error:

Code:

rsync: chgrp "/mnt/spock/transfer/home/.file.laJChp" failed: Remote I/O error (121)

I googled the error & found that ErrNo 121 is a Remote I/O error (Duh!). By the way, the owner/group/permissions are correct on the desktop, even for files written from the laptop.
How can I fix this?
Regards,
Bill

dwalkes · 03-15-2011, 10:21 PM

Hi Bill,
I think 4294967294 is "nobody" which in my experience means you've copied a file with user/group that is not mapped on the system in question (the laptop if I understood your post). I'd recommend looking at your /etc/passwd and /etc/group file on the desktop to determine the UID/GID value for bill:users (typically the only number on the line with matching user or group name). Compare this to the uid/gid for the same accounts on the laptop. I think this problem can happen if the laptop does not use a uid/gid with the same value.

myoung · 03-21-2011, 06:26 AM

Hi,
I am having the same problem but I do have the same uid/gid values on both computers.
They have the same /etc/passwd /etc/shadow and /etc/group files
Both are running slackware-current
I think it broke with "Slackware 13.37 release candidate 2"

niels.horn · 03-21-2011, 06:41 AM

This is a side-effect of using NFSv4.
Try setting "vers=3" in the options of your fstab file - that worked for me...

myoung · 03-21-2011, 07:19 AM

Thank you for "vers=3".
I will use that until NFSv4 learns about users and groups.
I presume NFSv4 will learn about users and groups in the near future!

My googling gave me the idea that idmapd would fix this problem without changing back to NFSv3
but I did not find nice instructions on how to set it up and it seems odd to me that NFSv4
does not know about users and groups.

niels.horn · 03-21-2011, 08:43 AM

Yes, NFSv4 does not work with UID or GID - it uses idmapd.
But this does not work in Slackware at the moment...

It's on my "to-do" list, as I use NFS mounts a lot, but for now I am using the "vers=3" option, so that I can do some research without the pressure of a non-working system

Alien Bob · 03-21-2011, 04:11 PM

Quote:

Originally Posted by niels.horn

Yes, NFSv4 does not work with UID or GID - it uses idmapd.
But this does not work in Slackware at the moment...

It's on my "to-do" list, as I use NFS mounts a lot, but for now I am using the "vers=3" option, so that I can do some research without the pressure of a non-working system

Slackware's installer hard-codes "vers=3" as an option to the nfs mount since 13.1.

Eric

niels.horn · 03-21-2011, 04:41 PM

Well, something is not working then...

This is an example of a mount output when the "vers=3" option is not given:

Code:

niels-sw:/srv/data/ftp_pub/pub on /srv/data/ftp_pub/pub type nfs (rw,rsize=8192,wsize=8192,hard,intr,vers=4,addr=192.168.2.110,clientaddr=192.168.2.1)

It definitely defaults to "vers=4"

This is on a Slackware 13.1 box mounting an NFS directory hosted on a -current box.
The path is "exported" in /etc/exports on the server and mounted automatically from /etc/fstab on the client.

<edit>
Hm, reading your post again, I see you said that the *installer* uses vers=3.
But normal mounts default to vers=4
</edit>

niels.horn · 03-21-2011, 05:45 PM

I just checked the nfs-utils package and its SlackBuild script, and now have a suggestion for Pat...

Since nfsv4 is not supported yet in Slackware (it is disabled in the configure stage), maybe it would be nice to:

1) configure with the "-enable-mountconfig" option
2) include the standard /etc/nfsmount.conf file
3) set "Defaultvers=3" in this file

I tried this here and it works.

Just an idea...

niels.horn · 03-22-2011, 05:51 AM

And fixed with the latest -current update, now 13.37-RC3!

TSquaredF · 03-22-2011, 04:22 PM

Thanks to everyone, particularly Niels & Pat. Today's updates have solved my problem. All is now well, again. Sorry I haven't visited this thread, except to open it & now to mark it solved, but life has been rather hectic around here for the past two weeks, including a wreck that still has my pickup in the shop, so have been hassling insurance cos, rental car cos, etc. More fun.
Regards,
Bill

Woodsman · 03-25-2011, 10:30 AM

Apparently this problem affects 13.1 too. Yesterday I installed 13.1 on a spare hard drive. NFS refused to connect from that box to a 12.2 system. I had to add nfsvers=3 as a mount option. I had no problem using NFS to connect from the 12.2 system to the 13.1 shares.

Alien Bob · 03-25-2011, 11:00 AM

Quote:

Originally Posted by Woodsman

Apparently this problem affects 13.1 too. Yesterday I installed 13.1 on a spare hard drive. NFS refused to connect from that box to a 12.2 system. I had to add nfsvers=3 as a mount option. I had no problem using NFS to connect from the 12.2 system to the 13.1 shares.

Yes, that is why I mentioned 5 posts up that "Slackware's installer hard-codes "vers=3" as an option to the nfs mount since 13.1."

Eric

Woodsman · 03-25-2011, 11:07 AM

Quote:

Yes, that is why I mentioned 5 posts up that "Slackware's installer hard-codes "vers=3" as an option to the nfs mount since 13.1."

You did, but I did not notice that.

When I ran into the problem last night I remembered this thread. I started reading from the end of the thread to find the snippet of text I needed to add as a mount option. So although you mentioned that five days ago I did not scroll back that far.