September 2018 - Devel - NFS Ganesha List Archives

Change in ffilz/nfs-ganesha[next]: SAL: add EXPORT_OPTION_SECLABEL_SET
by GerritHub 26 Sep '18

26 Sep '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426933 Change subject: SAL: add EXPORT_OPTION_SECLABEL_SET ...................................................................... SAL: add EXPORT_OPTION_SECLABEL_SET Add a new generic export option to enable security labels on a per-export basis. The default is to have them disabled. Signed-off-by: Jeff Layton <jlayton(a)redhat.com> Change-Id: If75ed7722efedb1a296cb197c1a152e0fc1d295b Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/include/nfs_exports.h M src/support/exports.c 2 files changed, 5 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/33/426933/1 -- To view, visit https://review.gerrithub.io/426933 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If75ed7722efedb1a296cb197c1a152e0fc1d295b Gerrit-Change-Number: 426933 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Change in ffilz/nfs-ganesha[next]: mdcache: do readdir cb supercall using entry->attrs
by GerritHub 26 Sep '18

26 Sep '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426925 Change subject: mdcache: do readdir cb supercall using entry->attrs ...................................................................... mdcache: do readdir cb supercall using entry->attrs mdc_readdir_uncached_cb will update the mdcache first, and then do the supercall with the old attributes. When updating the cache though, we might "steal" some of the pointers in "attrs", which could make us populate the reply from an incomplete set of attrs. Use the attrs in the mdcache instead. Change-Id: If2e3b7e9de1f496c96ad2cb29552318e33626c61 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c 1 file changed, 3 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/25/426925/1 -- To view, visit https://review.gerrithub.io/426925 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If2e3b7e9de1f496c96ad2cb29552318e33626c61 Gerrit-Change-Number: 426925 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Nfs-ganesha with openldap and kerberos
by Durgaprasad Dandi 25 Sep '18

25 Sep '18

Hello, These are my system configuration. CentOS Linux release 7.3.1611 Linux 3.10.0-514.el7.x86_64 kernel nfs-ganesha-2.3.2-1.el7.x86_64 libnfsidmap-0.25-19.el7.x86_64 I am trying to use nfs-ganesha with openldap and kerberos. In the client, I am using autofs to mount the home directories of the users. Logging as a user in the client is failing with following error >>Could not chdir to home directory /home/demouser2: Permission denied >>-bash: /home/demouser2/.bash_profile: Permission denied Nfs-ganesha logs: 25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6] nfs_req_creds :DISP :M_DBG :Mapping RPCSEC_GSS principal demouser2(a)DMS.COM to uid/gid 25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6] principal2uid :RW LOCK :F_DBG :Got read lock on 0x7f92c10e6380 (&idmapper_user_lock) at /builddir/build/BUILD/nfs-ganesha-2.3.2/src/idmapper/idmapper.c:662 25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6] principal2uid :RW LOCK :F_DBG :Unlocked 0x7f92c10e6380 (&idmapper_user_lock) at /builddir/build/BUILD/nfs-ganesha-2.3.2/src/idmapper/idmapper.c:667 25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6] nfs_req_creds :ID MAPPER :WARN :Could not map principal demouser2(a)DMS.COM to uid If I am using nfs, everything is working properly. So why this issue is only with nfs-ganesha? Am I doing something wrong in configuration? nfs-ganesha configuration file : /etc/ganesha/ganesha.conf NFSV4 { IdmapConf = /etc/idmapd.conf; Allow_Numeric_Owners = false; } EXPORT { # Export Id (mandatory, each EXPORT must have a unique Export_Id) Export_Id = 77; # Exported path (mandatory) Path = /home; # Pseudo Path (required for NFS v4) Pseudo = /home; # Required for access (default is None) # Could use CLIENT blocks instead Access_Type = RW; SecType = sys, krb5; # Exporting FSAL FSAL { Name = VFS; } CLIENT { Clients = client; Squash = No_root_squash; } NFS_KRB5 { PrincipalName = "nfs" ; KeytabPath = /etc/krb5.keytab ; Active_krb5 = YES ; } } Thanks, Durga.

1 1

Re: [Nfs-ganesha-devel] Issue with file locks after upgrade from 2.5.4 to 2.6.2
by Naresh Babu 24 Sep '18

24 Sep '18

Thanks for the response, Daniel. Ping to "::ffff:10.0.0.7" works fine. Do you suspect anything else? Thanks, Naresh On Tue, Sep 11, 2018 at 5:48 AM Daniel Gryniewicz <dang(a)redhat.com> wrote: > My guess is that this is related to IPv6. IPv6 support in 2.5 was > spotty, but that's been fixed since. It's clearly using the 4-in-6 > address (pretty common on a v6 enabled machine), and I don't believe it > could have used that in 2.5, so that's seems the smoking gun. > > Does IPv6 work on your system? If you ping ::ffff:10.0.0.7 on that box, > does it work? If the problem is IPv6, you may be able to work around it > by preferring IPv4 to IPv6. This is done by adding this line to > /etc/gai.conf: > > precedence ::ffff:0:0/96 100 > > Daniel > > On 09/11/2018 03:42 AM, Naresh Babu wrote: > > This list has been deprecated. Please subscribe to the new devel list at > lists.nfs-ganesha.org. > > > > > > > > We have developed a custom FSAL on top of nfs-ganesha 2.5.4 version and > > lock tests ran fine with that. But, after upgrading nfs-ganesha to > > 2.6.2, lock tests are failing with the following errors: > > > > ganesha.nfsd-1419[svc_70] nsm_monitor :NLM :CRIT :Monitor > > ::ffff:10.0.0.7 SM_MON failed (1) > > > > /var/log/messages: > > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: SM_MON/SM_UNMON call from > > non-local host ::1 > > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: STAT_FAIL to mbclvm3 for SM_MON > > of ::ffff:10.0.0.7 > > > > $ rpcinfo -p |grep "status\|lockmgr" > > 100024 1 udp 46991 status > > 100024 1 tcp 33715 status > > 100021 4 udp 45075 nlockmgr > > 100021 4 tcp 45075 nlockmgr > > > > > > > > > > _______________________________________________ > > Nfs-ganesha-devel mailing list > > Nfs-ganesha-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > > >

3 6

Change in ffilz/nfs-ganesha[next]: FSAL_CEPH: open file as root for COMMIT purposes
by GerritHub 24 Sep '18

24 Sep '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426589 Change subject: FSAL_CEPH: open file as root for COMMIT purposes ...................................................................... FSAL_CEPH: open file as root for COMMIT purposes Kenneth reported that he was seeing problems copying large, read only files to a share as an unprivileged user. The final COMMIT call would get back a permissions error. Since we don't have a stateid to use as a hint, we have to use the global fd to issue a commit. In many situations we won't have it open for write already, so we need to perform an open. If the file has gone r/o though, we can't do that with the creds sent in the RPC. Switch to using root creds for the when we're opening the file for a COMMIT call. We check the permissions at the protocol layer already and we're just using it to issue an fsync, so this should be safe. Fixes: https://github.com/nfs-ganesha/nfs-ganesha/issues/349 Change-Id: I60fba7ff05b3a5210d34e25f591256c9a1d61949 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/FSAL/FSAL_CEPH/handle.c 1 file changed, 10 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/89/426589/1 -- To view, visit https://review.gerrithub.io/426589 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I60fba7ff05b3a5210d34e25f591256c9a1d61949 Gerrit-Change-Number: 426589 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Change in ffilz/nfs-ganesha[next]: FSAL_MDCACHE: prevent double free on new raced entries
by GerritHub 24 Sep '18

24 Sep '18

From <fatih(a)gandi.net>: fatih(a)gandi.net has uploaded this change for review. ( https://review.gerrithub.io/426583 Change subject: FSAL_MDCACHE: prevent double free on new raced entries ...................................................................... FSAL_MDCACHE: prevent double free on new raced entries This is a partial revert of c55046feb786d69de8ba046e7cbd242479621b66. The newly acquired entry is actually in the LRU at this point, it is inserted in mdcache_alloc_handle. We should put the ref once and let the reaper do the rest, otherwise it may race with another thread (LRU thread/reaper). Change-Id: Ia548c842b79958deb6b895a0249ec0bb4cde65d2 Signed-off-by: Fatih Acar <fatih.acar(a)gandi.net> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c 1 file changed, 1 insertion(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/83/426583/1 -- To view, visit https://review.gerrithub.io/426583 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ia548c842b79958deb6b895a0249ec0bb4cde65d2 Gerrit-Change-Number: 426583 Gerrit-PatchSet: 1 Gerrit-Owner: Anonymous Coward <fatih(a)gandi.net>

1 0

Announce Push of V2.7.0.1
by Frank Filz 21 Sep '18

21 Sep '18

Branch next Tag:V2.7.0.1 Release Highlights * To handle open upgrade, attempt to open lock fd RDWR * FSAL_CEPH: add flag to mask for setting atime/mtime to server time * specfile: build with libasan support if it was specified during cmake * ganesha-rados-grace: only create pool and db on "add" * rpm: add lttng-tools-devel as BuildRequires to .spec file * CMake - Find libraries on Debian * FSAL GLUSTER: fix the result of SEEK2 according to RFC7862 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 0fe4db2 Frank S. Filz V2.7.0.1 b4c0a4f Kinglong Mee FSAL GLUSTER: fix the result of SEEK2 according to RFC7862 59fe3bd Daniel Gryniewicz CMake - Find libraries on Debian 4a11713 Ali Maredia rpm: add lttng-tools-devel as BuildRequires to .spec file 93b47c6 Jeff Layton ganesha-rados-grace: only create pool and db on "add" ee7bad6 Jeff Layton specfile: build with libasan support if it was specified during cmake 4a12680 Zhu Shangzhong FSAL_CEPH: add flag to mask for setting atime/mtime to server time baa858b Frank S. Filz To handle open upgrade, attempt to open lock fd RDWR

1 0

Change in ffilz/nfs-ganesha[next]: To handle open upgrade, attempt to open lock fd RDWR
by GerritHub 20 Sep '18

20 Sep '18

From Frank Filz <ffilzlnx(a)mindspring.com>: Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/426288 Change subject: To handle open upgrade, attempt to open lock fd RDWR ...................................................................... To handle open upgrade, attempt to open lock fd RDWR If that fails, then open in the openstate mode if available. Change-Id: I6c765b29d64d4d407feca99917ff0ec9b6516535 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/FSAL/commonlib.c 1 file changed, 21 insertions(+), 11 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/88/426288/1 -- To view, visit https://review.gerrithub.io/426288 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I6c765b29d64d4d407feca99917ff0ec9b6516535 Gerrit-Change-Number: 426288 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>

1 0

Change in ffilz/nfs-ganesha[next]: ganesha-rados-grace: only create pool and db on "add"
by GerritHub 20 Sep '18

20 Sep '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426263 Change subject: ganesha-rados-grace: only create pool and db on "add" ...................................................................... ganesha-rados-grace: only create pool and db on "add" The first thing we have to do with a new cluster is add members, so it doesn't make sense to create the pool or db unless we're doing that. Otherwise, the tool will create the pool and db, even if we're just dumping the current status. Also, clean up some unnecessary code duplication. We need at least one nodeid for all commands except for "dump" so just check that after we see if we're handling a dump command. Change-Id: Id6f72384a0fb4ae3e7286cad71fa8b8fda90607f Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/tools/ganesha-rados-grace.c 1 file changed, 40 insertions(+), 74 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/63/426263/1 -- To view, visit https://review.gerrithub.io/426263 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Id6f72384a0fb4ae3e7286cad71fa8b8fda90607f Gerrit-Change-Number: 426263 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Crash in mdcache_lru_cleanup_push()
by Sandeep Nashikkar 19 Sep '18

19 Sep '18

Ganesha Version: 2.5.1 Platform: Linux x86_64 I am seeing following issue while doing re-exporting the ganesha export (remove_export -> add_export) The crash happens during add_export operation and there are some applications using the export while this is happening. We also implemented mechanism to stall the IOs when this operation is happening but it did not help. Program terminated with signal 11, Segmentation fault. #0 0x0000000000530d27 in mdcache_lru_cleanup_push (entry=0x7f3078007f50) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:935 935 LRU_DQ_SAFE(lru, q); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-12.el7.x86_64 dbus-libs-1.10.24-7.el7.x86_64 elfutils-libelf-0.160-1.el7.x86_64 elfutils-libs-0.160-1.el7.x86_64 gssproxy-0.3.0-10.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-19.el7.x86_64 libacl-2.2.51-14.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libblkid-2.23.2-21.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-12.el7_5.x86_64 libgcrypt-1.5.3-12.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libnfsidmap-0.25-11.el7.x86_64 libselinux-2.5-12.el7.x86_64 libuuid-2.23.2-21.el7.x86_64 lz4-1.7.5-2.el7.x86_64 pcre-8.32-17.el7.x86_64 systemd-libs-219-57.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64 (gdb) bt #0 0x0000000000530d27 in mdcache_lru_cleanup_push (entry=0x7f3078007f50) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:935 #1 0x000000000054a0fc in _mdcache_kill_entry (entry=0x7f3078007f50, file=0x5a0970 "/root/rpmbuild/BUILD/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c", line=218, function=0x5a2120 <__func__.23400> "mdcache_alloc_handle") at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:3310 #2 0x00000000005419de in mdcache_alloc_handle (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, fs=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:218 #3 0x00000000005430ea in mdcache_new_entry (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, attrs_in=0x7f31287c6670, attrs_out=0x0, new_directory=false, entry=0x7f31287c67e8, state=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:590 #4 0x0000000000544093 in mdcache_locate_host (fh_desc=0x7f31287c6c60, export=0x7f30bc05d070, entry=0x7f31287c67e8, attrs_out=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:998 #5 0x000000000053d1b3 in mdcache_create_handle (exp_hdl=0x7f30bc05d070, fh_desc=0x7f31287c6c60, handle=0x7f31287c6c58, attrs_out=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1902 #6 0x000000000047729d in nfs4_mds_putfh (data=0x7f31287c6d60) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_op_putfh.c:211 #7 0x0000000000477486 in nfs4_op_putfh (op=0x7f30a00424c0, data=0x7f31287c6d60, resp=0x7f3078000d30) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_op_putfh.c:281 #8 0x000000000045f670 in nfs4_Compound (arg=0x7f30a00010f0, req=0x7f30a00008e8, res=0x7f3078001fa0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_Compound.c:743 #9 0x000000000044c20d in nfs_rpc_execute (reqdata=0x7f30a00008c0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1289 #10 0x000000000044ca17 in worker_run (ctx=0x1d88bf0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1561 #11 0x0000000000508a7a in fridgethr_start_routine (arg=0x1d88bf0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/support/fridgethr.c:550 #12 0x00007f31797f2df5 in start_thread (arg=0x7f31287c8700) at pthread_create.c:308 #13 0x00007f3178eb31ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 (gdb) p q $1 = (struct lru_q *) 0x0 (gdb) f 3 #3 0x00000000005430ea in mdcache_new_entry (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, attrs_in=0x7f31287c6670, attrs_out=0x0, new_directory=false, entry=0x7f31287c67e8, state=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:590 590 nentry = mdcache_alloc_handle(export, sub_handle, sub_handle->fs); (gdb) p export->flags $2 = 1 '\001' (gdb) p entry->lru $6 = {q = {next = 0x0, prev = 0x0}, qid = LRU_ENTRY_NONE, refcnt = 1, flags = 0, lane = 2, cf = 0} mdc_check_mapping () in following snippet returns error because MDC_UNEXPORT flag in export->flags is set. After an export is completely removed and ganesha_mgr remove_export command returned successfully, why do we see the flag set? The comment also says "The current export is in process to be unexported" /* Map the export before we put this entry into the LRU, but after it's * well enough set up to be able to be unrefed by unexport should there * be a race. */ status = mdc_check_mapping(result); if (unlikely(FSAL_IS_ERROR(status))) { /* The current export is in process to be unexported, don't * create new mdcache entries. */ LogDebug(COMPONENT_CACHE_INODE, "Trying to allocate a new entry %p for export id %" PRIi16" that is in the process of being unexported", result, op_ctx->ctx_export->export_id); mdcache_put(result); mdcache_kill_entry(result); return NULL; } The crash occurs because lru_queue_of() returns q = NULL due to entry->lru.qid = LRU_NO_LANE and LRU_DQ_SAFE refers to q. Is there any deferred work during unexport in mdcache FSAL? If we add delay between remove_export and add_export, I did not see the problem. But that does not seem to be elegant solution. Please help me understand if there are any limitations from mdcache with respect to back to back unexport and export operation. Thanks, Sandeep ***************************Legal Disclaimer*************************** "This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you." **********************************************************************

3 4