NFS Cache (?) Issue
Hello,
I run a Debian squeeze NFS Server and a Debian squeeze NFS client. I see a
strange issue, which looks like a cache issue:
I had on the server a directory
drwxrwsr-x 2 dorsch users 4096 15. Feb 2010 shared
on the client that was translated into
drwxrwsr-x 2 nobody users 4096 15. Feb 2010 shared
(I might have had a uid mismatch for a short time for that folder on client
and server).
I wanted to test if it has something todo with the SGID bit on that directory
and did a
# chmod g-s shared
on the server. This had the expected effect on the server
drwxrwxr-x 17 dorsch users 4096 27. Dez 19:25 shared
but the client still shows
drwxrwsr-x 2 nobody users 4096 15. Feb 2010 shared
(see also the file modification date).
The big surprise for me was that this mismatch was even after a reboot of the
client and the server was still there.
Any idea why this information does not get updated on the client is welcome, I
am also happy to provide additional information.
For reference, what I did on the server side:
Setup NFS Server:
=================
# apt-get install nfs-kernel-server
dell:~# cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check)
hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home 192.168.2.27(rw,no_root_squash,subtree_check)
dell:~# cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8)
# for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
dell:~# cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8)
# for further information.
#
portmap: 192.168.2.27
lockd: 192.168.2.27
rquotad: 192.168.2.27
mountd: 192.168.2.27
statd: 192.168.2.27
dell:~#
Make UID matching work with NFSv4:
----------------------------------
dell:/etc/default# diff nfs-common.orig nfs-common
16c16
< NEED_IDMAPD=
---
> NEED_IDMAPD=yes
19c19
For reference, what I did on the client side (happens also when I use without
autoFS):
Mount NFS volumes with AutoFS:
==============================
support automount nfs volumes: /mnt/net/<hostname>/<path>:
----------------------------------------------------------
root@omjuta:~# cat /etc/auto.master.d/net.autofs
/mnt/net -hosts --timeout=60
root@omjuta:~#
# ls -l /mnt/net/dell/home
Make UID matching work with NFSv4:
----------------------------------
root@omjuta:/etc# diff idmapd.conf.orig idmapd.conf
10a11,13
>
> [Translation]
> Method=nsswitch
root@omjuta:/etc#
root@omjuta:~# diff /etc/default/nfs-common.orig /etc/default/nfs-common
16c16
< NEED_IDMAPD=
---
> NEED_IDMAPD=yes
19c19
< NEED_GSSD=
---
> NEED_GSSD=no
root@omjuta:~#
Many thanks,
Rainer
Reply to: