We can still ping one another after the ipchains -F command is run.

Let me describe the network briefly, in case this helps:

We have a cable modem, we share it by connecting to a cable modem router which then connects to the uplink plug on our hub. Each computer is conntected to the regular (non-uplink) ethernet plugs on the hub. When I run ping, I can see the lights associated with each machine blink once per second.

Hope that helps

I'm lost as to what to try next, the nfs is so simple to setup and depends only on a few things which you appear to have.


I just setup a box with redhat 7.1 a few minutes ago

I just setup nfs to see what it would do


here's what I did
machine ip is 12.0.0.8

step 1

/etc/exports
/home 12.0.0.7(ro)

step 2

exportfs -av

step 3

/etc/rc.d/init.d/nfs start


step 4

on machine with ip address 12.0.0.7

mkdir /nfs/home

mount -t nfs 12.0.0.8:/home /nfs/home


Now I got the same error as you because I have a firewall on that interface on the nfs server


so I did this on the machine 12.0.0.8

ipchains -F


then step 4 works fine

One thing after running the command ipchains -F

try this

ipchains -L

see if it says accept

for input output and forward






check /var/log/messages for something like this





Feb 4 20:30:45 WWW nfs: Starting NFS services: succeeded
Feb 4 20:30:45 WWW nfs: rpc.rquotad startup succeeded
Feb 4 20:30:45 WWW nfs: rpc.mountd startup succeeded
Feb 4 20:30:45 WWW kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Feb 4 20:30:45 WWW nfs: rpc.nfsd startup succeeded
Feb 4 20:30:51 WWW rpc.mountd: dump request from 12.0.0.4 Feb 4 20:33:30 WWW rpc.mountd: authenticated mount request from 12.0.0.7:882 for /home (/home)

one way to do this is

cat /var/log/messages


or run it like this


tail -f /var/log/messages


then while that's running run
nfs start
exportfs -av

and try to mount from other machine


post the errors

Nothing printed when the connection was refused

This makes me think that you are correct. Everything should be working, but soething is not connecting correctly.

I wonder if the networking might somehow be the problem. When we installed linux, both machines were called localhost.localdomain. I tried to fix this, but I may have missed something.

Since we only installed linux a few weeks ago and haven't really settled in, I am thinking of re-installing. If I do, would it be a good idea to do a server install on one of the computers rather than doing a workstation install on both?

I usually install everything, but that's not necessarily a great thing.


That's just the way i like to do it.


what about the ipchains -L was it ok



tcpdump should show the traffic if you have it installed



I tried on mine with firewall up and

tail -f /var/log/messages says nothing

it only reports other errors or success when there's no firewall



however tcpdump shows this traffic even if I get the Connection refused error



tcpdump: listening on all devices
00:48:48.089718 eth0 < 12.0.0.7.920 > WWW.HOME.sunrpc: S [ECN-Echo,CWR] 1278539892:1278539892(0) win 5840 <mss 1460,sackOK,timestamp 359335087 0,nop,wscale 0> (DF)
00:48:48.089786 eth0 > WWW.HOME > 12.0.0.7: icmp: WWW.HOME tcp port sunrpc unreachable [tos 0xc0]
00:48:48.090885 eth0 < 12.0.0.7.921 > WWW.HOME.635: udp 108 (DF)
00:48:48.090955 eth0 > WWW.HOME > 12.0.0.7: icmp: WWW.HOME udp port 635 unreachable [tos 0xc0]



notice these

udp port 635 unreachable [tos 0xc0]

so the error still sounds like firewall issues

but that's only because you had me fix it earlier. It used to say REJECT.

By the way, for the output and forward, there were no entries, but on the line corresponding to each it said

Chain forward (policy ACCEPT)
Chain output (policy ACCEPT)

I don't have tcpdump installed

What does input say?


If it said ACCEPT it would probably work



ipchains -F will not change this


to change it use this

ipchains -P input ACCEPT

this is what we want to see


ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

It contains several ports and protocols with individual ACCEPTS or REJECTS.

it looks like the default is ACCEPT, and both tcp and udp for nfs are set to ACCEPT

I modified my /etc/sysconfig/ipchains file so that ipchailns -L prints out ACCEPT for all chains (just like yours)

However, I am now seeing a new error. The mount attempt times out.

Any thoughts?

make sure you did the ipchains flush on both systems


check logs on nfs server and the client


tail -f /var/log/messages


if it is ok then it may be a local problem with the mount command now


try exporting an empty test folder like this


mkdir /nfsmount

chmod 777 /nfsmount

add it to /etc/exports

/nfsmount 192.168.1.2(rw)

exportfs -av

then mount it on the client like this

mkdir ~/nfs

mount -t nfs 192.168.1.1:/nfsmount ~/nfs

Hi,

Make sure that nfs and portmap are running on both the server and client. I tried evrything the other folks did and everything is fine.

I re-installed, and it still didn't work.

I was sad.

Then I read a message about making sure that nfs was running on both machines, so I started NFS on the other machine.

It didn't work.

I was still sad.

Then it occured to me that the firewall rules on the other machine were probably just as restrictive, so I ran ipchains -F and now it works!

I have ceased to be sad.

Thanks for all your help, I have learned a lot about security and networking, but unfortunatly, it looks like the easiest thing to do is just remove all security and that doesn't seem like a good long term rule if I ever get a real IP address.

Glad you got it.

This thread is why I have NFS working I just have to say thanks.

On the client, run:
showmount -e 192.168.1.1 (or whatever the IP address is for your server)

If it doesn't show you the server's exported filesystems, then your client isn't getting served.
If it does show you the exported filesystems, then maybe you didn't
enable port 2049 on the client? I don't think that should matter, but it may.


Ooops, just updated the page after submitting, and saw that you've already
got it working. . .