Bug 1006772

Summary:	nfs: some vague message in logs
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Saurabh <saujain>
Component:	glusterd	Assignee:	Vivek Agarwal <vagarwal>
Status:	CLOSED ERRATA	QA Contact:	Saurabh <saujain>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.1	CC:	mzywusko, sankarshan, ssamanta, vagarwal, vbellur
Target Milestone:	---
Target Release:	RHGS 3.0.0
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.6.0.0-1.el6rhs	Doc Type:	Bug Fix
Doc Text:	If NFS server does not get the NLM port number of the NFS client, then server log would look like: "Unable to get NLM port of the client. Is the firewall running on client? OR Are RPC services running (rpcinfo -p)?" instead of "Unable to get NLM port of the client. Is the firewall running on client?"	Story Points:	---
Clone Of:
Clones:	1090782 (view as bug list)		Environment:
Last Closed:	2014-09-22 19:28:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1090782

Description Saurabh 2013-09-11 09:22:09 UTC

Description of problem:
getting a message about firewall, even when the firewall is off on both server and client.

iptables on server,
[root@nfs1 ~]# service iptables status
iptables: Firewall is not running.


iptables on client,
on client,
[root@rhsauto030 ~]# service iptables status
iptables: Firewall is not running.


Version-Release number of selected component (if applicable):
glusterfs-3.4.0.33rhs-1.el6rhs.x86_64

How reproducible:
always

Steps to Reproduce:
1. mount a volume over nfs
2. rpcinfo -p
3. service rpcbind stop
4. rpcinfo -p
5. service rpcbind start
6. service nfslock restart
7. rpcinfo -p
8. try a shared lock on a file.

Actual results:

nfs.log says,

[2013-09-11 08:55:11.775876] E [nlm4.c:977:nlm4_establish_callback] 0-nfs-NLM: Unable to get NLM port of the client. Is the firewall running on client?
[2013-09-11 08:55:41.777704] E [nlm4.c:977:nlm4_establish_callback] 0-nfs-NLM: 

Unable to get NLM port of the client. Is the firewall running on client?

packet trace,
  4   0.001124   10.70.37.5 -> 10.70.37.213 NFS V3 ACCESS Call, FH:0xa3b59a5b
  6   0.003112 10.70.37.213 -> 10.70.37.5   NFS V3 ACCESS Reply (Call In 4)
  8   0.003416   10.70.37.5 -> 10.70.37.213 NFS V3 GETATTR Call, FH:0xa3b59a5b
  9   0.005949 10.70.37.213 -> 10.70.37.5   NFS V3 GETATTR Reply (Call In 8)  Directory mode:0755 uid:0 gid:0
 10   0.006089   10.70.37.5 -> 10.70.37.213 NFS V3 ACCESS Call, FH:0x0c667ce4
 11   0.007776 10.70.37.213 -> 10.70.37.5   NFS V3 ACCESS Reply (Call In 10)
 12   0.007970   10.70.37.5 -> 10.70.37.213 NFS V3 GETATTR Call, FH:0x0c667ce4
 13   0.010331 10.70.37.213 -> 10.70.37.5   NFS V3 GETATTR Reply (Call In 12)  Directory mode:0777 uid:0 gid:0
 14   0.010778   10.70.37.5 -> 10.70.37.213 NFS V3 LOOKUP Call, DH:0x0c667ce4/a
 15   0.013052 10.70.37.213 -> 10.70.37.5   NFS V3 LOOKUP Reply (Call In 14), FH:0x876e0a56
 16   0.013221   10.70.37.5 -> 10.70.37.213 NFS V3 ACCESS Call, FH:0x876e0a56
 17   0.014224 10.70.37.213 -> 10.70.37.5   NFS V3 ACCESS Reply (Call In 16)
 31   0.018518   10.70.37.5 -> 10.70.37.213 NLM V4 LOCK Call FH:0x876e0a56 svid:5 pos:0-0
 33   0.019080 10.70.37.213 -> 10.70.37.5   NLM V4 LOCK Reply (Call In 31) NLM_BLOCKED
 52  30.019290   10.70.37.5 -> 10.70.37.213 NLM V4 LOCK Call FH:0x876e0a56 svid:5 pos:0-0
 53  30.020434 10.70.37.213 -> 10.70.37.5   NLM V4 LOCK Reply (Call In 52) NLM_BLOCKED
 79  60.022740   10.70.37.5 -> 10.70.37.213 NLM V4 LOCK Call FH:0x876e0a56 svid:5 pos:0-0
 82  60.023362 10.70.37.213 -> 10.70.37.5   NLM V4 LOCK Reply (Call In 79) NLM_BLOCKED
100  90.023302   10.70.37.5 -> 10.70.37.213 NLM V4 LOCK Call FH:0x876e0a56 svid:5 pos:0-0
101  90.024292 10.70.37.213 -> 10.70.37.5   NLM V4 LOCK Reply (Call In 100) NLM_BLOCKED
115 108.280520   10.70.37.5 -> 10.70.37.213 NLM V4 CANCEL Call FH:0x876e0a56 svid:5 pos:0-0
116 108.283282 10.70.37.213 -> 10.70.37.5   NLM V4 CANCEL Reply (Call In 115)


Expected results:
the message should be something different, as the iptables are off on server and client both.



Additional info:

Comment 2 Vivek Agarwal 2014-04-07 11:41:03 UTC

Per bug triage, between dev, PM and QA, moving these out of denali

Comment 4 santosh pradhan 2014-04-24 08:14:14 UTC

Posted the patch for review:

http://review.gluster.org/7544

Comment 5 Nagaprasad Sathyanarayana 2014-05-06 10:35:07 UTC

BZs not targeted for Denali.

Comment 7 Vivek Agarwal 2014-05-22 11:43:45 UTC

Merged as a part of rebase

Comment 10 errata-xmlrpc 2014-09-22 19:28:54 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2014-1278.html