Bug 33742
| Summary: | nfs refuses connection after update of rh7 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Changed to DavidTangye@hotmail.com <dt1954> |
| Component: | nfs-server | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-11 10:36:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I get the same error: "mount: RPC: Unable to receive; errno = Connection refused" between two RH7.2 machines, installed using the default workstation installation (kernel 2.4.7-10). In addition, mounting from the RH7.2 machines to my RH7.0 with latest up2dates, the 7.0 machine logs an Authenticated mount from ..., but the 7.2 machine says: "Mount: RPC: Timed out." These machines were mounting fine when RH5.2 was installed; My other RH7.0 machines mount fine (v.2.2). This Linux NFS-HOWTO http://nfs.sourceforge.net/nfs-howto/client.html, states that /proc/filesystems should contain an entry for NFS. My RH7.2 systems do not, but my older, nfs-mountable systems do. I will need to rebuild the kernel or try a different installation method to test, time permitting. If you get there first, please post the results. Tim Addendum: I built the new kernel, moving NFS file system support from module to kernel. /proc/filesystems now lists nfs as a file type. No detectable change in the behavior - i.e., I am still not able to mount a remote file system from the RH7.2 client to a RH7.0 server. Tim I discovered the cause of my mounting problems - the firewall rules were disallowing connection from the server to the new client. ipchains -L listed reject of incoming tcp, etc. I removed all the exclusions from input and now mount works as before. |
I have applied Redhat 7.0 updates to my two linux hosts, including updating package - xinetd-2.1.8.9pre9-6 to - xinetd-2.1.8.9pre11-1 on both hosts, and now nfs will not allow connections from either direction. The error I get is - "mount: RPC: Unable to receive; errno = Connection refused" *** On the client side : - in /etc/fstab is the line - lestar:/ /mnt/lestar nfs user,exec,dev,suid,rw,noauto 1 1 - I run the command "mount lestar:/" and get the error - "mount: RPC: Unable to receive; errno = Connection refused" I get this from either end. Neither server will provide any nfs mounts. **** The server side config (of one host) is : - At host startup the system log reports - Mar 29 13:04:57 lestar xinetd[444]: chargen disabled, removing Mar 29 13:04:57 lestar xinetd[444]: chargen-udp disabled, removing Mar 29 13:04:57 lestar xinetd[444]: time disabled, removing Mar 29 13:04:57 lestar xinetd[444]: time disabled, removing Mar 29 13:04:57 lestar xinetd[444]: linuxconf disabled, removing Mar 29 13:04:57 lestar xinetd[444]: echo-udp disabled, removing Mar 29 13:04:57 lestar xinetd[444]: echo disabled, removing Mar 29 13:04:57 lestar xinetd[444]: daytime-udp disabled, removing Mar 29 13:04:57 lestar xinetd[444]: daytime disabled, removing Mar 29 13:04:57 lestar xinetd[444]: xinetd Version 2.1.8.9pre11 started with Mar 29 13:04:57 lestar xinetd[444]: libwrap Mar 29 13:04:57 lestar xinetd[444]: options compiled in. Mar 29 13:04:57 lestar xinetd[444]: Started working: 1 available service Mar 29 13:05:00 lestar xinetd: xinetd startup succeeded I wonder what the 1 available service is? How do I find out? ssh and ftp servers work properly on both sides. nfs used to work on one side (not tested on the other) with xinetd-2.1.8.9pre9-6. - the contents of /etc/exports is - / 192.168.0.0/255.255.255.0(rw,no_root_squash) # All of lestar - I run "exportfs -r" and get in /var/lib/nfs/etab - / 192.168.0.0/255.255.255.0(rw,async,wdelay,hide,secure,no_root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) The advice in /usr/share/doc/xinetd-2.1.8.9pre11/CHANGELOG states - 2.1.8.9pre10 a) When compiled with libwrap support, xinetd passes the server name to be checked in hosts.{allow,deny} instead of the service name. Behavior should now match tcpd. 2.1.8.9pre11 b) More paranoid handling of access control in addr.c c) For internal services and libwrap, access control is performed by the service name (instead of the server, since there is no server). I believe a) and c) are no problem to me. However I wonder what is meant by c). - Is the paranoid access logic stopping my connection? - or is the nfs service not started by xinetd?