On Mon, Aug 13, 2012 at 07:24:56PM +0530, Rajesh Ghanekar wrote: > Its no_subtree_check exported. > > Underneath filesystem (->permission) doesn't support capabilities and > hence EACCES is being returned. The filesystem is proprietary. > I figured it out later that they don't support capabilities. That sounds like a bug in their permission method. We won't be able to help with a proprietary filesystem here. --b. > > Thanks, > Rajesh > > > On Thu, Aug 9, 2012 at 11:42 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Thu, Aug 09, 2012 at 02:55:28AM +0530, Rajesh Ghanekar wrote: > >> Hi, > >> I am facing problem with reconnect_path failing with EACCES when doing > >> lookup_one_len. I have 2 users goind to same directory, one with uid=0 > >> and another with uid=xxx. Sometime for uid=0 request, nfsd is still is using > >> uid=xxx (as it was used previously), as uid=xxx doesn't have any permissions > >> on the directory. > >> > >> Should this probably do nfsd_setuser_and_check_port before > >> the below code in nfsd_set_fh_dentry()? As it carries older > >> fsuid and fsgid, can it create issues. This always happens > >> with disconnected dentries. > >> > >> if (exp->ex_flags & NFSEXP_NOSUBTREECHECK) { > >> /* Elevate privileges so that the lack of 'r' or 'x' > >> * permission on some parent directory will > >> * not stop exportfs_decode_fh from being able > >> * to reconnect a directory into the dentry cache. > >> * The same problem can affect "SUBTREECHECK" exports, > >> * but as nfsd_acceptable depends on correct > >> * access control settings being in effect, we cannot > >> * fix that case easily. > > > > Are you exporting with subtree_check or no_subtree_check? (What does > > "exportfs -v" say?) > > > > In the no_subtree_check case, the cap_raise_nfsd_set() is intended to > > override file permissions, so the uid and gid shouldn't matter. > > > > --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html