LinuxQuestions.org - Mounted NFS share denies access to subdirectories

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - Mounted NFS share denies access to subdirectories (https://www.linuxquestions.org/questions/linux-server-73/mounted-nfs-share-denies-access-to-subdirectories-588689/)

Mounted NFS share denies access to subdirectories

Hi all, I'm still learning the ins and outs of Linux. Right now I'm having a bit of a problem with NFS. I'm trying to access a media share called "storage" which I have setup on my main machine running Sabayon 3.4.

The NFS share mounts without complaint, but then if I do a directory listing on the mount point, I get this:

Code:

$ ls -l /mnt/storage/

total 0

?--------- ? ? ? ?            ? /mnt/storage/backup

?--------- ? ? ? ?            ? /mnt/storage/dvd

?--------- ? ? ? ?            ? /mnt/storage/linux

?--------- ? ? ? ?            ? /mnt/storage/music

?--------- ? ? ? ?            ? /mnt/storage/recordings

?--------- ? ? ? ?            ? /mnt/storage/video

It can see all the subdirectories (which is where all the actual content is), but trying to ls or cd into any of them returns

Code:

$ ls /mnt/storage/music

ls: /mnt/storage/music: Permission denied



$ cd /mnt/storage/music

bash: cd: /mnt/storage/music: Permission denied

Is this a server/client UID problem? If so, what do I need to do to enable access to this share? My /etc/exports reads:

Code:

/media/storage 192.168.1.0/255.255.255.0(ro)

Which as far as I know should give access to "storage" to everyone on my home network.

/etc/hosts.deny is denying ALL on portmap, lockd, mountd, rquotad, and statd.

/etc/hosts.allow reads ALL:192.168.1.0/255.255.255.0

The server machine is running Sabayon 3.4, and the client in question has Fedora Core 5.

If anyone can shed any light on this, it would be appreciated. And if there's any information I omitted which would be helpful, please let me know and I will provide it.

the uid/gid (numerical values!) have to match for client/server

--> use chown to change the uid/gid on the server or client as needed.

Quote:

Originally Posted by rtspitz (Post 2909815)

the uid/gid (numerical values!) have to match for client/server

--> use chown to change the uid/gid on the server or client as needed.

Okay, so in other words, if UID 1000, GID 0 owns the storage share on the server end, then in order to access the share from the client, I need to change the actual UID:GID of the client to 1000:0 (like in /etc/passwd)? Or do I just chown the share on the client end to these numerical values?

There are a number of ways of dealing with this problem. The simplest, though possibly inconvenient, way is to make sure that all computers have matching uids and gids. It's also possible to use uid mapping though, through the use of ugidd, some kind of static map, or LDAP. You can read a bit more about these methods here.

All right, so I used usermod -u to change the UID/GID of the main user on the client to 1000:0 (to match the owner of the share on the server). Nothing seems to have changed.

EDIT: Also tried using the map_daemon option in my /etc/exports file as per your link Gethyn, which also doesn't seem to have changed anything. Do I need to be setting up the daemon elsewhere so that ugidd will work?

you cannot (and should not) change the share from the client, as it is set read-only on the server.
basically you need to make sure that users on your client have numerical user-ids that match the ones on your server. that is text names like 'users' don't matter!

example dir on the server ('ls -n'):

drwxrwxr-x 40 1000 100 4096 2007-10-02 17:02 my-home-dir

this folder is owned by some user with user-id: 1000 and group-id: 100

for users on the client machine to get access they need to be in a group on the client with a numerical id of 1000. those numbers can be set during group/user creation. this also poses some security issue, as anybody with root access on some nfs client can switch those numbers as desired - and gain root access to that share !

that's why you should always use something like this:

/media/storage 192.168.1.0/255.255.255.0(ro,root_squash)

oops. a bit late :-)

are all daemons running ? portmap ?

Quote:

Originally Posted by rtspitz (Post 2910633)

are all daemons running ? portmap ?

rpcinfo returns that portmapper and nfs processes are running on both machines. Should I be looking for something specific to make sure "map_daemon" is running?

The share on the server (which is owned by user "luke"):

Code:

$ cat /etc/passwd | grep luke

luke:x:1000:0:Luke,,,:/home/luke:/bin/bash



$ ls -n /media/storage

total 40

drwxrwxr--  3 1000 0  4096 2007-09-11 02:57 backup

drwxrwxr--  9 1000 0  4096 2007-09-29 10:25 dvd

drwxrwxr--  9 1000 0  4096 2007-07-05 09:05 linux

drwxrwxr--  6 1000 0  4096 2007-09-26 09:04 music

drwxrwxr-- 15 1000 0 12288 2007-09-26 09:16 recordings

drwxrwxr--  5 1000 0 12288 2007-09-28 06:48 video

The mount directory on the client (being accessed by user "jukebox"):

Code:

$ cat /etc/passwd | grep jukebox

jukebox:x:1000:0::/home/jukebox:/bin/bash



$ ls -n /mnt/

total 4

drwxrwxr-- 8 1000 0 4096 Sep 26 04:30 storage



$ ls -n /mnt/storage

total 0

?--------- ? ? ? ?            ? /mnt/luke/storage/backup

?--------- ? ? ? ?            ? /mnt/luke/storage/dvd

?--------- ? ? ? ?            ? /mnt/luke/storage/linux

?--------- ? ? ? ?            ? /mnt/luke/storage/music

?--------- ? ? ? ?            ? /mnt/luke/storage/recordings

?--------- ? ? ? ?            ? /mnt/luke/storage/video

As you can see, the UID/GIDs now match, yet I still can't read the storage share from the client machine.

Figured it out.

The permissions on the /storage directory were set incorrectly. :p I did a chmod -r 755 and now everything works just fine.

Thank you all for your help!