[Nfs-ganesha-devel] 2.5 Ganesha with extended API crash

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org.Hi, We seen one crash with below stack trace. And core dump was not not enabled so i couldn't pin point the issue. But crash may be because of below reason and it is my hunch. Is this seen before in any

Re: [Nfs-ganesha-devel] ACE permission check

You may decide this scenario is unlikely and not worry, but it’s the > ultimate reason we deferred to the filesystem for permission checks of > directory operations. > > > > Also, the locking of multiple objects is hard to do correctly to avoid > deadlock… > > > &

Re: [Nfs-ganesha-devel] ACE permission check

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org.Frank/Daniel, Creds are correct, ACL implementation in our FSAL is new, basic RWX permission is enforced in our FSAL on this path. Currently ACL's are not enforced in our Filesystem. We are relying on

[Nfs-ganesha-devel] ACE permission check

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org. Hi, By looking at nfs-Ganesha code, permission check (ACL) happens access_check.c. Our FSAL (not in tree FSAL), storing and serving the ACLs to Ganesha. I see an issue with rename: Even though i set d

[Nfs-ganesha-devel] ACE permission check

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org.Hi, By looking at nfs-Ganesha code, permission check (ACL) happens access_check.c. Our FSAL (not in tree FSAL), storing and serving the ACLs to Ganesha. I see an issue with rename: Even though i set de

Re: [Nfs-ganesha-devel] ACL support

Hi, Kernel nfs reorders the ACE in ACL and i think it puts more restrictive ACEs first in the list. But i see NFS Ganesha is not doing it,is reordering the responsibility of FSAL ? Is there any plans to support reordering ? Thanks, Sagar. On Mon, Feb 19, 2018 at 11:43 AM, Sagar M D wrote

Re: [Nfs-ganesha-devel] ACL support

You can > find these commands in nfs4-acl-tools package. > > > > - Sriram > > > > *From: *Sagar M D > *Date: *Friday, February 16, 2018 at 3:20 PM > *To: *Supriti Singh > *Cc: *"nfs-ganesha-devel@lists.sourceforge.net" sourceforge.net> > *Subje

Re: [Nfs-ganesha-devel] ACL support

>fsal_check_access_acl. > > > > - Sriram > > > > *From: *Frank Filz > *Date: *Friday, February 16, 2018 at 8:19 PM > *To: *Sriram Patil , 'Sagar M D' , > 'Supriti Singh' > *Cc: *"nfs-ganesha-devel@lists.sourceforge.net" sou

Re: [Nfs-ganesha-devel] ACL support

; } } Thanks, Sagar. On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D wrote: > Supriti, > > We are testing our own FSAL. > > Thanks, > Sagar. > > > On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh > wrote: > >> Hi Sagar, >> >> Which FSAL ar

Re: [Nfs-ganesha-devel] ACL support

rton, > HRB 21284 (AG Nürnberg) > > >>> Sagar M D 02/16/18 9:15 AM >>> > Hi, > > We are setting below value in our EXPORT block to enable ACL. > *Disable_ACL = FALSE;* > > However when try to do any ACL operation it throws get below error:- > > *Operation to re

[Nfs-ganesha-devel] ACL support

Hi, We are setting below value in our EXPORT block to enable ACL. *Disable_ACL = FALSE;* However when try to do any ACL operation it throws get below error:- *Operation to request attribute not supported.Failed to instantiate ACL.* On further analysis, i found that getattr call on our fsal exp

Re: [Nfs-ganesha-devel] owner and group issue.

ity is being deprecated so your FSAL > would need to be converted to support_ex if you wish to migrate to newer > Ganesha (and there will be lots of reasons to migrate to V2.6 and later as > we move forward). > > > > Frank > > > > *From:* Sagar M D [mailto:sagar...@g

Re: [Nfs-ganesha-devel] owner and group issue.

> open2() call? > > Daniel > > > On 02/08/2018 05:15 AM, Sagar M D wrote: > >> Hi, >> >> We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file >> have -2 has owner and group even though root is created the file and >> no_root_

[Nfs-ganesha-devel] owner and group issue.

Hi, We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file have -2 has owner and group even though root is created the file and no_root_squash is enabled. I see this behavior for only for short duration that to right after ganesha restarts. During file creation, our fsal gets co

[Nfs-ganesha-devel] MNT3ERR_ACCESS vs MNT3ERR_NOTSUPP

*Hi All,In * *mnt_Mnt function, I see if the share is exported with only v4 and clients try to mount using v3 then "access denied by server" error is returned to client from the server. I feel "*MNT3ERR_NOTSUPP" should be retur

Re: [Nfs-ganesha-devel] lock_op

he opaque void * lock owner is also still available). > > > > I hope that helps, > > > > Frank > > > > *From:* Sagar M D [mailto:sagar...@gmail.com] > *Sent:* Wednesday, September 7, 2016 3:37 PM > *To:* nfs-ganesha-devel@lists.sourceforge.net > *Subject:* [Nf

[Nfs-ganesha-devel] lock_op

Hi All, could someone please shed light on the usage of "owner" in fsal side ? Is "owner" implemented as comments says "it is not yet". Also "owner" looks opaque to FSAL. Will NFS-Ganesha expects this back in any call ? how fsal should use this "owner" ? /** * @brief Perform a lock opera