March 2021 - Devel - NFS Ganesha List Archives

Change in ...nfs-ganesha[next]: Allow EXPORT pseudo path to be changed during export update
by Frank Filz (GerritHub) 20 Feb '24

20 Feb '24

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 ) Change subject: Allow EXPORT pseudo path to be changed during export update ...................................................................... Allow EXPORT pseudo path to be changed during export update This also fully allows adding or removing NFSv4 support from an export since we can now handle the PseudoFS swizzing that occurs. Note that an explicit PseudoFS export may be removed or added, though you can not change it from export_id 0 because we currently don't allow changing the export_id. Note that this patch doesn't handle DBUS add or remove export though that is an option to improve. I may add them to this patch (it wouldn't be that hard) but I want to get this reviewed as is right now. There are implications to a client of changing the PseudoFS. I have tested moving an export in the PseudoFS with a client mounted. The client will be able to continue accessing the export, though it may see an ESTALE error if it navigates out of the export. The current working directory will go bad and the pwd comment will fail indicating a disconnected mount. I have also seen referencing .. from the root of the export wrapping around back to the root (I believe this is how disconnected mounts are set up). FSAL_PSEUDO lookups and create handles (PUTFH or any use of an NFSv3 handle where the inode isn't cached) which fail during an export update are instead turned into ERR_FSAL_DELAY which turns into NFS4ERR_DELAY or NFS3ERR_JUKEBOX to force the client to retry under the completed update. Change-Id: I507dc17a651936936de82303ff1291677ce136be Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/FSAL/FSAL_PSEUDO/handle.c M src/MainNFSD/libganesha_nfsd.ver M src/Protocols/NFS/nfs4_pseudo.c M src/include/export_mgr.h M src/include/nfs_proto_functions.h M src/support/export_mgr.c M src/support/exports.c 7 files changed, 560 insertions(+), 203 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/34/490334/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I507dc17a651936936de82303ff1291677ce136be Gerrit-Change-Number: 490334 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-MessageType: newchange

2 2

Monitoring in Ganesha?
by Bjorn Leffler 22 Nov '21

22 Nov '21

Apart from the counters that you can access through dbus, is there any other monitoring built into Ganesha? I'm thinking of adding it with this higher level plan: - Exporting metrics from Ganesha to Prometheus. - Aggregate data in Prometheus. - Display monitoring consoles and graphs with Grafana. - Package up Prometheus, Grafana and the preconfigured rules/dashboards as a Docker image. - This makes it straightforward to deploy monitoring alongside a Gansha binary. My rough coding plan for the code is to: - Add a USE_MONITORING directive to the CMakeLists.txt files. - Add a build dependency to the Prometheus C client <https://github.com/digitalocean/prometheus-client-c>. - Create a src/monitoring directory for the new source files and templates. - Increment counters and timers throughout the code. - Use histograms to compute latency percentiles, heatmaps, etc. Is this a good idea? Any objections or suggestions? Thanks, Bjorn

3 6

connection fd in CLOSE_WAIT state
by gaurav gangalwar 29 Mar '21

29 Mar '21

Hi, I am using nfs4.1 mount with nconnect=16 from linux client (kernel 5.8.6-2.el7.elrepo.x86_64) I am facing mount hung if client is idle for sometime after running read/write IO. From netstat I could see, one of client connection in CLOSE_WAIT on server and FIN_WAIT2 on client. On debugging further I found out that if there is back channel client created on same client xprt then we won’t be able to close socket fd on connection reset from client, since there will be ref from rpc clnt, xprt will be released when reaper thread does client id expiry and do clnt destroy. I can see in logs client is keep on updating the lease and reaper is always getting valid lease for client and not expiring it. I am not sure if its due to multiple connections using nconnect due to some bug in client code, I have not seen this issue without nconnect. In nfs_rpc_create_chan_v41 we will create rpc_client on same xprt fd to create back channel on same connection, this will take ref on xprt for the rpc client. We cannot release this ref until rpc client is destroyed so fd will be open even if client has closed the connection. Client is updating the lease and reaper is always getting valid lease. Update lease from client: 25/03/2021 08:55:40 : epoch 605c1d45 : rbt-el7-2 : ganesha.nfsd-109993[svc_1630] nfs4_op_sequence :CLIENT ID :F_DBG :Don’t use sesson slot 1=0x7fa0c3c9ee38 for DRC 25/03/2021 08:55:40 : epoch 605c1d45 : rbt-el7-2 : ganesha.nfsd-109993[svc_1630] update_lease :CLIENT ID :F_DBG :Update Lease 0x7fa0bf813d00 ClientID={Epoch=0x605c1d45 Counter=0x0000002a} CONFIRMED Client={0x7fa0bf834630 name=(23:Linux NFSv4.1 rbt-el7-1) refcount=1} t_delta=0 reservations=0 refcount=2 Reaper check: 25/03/2021 08:56:22 : epoch 605c1d45 : rbt-el7-2 : ganesha.nfsd-109993[reaper] reaper_run :CLIENT ID :DEBUG :Now checking NFS4 clients for expiration 25/03/2021 08:56:22 : epoch 605c1d45 : rbt-el7-2 : ganesha.nfsd-109993[reaper] valid_lease :CLIENT ID :F_DBG :Check Lease 0x7fa0bf813d00 ClientID={Epoch=0x605c1d45 Counter=0x0000002a} CONFIRMED Client={0x7fa0bf834630 name=(23:Linux NFSv4.1 rbt-el7-1) refcount=1} t_delta=1 reservations=0 refcount=2 (Valid=YES 59 seconds left) Can we destroy the rpc client while destroying svc xprt? these back channel clients won't required since connection is closed by client. Regards, Gaurav

3 2

No community meeting next week (3/23) no merge either
by Frank Filz 19 Mar '21

19 Mar '21

I will be on vacation at the beach. Everyone have a good week. Frank

1 0

Announce Push of V4-dev.55
by Frank Filz 19 Mar '21

19 Mar '21

Branch next Tag:V4-dev.55 Merge Highlights * Patches to bring xattr up to speed with RFC 8276 * CEPH: implement and enable xattr * build: fixup perms on (/var)/run/ganesha Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 21f0535 Frank S. Filz V4-dev.55 0455e7e Kaleb S. KEITHLEY build: fixup perms on (/var)/run/ganesha e941efb Jeff Layton FSAL_CEPH: enable XATTR support c312f65 Jeff Layton FSAL_CEPH: plumb in xattr handling 91aad68 Jeff Layton FSAL: add a new listxattr helper routine 1765780 Jeff Layton NFS: fix up handling of ATTR4_XATTR_SUPPORTED 5326059 Jeff Layton NFS: convert LISTXATTRS to RFC 8276 deffaac Jeff Layton NFS: convert REMOVEXATTR to RFC 8276 d59be22 Jeff Layton NFS: convert SETXATTR to RFC 8276 e2b33b8 Jeff Layton NFS: update GETXATTR to RFC 8276 e61965a Jeff Layton NFS: add support for xattr ACCESS bits cb87135 Jeff Layton NFS: rename xattrname4 to xattrkey4 316eec6 Jeff Layton NFS: add new error codes for xattr support 7b8653d Jeff Layton FSAL: disable ATTR4_XATTR in FSAL_GLUSTER and FSAL_GPFS

1 0

TIRPC SVCAUTH_WRAP error in removexattr code
by Jeff Layton 16 Mar '21

16 Mar '21

I recently submitted some patches to clean up the xattr handling support for v4.2+, and discovered that there are xattr tests in pynfs! I tested against them and XATT8 failed, with the server timing out on the reply. Here's an excerpt from NIV_FULL_DEBUG run (sans some too- chatty debug messages that I disabled in the dbus code): 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] process_one_op :NFS4 :DEBUG :Request 2: opcode 75 is OP_REMOVEXATTR 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] check_resp_room :NFS4 :F_DBG :Status of OP_REMOVEXATTR in position 2 is ok so far, op response size = 32 total response size would be = 128 out of max 8192/8192 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] nfs4_op_removexattr :NFS4 :DEBUG :RemoveXattr len 10 name: user.attr1 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] nfs4_Is_Fh_Invalid :FH :F_DBG :NFS4 Handle (29:0x43000064187e06000000010000feffffffffffffff0200000000000000) 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Got read lock on 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c: 937 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Unlocked 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:945 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Got write lock on 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c :946 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_refresh_attrs :INODE :F_DBG :attrs obj attributes Request Mask=0111dfce Valid Mask=0011ffce Supported Mask=0311dfee REGULAR_FILE numlinks=0x1 size=0x0 mode=0644 owner=0x115f group=0x115f atime=15/03/2021 15:17:32 mtime=15/03/2021 15:17:32 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Unlocked 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:976 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :INODE :F_DBG :attrs obj attributes Request Mask=00100000 Valid Mask=0011ffce Supported Mask=0311dfee REGULAR_FILE numlinks=0x1 size=0x0 mode=0644 owner =0x115f group=0x115f atime=15/03/2021 15:17:32 mtime=15/03/2021 15:17:32 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Got read lock on 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c: 937 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Unlocked 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:945 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Got write lock on 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c :946 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_refresh_attrs :INODE :F_DBG :attrs obj attributes Request Mask=0111dfce Valid Mask=0011ffce Supported Mask=0311dfee REGULAR_FILE numlinks=0x1 size=0x0 mode=0644 owner=0x115f group=0x115f atime=15/03/2021 15:17:32 mtime=15/03/2021 15:17:32 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :RW LOCK :F_DBG :Unlocked 0x7f9120014730 (&entry->attr_lock) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:976 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] mdcache_getattrs :INODE :F_DBG :attrs obj attributes Request Mask=00100000 Valid Mask=0011ffce Supported Mask=0311dfee REGULAR_FILE numlinks=0x1 size=0x0 mode=0644 owner =0x115f group=0x115f atime=15/03/2021 15:17:32 mtime=15/03/2021 15:17:32 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_op :NFS4 :F_DBG :Current FH Len=29 0x70cd004c917f0000000000000000000000000000000000000000000000 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_op :NFS4 :F_DBG :Saved FH Len=0 (EMPTY) 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_op :NFS4 :DEBUG :Status of OP_REMOVEXATTR in position 2 = NFS4_OK, op response size is 32 total response size is 120 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_nfs4_compound :RW LOCK :F_DBG :Acquired mutex 0x7f914c0166e0 (&data->preserved_clientid->cid_mutex) at /home/jlayton/git/ganesha/src/Protocols/NFS/nfs4_Compound. c:1044 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] update_lease :CLIENT ID :F_DBG :Update Lease 0x7f914c016660 ClientID={Epoch=0x604fb2c8 Counter=0x00000002} CONFIRMED Client={0x7f914c00f2e0 name=(16:XATT8_1615835852) ref count=1} t_delta=0 reservations=0 refcount=3 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_nfs4_compound :RW LOCK :F_DBG :Released mutex 0x7f914c0166e0 (&data->preserved_clientid->cid_mutex) at /home/jlayton/git/ganesha/src/Protocols/NFS/nfs4_Compound. c:1048 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] _mdcache_lru_unref :RW LOCK :F_DBG :Acquired mutex 0x7f919ced6fe0 (&(qlane)->mtx) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:2036 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] _mdcache_lru_unref :RW LOCK :F_DBG :Released mutex 0x7f919ced6fe0 (&(qlane)->mtx) at /home/jlayton/git/ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:2043 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] compound_data_Free :RW LOCK :F_DBG :Released mutex 0x7f9120011fe8 (&slot->lock) at /home/jlayton/git/ganesha/src/Protocols/NFS/nfs4_Compound.c:1453 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] clear_op_context_export_impl :EXPORT :F_DBG :put export ref for id 100 /, refcount = 1 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_request :DISP :F_DBG :Before svc_sendreply on socket 35 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :xdr_ioq_uv_create() uv 0x7f914c00cd70 size 8192 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :xdr_ioq_reset() xioq 0x7f914c0174d0 head 0x7f914c017650 wh_pos 0 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :xdr_reply_encode:93 ACCEPTED INLINE 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :xdr_reply_encode:109 SUCCESS 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :svc_vc_reply: 0x7f9148000e20 fd 35 SVCAUTH_WRAP failed (will set dead) 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] complete_request :DISP :DEBUG :NFS DISPATCHER: FAILURE: Error while calling svc_sendreply on a new request. rpcxid=185455221 socket=35 function:NFS4_COMP client:::ffff:192.168.1.3 program:100003 nfs version:4 proc:1 errno: 0 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :svc_destroy_it() 0x7f9148000e20 fd 35 fd_send -1 xp_refcnt 4 af 10 port 42712 @complete_request:801 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :svc_rqst_xprt_unregister:1146 locking 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :svc_rqst_xprt_unregister:1151 unlocking @svc_rqst_xprt_unregister:1146 15/03/2021 15:17:32 : epoch 604fb2c8 : tleilax.poochiereds.net : ganesha.nfsd-309231[svc_3] rpc :TIRPC :F_DBG :svc_rqst_unhook_events: xprt 0x7f9148000e20 fd 35 ev_flags ADDED_RECV INITIALIZED CLOSE DESTROYING It looks like it all works, until we hit the SVCAUTH_WRAP failure...which is odd because this run is using AUTH_SYS, so you'd think that would be a no-op? In any case, I could use some help deciphering this log. What happened? TIA! -- Jeff Layton <jlayton(a)poochiereds.net>

3 5

running out of file descriptors
by Alok Sinha 16 Mar '21

16 Mar '21

Version : nfs-ganesha-2.8.3 File descriptor limit : 65536 FSAL used : VFS Server is running out of file descriptor. /proc/<pid>/fd shows that. I see few .so ( shared objects ) and executables are open more than once . Few of them are open about 26 times. I have not debugged LRU yet. I think all open FDs are by MDCACHE. Question: Is it expected that MDCACHE would open the same file many times ( multiple FDs )? -alok

2 3

Announce Push of V4-dev.54
by Frank Filz 12 Mar '21

12 Mar '21

Branch next Tag:V4-dev.54 Merge Highlights * PRIu64 fixups * GSSAPI: eliminate printerr macro and extraneous newlines * selinux: (re)start fails to read /var/lib/nfs when it's a symlink Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 3a184de Frank S. Filz V4-dev.54 3c08ee2 Kaleb S. KEITHLEY selinux: (re)start fails to read /var/lib/nfs when it's a symlink b5e8b1c Jeff Layton GSSAPI: eliminate printerr macro and extraneous newlines e5d5d00 Frank S. Filz PRIu64 fixups

1 0

Change in ...nfs-ganesha[next]: build: fixup perms on (/var)/run/ganesha
by Kaleb KEITHLEY (GerritHub) 11 Mar '21

11 Mar '21

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/512322 ) Change subject: build: fixup perms on (/var)/run/ganesha ...................................................................... build: fixup perms on (/var)/run/ganesha fix found by downstream testing of package metadata. Also use %{_rundir} instead of hard-coded path Change-Id: Icdc4d6d0cd0d253788fb73172cdfa3a03bd08bbd Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> --- M src/nfs-ganesha.spec-in.cmake 1 file changed, 3 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/22/512322/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/512322 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Icdc4d6d0cd0d253788fb73172cdfa3a03bd08bbd Gerrit-Change-Number: 512322 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: selinux: (re)start fails to read /var/lib/nfs when it's a symlink
by Kaleb KEITHLEY (GerritHub) 11 Mar '21

11 Mar '21

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/512320 ) Change subject: selinux: (re)start fails to read /var/lib/nfs when it's a symlink ...................................................................... selinux: (re)start fails to read /var/lib/nfs when it's a symlink In Red Hat Gluster Storage, the HA configuration changes /var/lib/nfs to be a symlink to a shared state directory. New selinux policy is prohibiting the reading of that symlink and ganesha is prevented from starting when it tries to read it. Also fixes another AVC (cluster_t:dbus send_msg) seen at the same time. Change-Id: I567fb165b0e8077f4071b0dc75fa331d8dc42ee0 Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> --- M src/selinux/ganesha.te 1 file changed, 7 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/20/512320/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/512320 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I567fb165b0e8077f4071b0dc75fa331d8dc42ee0 Gerrit-Change-Number: 512320 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com> Gerrit-MessageType: newchange

1 0