Re: NFS cache permissions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/12/2009 11:41 AM, Bruno Galindro da Costa wrote:
Hi yall,

Is it possible to clear the nfs cache permissions? I´m asking this
because I´ve made a NFS share with client access restrictions and the
users that have no more permissions, can still access the share.

The share has the following permissions (2770):

     drwxrws---  5 nobody vmail  1024 Nov 12 09:47 email

Only users that are within the vmail group can access the share. The
/etc/exports file has the following content (192.168.1.22 is the
client´s IP address):

      /mnt/vol0/email
192.168.1.22/255.255.255.255(rw,anonuid=5000,anongid=5000,secure,root_squash,wdelay,sync)

On the client, I´ve created a vmail group with the same UID of the
server (5000), and mounted the exported filesystem with the following
command (192.168.1.1 is the server´s IP address):

      mount -t nfs -o rsize=8192,wsize=8192  192.168.1.1:/mnt/vol0/email/ /email/

Right after executing the above command, I´ve added a user (abc) in
the vmail group and that user can access the share perfectly. So far
so god. BUT, when I remove that user from vmail group, logoff and
logon again, the user still has access to the share!
After unmounting and remounting the NFS filesystem, the user still has
the access!

Is this because the client computer has a NFS cache permissions? If
yes, how can I clear that cache?

PS.: After reading this - http://nfs.sourceforge.net/ - I´ve mounted
the share with the option "noac" to prevent client's file attribute
cache. But, it isn´t working.

Huh?  If you're the NFS server, you don't mount the share.  You export
a local directory and allow clients to mount that.  This is controlled
by the options you've specified in the /etc/exports file.

"noac" is specified at the _client_ during the mount (either the manual
mount command or one in the client's /etc/fstab), NOT at the server.
You can't force clients to not cache attributes.  Sorry.  In fact it's
a big load on both the client and server if they don't.  What you CAN
do at the server is control user/group IDs and access permissions to
the various things you export.  "man exports" for details.

If you are the server and you want to force the clients to remount to
recognize changes, usually you only need to change your options in the
/etc/exports file, then re-export the shares on the server:

	# exportfs -ra

If you want absolutely pristine stuff, you can execute the following
steps.

1. Unexport ALL shares:

	# exportfs -au

2. Make your changes to /etc/exports

3. Stop the nfs daemons:

	# service nfslock stop;service nfs stop

4. Delete state info:

	# rm -f /var/lib/nfs/state
	# rm -f /var/lib/nfs/etab*
	# rm -f /var/lib/nfs/rmtab*

5. Wait a bit to make sure the clients time out

6. Restart the nfs daemons:

	# service nfs start;service nfslock start

7. Finally, re-export the shares:

	# exportfs -ar

Hopefully the clients will have timed out and will remount.  They
should see the new restrictions at that time.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks@xxxxxxxx -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-     I was married by a judge.  I should have asked for a jury.     -
-                                                   -- Groucho Marx  -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux