Re: Q: nfs server fails to mount own exported resource, but other client able to mount

2014-04-24 Thread Tom H 
On Thu, Apr 24, 2014 at 2:06 PM, Snow Leopard
 wrote:
>
> the mystery has been resolved -- question how did I not catch it right away?
>
> I found that my old Red Hat system and Debian Wheezy/Squeezy resolve
> computer name into ip address in different ways.
>
> Red Hat mount maps computer name to DHCP ip address
> Debian mount maps computer name to loopback interface
>
> My attention was somewhat distracted and I've missed that in this case in
> /etc/exports a record should look
>
> not like
> /export/home192.168.0.0/24(rw,sync,no_subtree_check)
>
> but instead
> /export/home192.168.0.0/24(rw,sync,no_subtree_check)
> 127.0.0.0/16(rw,sync,no_subtree_check)
>
> The clue was found in logfiles
> /var/log/syslog.1:Apr 24 10:29:19 vega mountd[1320]: refused mount request
> from 127.0.1.1 for /export/home (/export/home): unmatched host
>
> The mystery is resolved.

Good!

That's why I'd asked about "/etc/exports".


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=syryj-mujciz6hkqe_tozmjieqk29gr0grb15zdp7p...@mail.gmail.com

Re: Q: nfs server fails to mount own exported resource, but other client able to mount

2014-04-24 Thread Snow Leopard 

Hi,

the mystery has been resolved -- question how did I not catch it right away?

I found that my old Red Hat system and Debian Wheezy/Squeezy resolve 
computer name into ip address in different ways.


Red Hat mount maps computer name to DHCP ip address
Debian mount maps computer name to loopback interface

My attention was somewhat distracted and I've missed that in this case 
in /etc/exports a record should look


not like
/export/home192.168.0.0/24(rw,sync,no_subtree_check)

but instead
/export/home192.168.0.0/24(rw,sync,no_subtree_check) 
127.0.0.0/16(rw,sync,no_subtree_check)


The clue was found in logfiles
/var/log/syslog.1:Apr 24 10:29:19 vega mountd[1320]: refused mount 
request from 127.0.1.1 for /export/home (/export/home): unmatched host


The mystery is resolved.

Cheers,
Andy

On 4/24/2014 3:25 AM, Ron Leach wrote:

On 24/04/2014 09:49, Snow Leopard wrote:

Hi,

I came across strange "mount" problem on nfs server -- it refuses to
mount it's own directory while other nfs clients able mount nfs server
exported directoryjust fine

1. nfs server
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
/etc/exports: /export/home 192.163.0.0/24(rw,subtree_check)
drxwrxwrxw /export/home

2. client1
name: meteor.myclub.com
OS: Valhalla (Red Hat 7.3)
ip: 192.168.0.1
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

3. client2
name: moon.myclub.com
OS: squeeze (Debian)
ip: 192.168.0.64
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

4. client3 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs 192.168.0.62:/export/home /mnt
mounts directory without any error

5. client4 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs install:/export/home /mnt
mounts fails with an error

mount -v -t nfs install:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:21:36 2014
mount.nfs: trying text-based options
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting install:/export/home

mount -v -t nfs install.myclub.com:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:22:50 2014
mount.nfs: trying text-based options
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting
install.myclub.com:/export/home

The error indicates that when I attempt to mount by using FQDN of nfs
server -- the name resolves to 127.0.1.1 and client resolves to
127.0.0.1 .




I wonder if it is letting you mount as 'nfs' when you supply the IP 
address, but is not letting you mount as 'nfs' when you try to address 
the device locally (which doesn't surprise me).


While I don't use mount, I do use fstab to mount the device containing 
our nfs export, locally


/dev/md5  /mnt/point  ext4rw,auto,users,exec

Isn't the 'right' way to mount local filesystems directly as 'ext4' or 
whatever, and only mount as 'nfs' if the filesystem has to be accessed 
at another IP address?


regards, Ron



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/535952ad.6060...@gmail.com

Re: Q: nfs server fails to mount own exported resource, but other client able to mount

2014-04-24 Thread Tom H 
On Thu, Apr 24, 2014 at 4:49 AM, Snow Leopard
 wrote:
>
> I came across strange "mount" problem on nfs server -- it refuses to mount
> it's own directory while other nfs clients able mount nfs server exported
> directory just fine
>
> 1. nfs server
> name: install.myclub.com
> OS: wheeze (Debian)
> ip: 192.168.0.62
> /etc/exports:   /export/home 192.163.0.0/24(rw,subtree_check)
> drxwrxwrxw  /export/home
>
> 2. client1
> name: meteor.myclub.com
> OS: Valhalla (Red Hat 7.3)
> ip: 192.168.0.1
> mount -t nfs install:myclub.com:/export/home /mnt
> mounts directory without any error
>
> 3. client2
> name: moon.myclub.com
> OS: squeeze (Debian)
> ip: 192.168.0.64
> mount -t nfs install:myclub.com:/export/home /mnt
> mounts directory without any error
>
> 4. client3 (nfs server itself)
> name: install.myclub.com
> OS: wheeze (Debian)
> ip: 192.168.0.62
> mount -t nfs 192.168.0.62:/export/home /mnt
> mounts directory without any error
>
> 5. client4 (nfs server itself)
> name: install.myclub.com
> OS: wheeze (Debian)
> ip: 192.168.0.62
> mount -t nfs install:/export/home /mnt
> mounts fails with an error
>
> mount -v -t nfs install:/export/home /mnt
> mount.nfs: timeout set for Thu Apr 24 01:21:36 2014
> mount.nfs: trying text-based options
> 'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
> mount.nfs: mount(2): Permission denied
> mount.nfs: access denied by server while mounting install:/export/home
>
> mount -v -t nfs install.myclub.com:/export/home /mnt
> mount.nfs: timeout set for Thu Apr 24 01:22:50 2014
> mount.nfs: trying text-based options
> 'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
> mount.nfs: mount(2): Permission denied
> mount.nfs: access denied by server while mounting
> install.myclub.com:/export/home
>
> The error indicates that when I attempt to mount by using FQDN of nfs server
> -- the name resolves to 127.0.1.1 and client resolves to 127.0.0.1 .
>
> cat /etc/hosts
> 127.0.0.1   localhost
> 127.0.1.1   install.myclub.com  install
>
> If I modify /etc/hosts to
>
> cat /etc/hosts
> 127.0.0.1   localhost
> #127.0.1.1  install.myclub.com  install
>
> then
>
> mount -v -t nfs install.myclub.com:/export/home /mnt
> mount.nfs: timeout set for Thu Apr 24 01:29:50 2014
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.0.62,clientaddr=192.168.0.62'
>
> mounts directory without any error, while
>
> mount -v -t nfs install:/export/home /mnt
> mount.nfs: timeout set for Thu Apr 24 01:29:27 2014
> mount.nfs: trying text-based options
> 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1'
> mount.nfs: mount(2): Permission denied
> mount.nfs: access denied by server while mounting install:/export/home
>
> I do not recall when a record "127.0.1.1" appear in /etc/hosts (Squeezy and
> Wheeze both have it) for first time, it is default record added during
> installation.
>
> I puzzled and run out of ideas why nfs server is not able to mount own
> exported directory. I see that "mount" tries to mount through loopback and
> for some inexplicable to me reason it fails. Why does it happen?

The "127.0.1.1" entry is a good thing...

Can you mount the nfs share locally using 127.0.0.1, 127.0.1.1, or the
dhcp-supplied ip address?

Can you mount the share locally when you add "-o vers=3" to the above mounts?

What's in "/etc/exports"?

What's in "/etc/hosts.allow" and "/etc/hosts.deny"?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=syn7_ubqh5yc2o17gegwrk0bzhd8lmavm4p2pl8d1a...@mail.gmail.com

Re: Q: nfs server fails to mount own exported resource, but other client able to mount

2014-04-24 Thread Ron Leach 

Escaped from list (:

On 24/04/2014 09:49, Snow Leopard wrote:

Hi,

I came across strange "mount" problem on nfs server -- it refuses to
mount it's own directory while other nfs clients able mount nfs server
exported directoryjust fine

1. nfs server
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
/etc/exports: /export/home 192.163.0.0/24(rw,subtree_check)
drxwrxwrxw /export/home

2. client1
name: meteor.myclub.com
OS: Valhalla (Red Hat 7.3)
ip: 192.168.0.1
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

3. client2
name: moon.myclub.com
OS: squeeze (Debian)
ip: 192.168.0.64
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

4. client3 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs 192.168.0.62:/export/home /mnt
mounts directory without any error

5. client4 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs install:/export/home /mnt
mounts fails with an error

mount -v -t nfs install:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:21:36 2014
mount.nfs: trying text-based options
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting install:/export/home

mount -v -t nfs install.myclub.com:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:22:50 2014
mount.nfs: trying text-based options
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting
install.myclub.com:/export/home

The error indicates that when I attempt to mount by using FQDN of nfs
server -- the name resolves to 127.0.1.1 and client resolves to
127.0.0.1 .




I wonder if it is letting you mount as 'nfs' when you supply the IP
address, but is not letting you mount as 'nfs' when you try to address
the device locally (which doesn't surprise me).

While I don't use mount, I do use fstab to mount the device containing
our nfs export, locally

/dev/md5 /mnt/point ext4 rw,auto,users,exec

(and a mount command can be similarly constructed).

Isn't the 'right' way to mount local filesystems directly as 'ext4' or
whatever, and only mount as 'nfs' if the filesystem has to be accessed
at another IP address?

regards, Ron


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5358ef18.3040...@tesco.net

Q: nfs server fails to mount own exported resource, but other client able to mount

2014-04-24 Thread Snow Leopard 

Hi,

I came across strange "mount" problem on nfs server -- it refuses to 
mount it's own directory while other nfs clients able mount nfs server 
exported directoryjust fine


1. nfs server
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
/etc/exports:   /export/home 192.163.0.0/24(rw,subtree_check)
drxwrxwrxw  /export/home

2. client1
name: meteor.myclub.com
OS: Valhalla (Red Hat 7.3)
ip: 192.168.0.1
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

3. client2
name: moon.myclub.com
OS: squeeze (Debian)
ip: 192.168.0.64
mount -t nfs install:myclub.com:/export/home /mnt
mounts directory without any error

4. client3 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs 192.168.0.62:/export/home /mnt
mounts directory without any error

5. client4 (nfs server itself)
name: install.myclub.com
OS: wheeze (Debian)
ip: 192.168.0.62
mount -t nfs install:/export/home /mnt
mounts fails with an error

mount -v -t nfs install:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:21:36 2014
mount.nfs: trying text-based options 
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'

mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting install:/export/home

mount -v -t nfs install.myclub.com:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:22:50 2014
mount.nfs: trying text-based options 
'vers=4,addr=127.0.1.1,clientaddr=127.0.0.1'

mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 
install.myclub.com:/export/home


The error indicates that when I attempt to mount by using FQDN of nfs 
server -- the name resolves to 127.0.1.1 and client resolves to 127.0.0.1 .


cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   install.myclub.com  install

If I modify /etc/hosts to

cat /etc/hosts
127.0.0.1   localhost
#127.0.1.1  install.myclub.com  install

then

mount -v -t nfs install.myclub.com:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:29:50 2014
mount.nfs: trying text-based options 
'vers=4,addr=192.168.0.62,clientaddr=192.168.0.62'


mounts directory without any error, while

mount -v -t nfs install:/export/home /mnt
mount.nfs: timeout set for Thu Apr 24 01:29:27 2014
mount.nfs: trying text-based options 
'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1'

mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting install:/export/home

I do not recall when a record "127.0.1.1" appear in /etc/hosts (Squeezy 
and Wheeze both have it) for first time, it is default record added 
during installation.


I puzzled and run out of ideas why nfs server is not able to mount own 
exported directory. I see that "mount" tries to mount through loopback 
and for some inexplicable to me reason it fails. Why does it happen?


What am I missing?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719621

--- Quote --
The IP address |127.0.1.1|in the second line of this example may not be 
found on some other Unix-like systems. The Debian Installer 
creates this entry for a 
system without a permanent IP address as a workaround for some software 
(e.g., GNOME) as documented in the bug #719621 
.

--- End of Quote ---

Thank you for any clue how this problem can be fixed.

Andy