Re: NFS cache permissions

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

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux