Rick, thankyou for your anwser. > 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. I know this. I gess I didn´t express myself quite well. Is there any other solution for this problem where it isn´t necessary to re-export the shares? 2009/11/12 Rick Stevens <ricks@xxxxxxxx>: > On 11/12/2009 11:41 AM, Bruno Galindro da Costa wrote: >> >> Hi yall, >> >> Is it possible to clear the nfs cache permissions? I惴 asking this >> because I扉e 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愀 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扉e 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愀 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扉e 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扉e mounted >> the share with the option "noac" to prevent client's file attribute >> cache. But, it isn愒 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 > -- Att. Bruno Galindro da Costa bruno.galindro@xxxxxxxxx Florianópolis - SC -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
