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:
Per bug triage, between dev, PM and QA, moving these out of denali
Posted the patch for review: http://review.gluster.org/7544
BZs not targeted for Denali.
Merged as a part of rebase
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