Can't Use NFS to Access Home Shares

Can you try toggling the NFS for the home shares off then on again?

Using CIFS/SMB the admin can see home folders. I'm not sure about NFS though.

Usually, the home directories (folders) are exported as "/home/<username>" from the ReadyNAS.

Try that.

Also, from your Linux system, see if you can get the list of exports using the following:

showmount -e <IP of ReadyNAS>

That will give you a definitive list of your exported shares that are allowing NFS and the pathname will be shown as the first field of the output.

You might also want to check the allowed IPs of hosts and options in use for each share.

Hope that helps. :)

Thanks guys,

I tried both suggestions.

The toggle of NFS for Home folders did not change anything.

The showmount gives reasurance that /home is being recognised for NFS.

Output below.

jim@WS-2 ~/Desktop $ showmount -e 192.168.0.xxx
Export list for 192.168.0.xxx:
/data/Pictures *
/home *
/data/Videos 127.0.0.1
/data/Music 127.0.0.1
/data/Documents 127.0.0.1
/data/Backup 127.0.0.1
< after toggle of NFS for Home Folders >
jim@WS-2 ~/Desktop $ sudo mount -t nfs 192.168.0.xxx:/home/jim /mnt/NFS
[sudo] password for jim:
mount.nfs: access denied by server while mounting 192.168.0.215:/home/jim
jim@WS-2 ~/Desktop $

Have you tried logging in to NFS specifying the user you wish to connect as?

Hello! I'm trying to achive/understand the same thing, but I can't grasp the whole picture...

mdgm wrote:
Have you tried logging in to NFS specifying the user you wish to connect as?

I'm having trouble when I try to use "username=xxx,passwd=xxx" when mounting NFS shares. I don't know if that is doable, since (as I understand) NFS is only using uid's and gid's for access control.

Oops. My knowledge of Linux clients isn't as good as other ones.

Do the UIDs and GIDs for the user(s) you are using on your Linux PC(s) match that of user(s) on the NAS?

Update - some new findings ---
Because the showmount -e Linux command shows the NAS is exporting the NAS's /home folder <see previous post> on the LAN, I decided to try mounting just that (/home), not /home/jim. This is what I get:

jim@WS-2 ~/Desktop $ sudo mount  192.168.XXX.XXX:/home /mnt/NFS 
jim@WS-2 ~/Desktop $ ll /mnt/NFS 
total 4 
drwxr-xr-x 1         98    98   42 Sep  3 12:03 ./ 
drwxr-xr-x 3 root       root  4096 Sep  7 16:54 ../ 
drwx------ 1         98    98    0 Sep  3 19:39 admin/ 
drwx------ 1 messagebus users   38 Sep  3 15:20 user1/ 
drwx------ 1 syslog     users  136 Sep  3 15:41 user2/ 
drwx------ 1 libuuid       98    0 Sep  3 12:03 user3/

So, I can mount the /home folder; but not sub-folders of /home. I manually edited the IP address of the NAS and user names in the above code block to hide the correct values.

Notice the User & Group values in the folders under /home that became available. The UID & GID values don't match between the computer's Linux system and the NAS's OS. I cannot access any of the folders under the mounted /home folder, obviously due to permissions.

So, now I need to get the computer's UID & GID values to match, or find a way to translate or associate between the two devices. On a whim I created a new Local User on the NAS and manually assigned the UID for that user to 1003 which matches a different user on the computer system. The NAS created the new user with the desired UID just fine, but that user does not show up when I do a fresh NFS mount (umount then mount). The contents of the NAS /home folder after the new mount are identical to that shown in the code block.

The NAS software appears to want UID values starting at 101, and Linux starts UID values at 1000. Assigning UID value of 1003 on the NAS to a new user is, I'm guessing, beyond the range of valid (usable) UID values on the NAS, at least for NFS. The NAS gives no indication that the UID value of 1003 is bad or not usable for NFS.

The only ID value that matches between the computer's Linux and NAS OS is the GID value for group named "users", that is 101. I checked the computer's passwd and groups files and the Users and Groups listed in the code block agree with my Linux system, as expected. not even root can access those folders, or make changes such as chown or chmod.

I think the NAS OS needs to alter their minimum UID value to start at 1000 (or make that a configuration setting when setting up the NAS), and maybe a tweak is needed in the NFS allowed UID values. I believe UID values can be set in a configuration file on the server (NAS) but that would require using SSH, which NetGear says can void getting future support. I also think NFS supports UID:GID transalation but I am not sure that can be done on the client side, but only on the server (NAS) side, again the SSH warning enters the picture. I'm still researching this.

Are there any ReadyNAS OS 6.1.8 users out there using NFS to Linux systems that have resolved this? Which appoach did you use to get this working.

wagb4 wrote:
The NAS software appears to want UID values starting at 101, and Linux starts UID values at 1000. Assigning UID value of 1003 on the NAS to a new user is, I'm guessing, beyond the range of valid (usable) UID values on the NAS, at least for NFS. The NAS gives no indication that the UID value of 1003 is bad or not usable for NFS.

Private home shares are created when the user first logins using samba. After the first login using samba if the user logs out then logs in again the user should see the private home share.

wagb4 wrote:
The only ID value that matches between the computer's Linux and NAS OS is the GID value for group named "users", that is 101. I checked the computer's passwd and groups files and the Users and Groups listed in the code block agree with my Linux system, as expected. not even root can access those folders, or make changes such as chown or chmod.

I think for home shares using samba would be better for administrative tasks. The admin shouldn't write to another user's private home share (as that may cause ownership/permissions issues)

wagb4 wrote:
I believe UID values can be set in a configuration file on the server (NAS) but that would require using SSH, which NetGear says can void getting future support. I also think NFS supports UID:GID transalation but I am not sure that can be done on the client side, but only on the server (NAS) side, again the SSH warning enters the picture. I'm still researching this.

If you mess things up using SSH then you may be denied support, but it does depend on what you do. For some problems caused by SSH, help may be provided for a fee, but it does depend on what's happened.

Also note that some configuration is automatically repaired based on values stored in our readynasd database.

In my RN102, I have the option to specify what UID a new user will get, in the "New User" dialog.

Even if I specify the same UID for a user, identical as his UID in a particular Linux host, from where I would like to use the NAS over NFS to hold the /home/* directories, I can still not get the correct behavior.

deb1 (nikos) ~ $ sudo mount nnas:/home /mnt/nnas/home
deb1 (nikos) ~ $ ll /mnt/nnas/home
total 4
drwxr-xr-x 1 4294967294 4294967294   20 Sep  9 09:18 .
drwxr-xr-x 3 root       root       4096 Sep  8 13:01 ..
drwxr-xr-x 1 4294967294 4294967294    0 Sep  9 09:18 admin
drwxr-xr-x 1 4294967294 4294967294    0 Sep  6 23:33 nikos

I wonder if this can have something to do with the fact that I have been toggling between trying NFS with AD authentication and NFS with locally configured users.

I am right now unable to delete the /home/nikos directory :-(
It isn't even possible to delete while logged in as root over ssh.

Another update ---

I am able to at least access my local user share on the NAS now. I use the Caja File Manager in Linux Mint-13 and the Path to a local user's share via SMB needs to include the protocol. So this path works for me: smb://<nas name>/<user name>. That opens the user's private share in the file manager. Caja does not support NFS.

I will experiment with other Linux File Mangers to see of maybe one supports NFS to my liking. SMB gets me access to the share, but you don't retain file permissions.