Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu User (http://www.linux-archive.org/ubuntu-user/)
-   -   NFS cache permissions (http://www.linux-archive.org/ubuntu-user/279359-nfs-cache-permissions.html)

Bruno Galindro da Costa 11-12-2009 12:06 PM

NFS cache permissions
 
Hi yall,

Is it possible to clear the nfs cache permissions? Im asking this because Ive 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 clients IP address):


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


On the client, Ive 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 servers IP address):

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


Right after executing the above command, Ive 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/ - Ive mounted the share with the option "noac" to prevent client's file
attribute cache. But, it isnt working.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Steve Flynn 11-12-2009 01:24 PM

NFS cache permissions
 
On Thu, Nov 12, 2009 at 1:06 PM, Bruno Galindro da Costa
<bruno.galindro@gmail.com> wrote:

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

I don't recall what the Linux mount command defaults the NFS version
to - please retest after mounting the export under version 3 or
version 4. You can do this by specifying vers=3 or nfsvers=3 (or 4) on
the mount command.

The fact that you specifically request a read and write size of 8k
(the default for v2) implies that you might have a requirement to only
handle version 2... is this the case?


--
Steve
When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Bruno Galindro da Costa 11-12-2009 03:16 PM

NFS cache permissions
 
> I don't recall what the Linux mount command defaults the NFS version
> to - please retest after mounting the export under version 3 or
> version 4. You can do this by specifying vers=3 or nfsvers=3 (or 4) on
> the mount command.

Ive tried these:

# mount -t nfs4 192.168.1.1:/mnt/vol0/email/ /email/
mount.nfs4: mounting 192.168.1.1:/mnt/vol0/email/ failed, reason given
by server:
No such file or directory

# mount -t nfs -o vers=4 192.168.1.1:/mnt/vol0/email/ /email/
mount.nfs: an incorrect mount option was specified

# mount -t nfs -o nfsvers=4 192.168.1.1:/mnt/vol0/email/ /email/
mount.nfs: an incorrect mount option was specified

I think my server doesnt support nfsv4. Reading the /proc/mounts,
Ive noticed that other mount points (mounted with shares of the same
server) use nfs version 3.

# cat /proc/mounts
<other mount point>
.
.
192.168.1.1:/mnt/vol0/share/ /share nfs
rw,relatime,vers=3,rsize=262144,wsize=262144,hard, nointr,proto=tcp,timeo=600,retrans=2,sec=sys,addr= 192.168.1.1
0 0

These mount points are mounted with this following command. This means
that both client and server are negotiating (by default) a nfs version
3.

# mount -t nfs 192.168.1.1:/mnt/share /share


> The fact that you specifically request a read and write size of 8k
> (the default for v2) implies that you might have a requirement to only
> handle version 2... is this the case?

No no. Ive added that options because it provides more performance
with nfs2 (I dont remember where Ive found this information). This
option can be removed without problems to my case.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Bruno Galindro da Costa 11-12-2009 06:41 PM

NFS cache permissions
 
Hi yall,

Is it possible to clear the nfs cache permissions? Im asking this
because Ive 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
clients IP address):

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

On the client, Ive 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 servers IP address):

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

Right after executing the above command, Ive 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/ - Ive mounted
the share with the option "noac" to prevent client's file attribute
cache. But, it isnt working.

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

Rick Stevens 11-12-2009 08:12 PM

NFS cache permissions
 
On 11/12/2009 11:41 AM, Bruno Galindro da Costa wrote:

Hi yall,

Is it possible to clear the nfs cache permissions? Im asking this
because Ive 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
clients IP address):

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

On the client, Ive 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 servers IP address):

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

Right after executing the above command, Ive 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/ - Ive mounted
the share with the option "noac" to prevent client's file attribute
cache. But, it isnt 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@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@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Bruno Galindro da Costa 11-13-2009 10:13 AM

NFS cache permissions
 
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@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,secur e,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@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@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@gmail.com
Florianópolis - SC

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


All times are GMT. The time now is 09:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.