Hello We are seeing issue as following: 1. We are using our own FSAL with ganesha version 2.8.2 which eventually performs operation on underlying storage through a wrapper layer. 2. We perform add_export programmatically when required. When add_export command tries to lstat, sometimes the underlying storage takes time to return the attributes. Here is the stack where it gets stuck for some time: #5 0x00007fdc9d24ea0f in lookup_path () from /usr/lib64/ganesha/libfsaltdfs.so #6 0x000000000053f719 in mdcache_lookup_path (exp_hdl=0x7fdbfa43d900, path=0x7fdbfa40f200 "/Chk1234", handle=0x7fdbfc0daac8, attrs_out=0x0) at /usr/src/debug/nfs-gan esha-2.6.3/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1697 #7 0x0000000000504454 in init_export_root (export=0x7fdbfa435448) at /usr/src/debug/nfs-ganesha-2.6.3/support/exports.c:2253 #8 0x00000000005029c2 in export_commit_common (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160, commit_type=add_export) at /us r/src/debug/nfs-ganesha-2.6.3/support/exports.c:1235 #9 0x0000000000502e27 in add_export_commit (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.6 .3/support/exports.c:1351 #10 0x000000000055832b in proc_block (node=0x7fdbfa4331a0, item=0x7e51a8 <add_export_param+8>, link_mem=0x0, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2. 6.3/config_parsing/config_parsing.c:1362 #11 0x0000000000559116 in load_config_from_node (tree_node=0x7fdbfa4331a0, conf_blk=0x7e51a0 <add_export_param>, param=0x0, unique=false, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.6.3/config_parsing/config_parsing.c:1862 #12 0x0000000000518d42 in gsh_export_addexport (args=0x7fdbfc0db220, reply=0x7fdc97bf5180, error=0x7fdbfc0db270) at /usr/src/debug/nfs-ganesha-2.6.3/support/export_mg r.c:1038 #13 0x000000000055330b in dbus_message_entrypoint (conn=0x7fdc97aaa0c0, msg=0x7fdbfa42a440, user_data=0x7e5ff0 <export_interfaces>) at /usr/src/debug/nfs-ganesha-2.6. 3/dbus/dbus_server.c:564 #14 0x00007fdc9ca50276 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3 #15 0x00007fdc9ca41b29 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #16 0x00007fdc9ca41e42 in _dbus_connection_read_write_dispatch () from /lib64/libdbus-1.so.3 #17 0x0000000000553ed9 in gsh_dbus_thread (arg=0x0) at /usr/src/debug/nfs-ganesha-2.6.3/dbus/dbus_server.c:796 #18 0x00007fdc9b429e25 in start_thread () from /lib64/libpthread.so.0 #19 0x00007fdc9aae6bad in clone () from /lib64/libc.so.6 1. Despite the lstat getting stuck, add_export command returns prematurely in 30-40 seconds or so and return code is success. This is not expected. 2. This causes subsequent mount to fail since the export is not actually ready for the mount (init_export_root not being complete) Can someone help here to understand why dbus interface returns success? Is this known issue? How can we fix this behavior? Can we rather have a library interface to create/delete/update exports rather than relying on ganesha_mgr python script and dbus interface? Thanks Sandeep