On Fri, 30 Dec 2005 07:29:54 -0600, Charles Howse wrote:
>> On Thu, 29 Dec 2005 12:37:37 -0600, Charles Howse wrote:
>>
>>>> On Thu, 29 Dec 2005 10:48:13 -0600, Charles Howse wrote:
>>>>
>>>>>> On Wed, 28 Dec 2005 21:33:57 -0600, Charles Howse wrote:
>>>>>>
>>>>>>>> On Wed, 28 Dec 2005 11:29:39 -0600, Charles Howse wrote:
>>>>>>>>
>>>>>>>>> I'm sure this has been asked and answered hundreds of times, but I've
>>>>>>>>> been
>>>>>>>>> working on it for 2 days now, and can't resolve the issue.
>>>>>>>>> I'm trying to mount an nfs filesystem that lives on FC4 from my
>>>>>>>>> Macintosh
>>>>>>>>> across the home lan (machines are only 15' apart). ;-)
>>>>>>>>> I can successfully mount nfs shares that live on the FreeBSD machine
>>>>>>>>> from
>>>>>>>>> the Mac, and can successfully ssh to the FC4 box from the Mac.
>>>>>>>>>
>>>>>>>>> On FC4:
>>>>>>>>> [root@shemp ~]# cat /etc/exports
>>>>>>>>> /disc2 moe(rw,sync) larry(ro,sync)
>>>>>>>>> /home moe(rw) larry(ro)
>>>>>>>>> [root@shemp ~]# cat /etc/hosts.allow
>>>>>>>>> #
>>>>>>>>> # hosts.allow This file describes the names of the hosts which are
>>>>>>>>> # allowed to use the local INET services, as decided
>>>>>>>>> # by the '/usr/sbin/tcpd' server.
>>>>>>>>> #
>>>>>>>>> ALL: ALL
>>>>>>>>> [root@shemp ~]# cat /etc/hosts.deny
>>>>>>>>> #
>>>>>>>>> # hosts.deny This file describes the names of the hosts which are
>>>>>>>>> # *not* allowed to use the local INET services, as
>>>>>>>>> decided
>>>>>>>>> # by the '/usr/sbin/tcpd' server.
>>>>>>>>> #
>>>>>>>>> # The portmap line is redundant, but it is left to remind you that
>>>>>>>>> # the new secure portmap uses hosts.deny and hosts.allow. In
>>>>>>>>> particular
>>>>>>>>> # you should know that NFS uses portmap!
>>>>>>>>>
>>>>>>>>> [root@shemp ~]# cat /proc/fs/nfs/exports
>>>>>>>>> # Version 1.1
>>>>>>>>> # Path Client(Flags) # IPs
>>>>>>>>> /home larry(ro,root_squash,sync,wdelay)
>>>>>>>>> /disc2 larry(ro,root_squash,sync,wdelay)
>>>>>>>>> [root@shemp ~]# cat /var/lib/nfs/xtab
>>>>>>>>> [root@shemp ~]# exportfs -ra
>>>>>>>>> exportfs: /etc/exports [2]: No 'sync' or 'async' option specified for
>>>>>>>>> export
>>>>>>>>> "moe:/home".
>>>>>>>>> Assuming default behaviour ('sync').
>>>>>>>>> NOTE: this default has changed from previous versions
>>>>>>>>>
>>>>>>>>> On the Mac:
>>>>>>>>> [charles@larry:~]$ mount -t nfs shemp:/disc2 ~/mnt
>>>>>>>>> mount_nfs: /Users/charles/mnt: Operation not permitted
>>>>>>>>> [charles@larry:~]$ mount -t nfs shemp:/home ~/mnt
>>>>>>>>> mount_nfs: /Users/charles/mnt: Operation not permitted
>>>>>>>>>
>>>>>>>>> properties for ~/mnt on the Mac:
>>>>>>>>> 0 drwxr-xr-x 3 charles charles 102 Nov 20 17:11 mnt/
>>>>>>>>>
>>>>>>>>> My uid/gid are the same on both client and server...my username is the
>>>>>>>>> same
>>>>>>>>> on both machines, password is different.
>>>>>>>>>
>>>>>>>>> Anybody have a clue? I've read and read and Google'd and browsed till
>>>>>>>>> I'm
>>>>>>>>> blue in the face.
>>>>>>>>> Could this be a problem with (what is it...) "non-privileged ports"?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks,
>>>>>>>>> Charles
>>>>>>>>
>>>>>>>>
>>>>>>>> I bet it's the firewall in FC4. Turn it off and see if nfs works. Then
>>>>>>>> you
>>>>>>>> go from there. Besides the port 2049 (nfs) you need to have several
>>>>>>>> other
>>>>>>>> ports open. The problem is those ports are not always the same, which is
>>>>>>>> a
>>>>>>>> problem with the firewall.
>>>>>>>
>>>>>>> Thank you all very kindly for the suggestions.
>>>>>>> The solution to the problem was the lack of the 'insecure' export option
>>>>>>> in
>>>>>>> /etc/exports:
>>>>>>> /home larry(rw,insecure,sync)
>>>>>>>
>>>>>>> I discovered it by tailing /var/log/messages:
>>>>>>> Dec 28 15:44:00 shemp rpc.mountd: authenticated mount request from
>>>>>>> larry:982
>>>>>>> for /home (/home)
>>>>>>> Dec 28 15:44:00 shemp kernel: nfsd: request from insecure port
>>>>>>> (192.168.254.3:50646)!
>>>>>>>
>>>>>>> Everything works now. Thanks again.
>>>>>>> Look for my new thread on discussing why questions to mailing lists and
>>>>>>> usenet groups don't get answered.
>>>>>>
>>>>>> Strange, I don't have insecure in my /etc/exports on the nfs server:
>>>>>>
>>>>>> /opt 192.168.2.0/24(rw,sync)
>>>>>> /home 192.168.2.0/24(rw,sync)
>>>>>>
>>>>>> and it still works. And I'm all the more surprised knowing how the default
>>>>>> iptables rules are set on FC4. But maybe you already had the firewall set
>>>>>> up to allow nfs traffic and the auxiliary nfs services running on fixed
>>>>>> ports.
>>>>>
>>>>> Did I mention that I turned iptables off? Didn't even check the ruleset,
>>>>> just turned it off.
>>>>> Also made sure that selinux was disabled.
>>>>
>>>> I don't think you did. Turning off the firewall is not a permanent
>>>> solution. Does it work if you turn it back on?
>>>>
>>>>>
>>>>>> Reading the exports man page I see that the secure option is on by
>>>>>> default, which requires that nfs connections be made from ports < 1024.
>>>>>> Checking this with netstat on my nfs server I do see connections
>>>>>> originating on ports 800 and 799, so maybe that's the default behavior
>>>>>> of FC4 nfs clients. Or maybe I just got lucky.
>>>>>>
>>>>>> Good to know about "insecure" though.
>>>>>
>>>>> It may have something to do with the request coming from the Mac...?
>>>>> Maybe Mac's use insecure ports for nfs connections? Haven't looked into
>>>>> making the Mac use a secure port for nfs.
>>>>
>>>> Out of curiosity, can you do a
>>>>
>>>> netstat -tupan
>>>>
>>>> on the FC4 nfs server while accessing the exported partition from the mac
>>>> and see what port it's coming from?
>>>
>>> Yes, it works with iptables started, but the only established connection I
>>> see below, is me ssh'ing to the FC4 box to run those commands.
>>>
>>> [root@shemp ~]# service iptables start
>>> [root@shemp ~]# netstat -tupan
>>> Active Internet connections (servers and established)
>>> Proto Recv-Q Send-Q Local Address Foreign Address
>>> State PID/Program name
>>> tcp 0 0 0.0.0.0:2049 0.0.0.0:*
>>> LISTEN -
>>> tcp 0 0 0.0.0.0:32769 0.0.0.0:*
>>> LISTEN 1348/rpc.statd
>>> tcp 0 0 0.0.0.0:32774 0.0.0.0:*
>>> LISTEN -
>>> tcp 0 0 0.0.0.0:111 0.0.0.0:*
>>> LISTEN 1330/portmap
>>> tcp 0 0 0.0.0.0:628 0.0.0.0:*
>>> LISTEN 1720/rpc.rquotad
>>> tcp 0 0 127.0.0.1:631 0.0.0.0:*
>>> LISTEN 1630/cupsd
>>> tcp 0 0 127.0.0.1:25 0.0.0.0:*
>>> LISTEN 1768/sendmail: acce
>>> tcp 0 0 0.0.0.0:639 0.0.0.0:*
>>> LISTEN 1732/rpc.mountd
>>> tcp 0 0 :::110 :::*
>>> LISTEN 1750/dovecot
>>> tcp 0 0 :::22 :::*
>>> LISTEN 1678/sshd
>>> tcp 0 1440 ::ffff:192.168.254.5:22 ::ffff:192.168.254.3:52541
>>> ESTABLISHED 8920/sshd: charles
>>> udp 0 0 0.0.0.0:32768 0.0.0.0:*
>>> 1348/rpc.statd
>>> udp 0 0 0.0.0.0:2049 0.0.0.0:*
>>> -
>>> udp 0 0 0.0.0.0:32769 0.0.0.0:*
>>> -
>>> udp 0 0 0.0.0.0:676 0.0.0.0:*
>>> 1348/rpc.statd
>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>> 1330/portmap
>>> udp 0 0 0.0.0.0:625 0.0.0.0:*
>>> 1720/rpc.rquotad
>>> udp 0 0 0.0.0.0:631 0.0.0.0:*
>>> 1630/cupsd
>>> udp 0 0 192.168.254.5:123 0.0.0.0:*
>>> 1691/ntpd
>>> udp 0 0 127.0.0.1:123 0.0.0.0:*
>>> 1691/ntpd
>>> udp 0 0 0.0.0.0:123 0.0.0.0:*
>>> 1691/ntpd
>>> udp 0 0 0.0.0.0:636 0.0.0.0:*
>>> 1732/rpc.mountd
>>> udp 0 0 :::123 :::*
>>> 1691/ntpd
>>> [root@shemp ~]#
>>
>> Are you actually accessing the nfs partitions from the mac client, when
>> you run netstat? Copy a big file.
>
> Sorry to be so long getting back.
> It looks like port 800 on FC and 2049 on the Mac.
> Here's the output:
>
> [root@shemp ~]# netstat -tupan
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address
> State PID/Program name
> tcp 0 0 0.0.0.0:2049 0.0.0.0:*
> LISTEN -
> tcp 0 0 0.0.0.0:32769 0.0.0.0:*
> LISTEN 1348/rpc.statd
> tcp 0 0 0.0.0.0:32774 0.0.0.0:*
> LISTEN -
> tcp 0 0 0.0.0.0:111 0.0.0.0:*
> LISTEN 1330/portmap
> tcp 0 0 0.0.0.0:628 0.0.0.0:*
> LISTEN 1720/rpc.rquotad
> tcp 0 0 127.0.0.1:631 0.0.0.0:*
> LISTEN 1630/cupsd
> tcp 0 0 127.0.0.1:25 0.0.0.0:*
> LISTEN 1768/sendmail: acce
> tcp 0 0 0.0.0.0:639 0.0.0.0:*
> LISTEN 1732/rpc.mountd
> tcp 0 0 192.168.254.5:800 192.168.254.4:2049
> ESTABLISHED -
> tcp 0 0 :::110 :::*
> LISTEN 1750/dovecot
> tcp 0 0 :::22 :::*
> LISTEN 1678/sshd
> tcp 0 0 ::ffff:192.168.254.5:110 ::ffff:192.168.254.3:54290
> TIME_WAIT -
> tcp 0 1296 ::ffff:192.168.254.5:22 ::ffff:192.168.254.3:54255
> ESTABLISHED 14540/sshd: charles
> udp 0 0 0.0.0.0:32768 0.0.0.0:*
> 1348/rpc.statd
> udp 0 0 0.0.0.0:2049 0.0.0.0:*
> -
> udp 0 0 0.0.0.0:32769 0.0.0.0:*
> -
> udp 0 0 0.0.0.0:800 0.0.0.0:*
> -
> udp 0 0 0.0.0.0:676 0.0.0.0:*
> 1348/rpc.statd
> udp 0 0 0.0.0.0:111 0.0.0.0:*
> 1330/portmap
> udp 0 0 0.0.0.0:625 0.0.0.0:*
> 1720/rpc.rquotad
> udp 0 0 0.0.0.0:631 0.0.0.0:*
> 1630/cupsd
> udp 0 0 192.168.254.5:123 0.0.0.0:*
> 1691/ntpd
> udp 0 0 127.0.0.1:123 0.0.0.0:*
> 1691/ntpd
> udp 0 0 0.0.0.0:123 0.0.0.0:*
> 1691/ntpd
> udp 0 0 0.0.0.0:636 0.0.0.0:*
> 1732/rpc.mountd
> udp 0 0 :::123 :::*
> 1691/ntpd
> [root@shemp ~]#
>
So, you see, the mac is making requests from 2049, which is unpriviledged.
I thought 2049 was the port nfs was listening on, not sending requests
from.
I have the exact opposite situation. On my nfs server (192.168.2.40):
netstat -tupan
tcp 0 0 192.168.2.40:2049 192.168.2.10:800 ESTABLISHED -
tcp 0 0 192.168.2.40:2049 192.168.2.10:799 ESTABLISHED -
so the client makes requests from low-numbered ports to the nfs port on
the server.
Perhaps more knowledgeable people than us could figure this out. For
academic purposes only. Unless I totally misunderstood, and in fact your
mac is the nfs server, and you're accessing it from FC4. It looks that way
from your nestat output.
