All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Ward <matthew.ward@fubra.com>
To: linux-nfs@vger.kernel.org
Subject: Issue with NFS and LDAP, attribute caching with "Permission denied"
Date: Thu, 07 Jul 2011 15:40:21 +0100	[thread overview]
Message-ID: <4E15C555.9030002@fubra.com> (raw)

Hi all,

I'm having a particular issue with NFS and LDAP permissions causing 
"Permission denied" when trying to access directories where my apache 
user is a member of another's group, and there seems to be some kind of 
caching of permissions that are stopping me from getting into 
directories until the NFS server is restarted. I've tried reducing 
attribute caching timeouts as well as turning attribute caching off with 
noac, which help to alleviate the problem on the client side but still 
require a restart of NFS on the server side otherwise there is a long 
(up to 15 minute) wait. The setup is as follows:

1) A random user and group are added to LDAP on the LDAP server, for 
example `matt`
2) `apache` is added as a memberUid to the group `matt` so that `apache` 
has access to everything that the `group` matt can read
3) Checking the groups for the `apache` user on the client shows it's a 
member of the `matt` group
4) Trying to access directories that are group-read/executable to `matt` 
(drwxr-x---) from `apache` produces "Permission denied"
5) Restarting the NFS server then allows the `apache` user to access the 
`matt`-owned directory

Originally, we didn't have the noac option on the client-side mount and 
even after restarting the NFS server it would still be anywhere between 
30 seconds and 15 minutes before the `apache` user had access to the 
directory, but since turning on noac (or reducing actimeo to something 
small) means that after an NFS server restart we're able to use `apache` 
to access the directory straight away.

I'm just wondering if there's some sort of cache on the server side that 
also needs to be reduced so that we don't have to restart the NFS server 
to avoid the 15 minute wait as well?

NFS-specific files and commands are as follows

/etc/exports (on the server):
-----------------------------
/my/shared/dir x.x.x.x(rw,nohide,insecure,no_subtree_check,async)

/etc/fstab (on the client):
---------------------------
x.x.x.x:/my/shared/dir /my/shared/dir nfs defaults,noatime,actimeo=1 1 1

commands on the client (as the `apache` LDAP user):
---------------------------------------------------
$ whoami
apache
$ groups
apache matt
$ cd /my/shared/dir
$ ls -l
drwxr-s--- 7 matt matt 4096 Jul 6 16:56 matt
$ ls -a matt
ls: cannot open directory matt: Permission denied
(RESTART NFS SERVER)
$ ls -a matt
. ..
$

============
Matthew Ward
Web and Mobile Application Developer
Fubra Limited

w: www.fubra.com
e: matthew.ward@fubra.com

------------------------------

Fubra is a company limited by shares and registered in England and
Wales with number 3967214 at Anstey Park House, Anstey Road,
Alton, Hampshire, GU34 2RL. We are registered for VAT with number
GB733667024, and as a data controller with number Z5193400.
We are members of RIPE, Nominet, The Italian RA and registered
with OfCom as a provider of electronic communications services.


             reply	other threads:[~2011-07-07 14:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07 14:40 Matthew Ward [this message]
2011-07-07 15:10 ` Issue with NFS and LDAP, attribute caching with "Permission denied" Matthew Ward

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E15C555.9030002@fubra.com \
    --to=matthew.ward@fubra.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.