NFS cache permissions
Bruno Galindro da Costa
bruno.galindro at gmail.com
Fri Nov 13 11:13:10 UTC 2009
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 at nerd.com>:
> 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 at nerd.com -
> - 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 at redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>
--
Att.
Bruno Galindro da Costa
bruno.galindro at gmail.com
Florianópolis - SC
More information about the fedora-list
mailing list