[gentoo-user] [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[gentoo-user] [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

Everybody's favoritest cuddly FOSS personality Theo de Raadt is quoted in
Wikipedia as saying: "NFS4 is not on our roadmap.  It's a horribly bloated
protocol that they keep adding crap to."

The latest nfs-utils package demonstrates why he's annoyed with NFS4:

This morning I got this when mounting an nfs share that's been working for
many months:

#mount.nfs -v a6:/usr/portage /usr/portage/
mount.nfs: timeout set for Sun Feb  1 13:09:39 2015
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.84,clientaddr=192.168.1.84'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified

Note the "vers=4.2", which is brand new behavior.  My kernel doesn't have
any config option for nfs-4.2 because I've never enabled nfs-4.1 and the
4.2 option is invisible in menuconfig without it.  Who knew?

So, you either need to enable nfs-4.1 *and* nfs-4.2 in your kernel, or start
using the nfsvers=4 mount option in fstab.

Anyone got an opinion on the need for nfs-4.2?  Is it better, or just newer?
I was happy with nfs3 until it stopped working for reasons I still don't
understand :(

[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

On 02/01/2015 01:18 PM, walt wrote:
> I was happy with nfs3 until it stopped working for reasons I still don't
> understand :(

Well, nfs3 still works, but only after failing on the first attempt:

#mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs indefinitely
until I hit Ctrl-C.  If I then repeat the same command immediately the
mount succeeds.  This is the mysterious nfs black magic I've run into many
times over the years and makes me dread nfs updates.

I'm going to remove nfs4* support completely from the kernel and nfs-utils
now just as a voodoo trial (on a vbox guest, that is :)

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[wabenbau]

Am Sonntag, 01.02.2015 um 14:41
schrieb walt <w41ter@gmail.com>:

> On 02/01/2015 01:18 PM, walt wrote:
> > I was happy with nfs3 until it stopped working for reasons I still
> > don't understand :(
> 
> Well, nfs3 still works, but only after failing on the first attempt:
> 
> #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs
> indefinitely until I hit Ctrl-C.  If I then repeat the same command
> immediately the mount succeeds.  This is the mysterious nfs black
> magic I've run into many times over the years and makes me dread nfs
> updates.

Here is the postinstall info from the update to nfs-utils-1.3.1-r1.
Maybe you run into that. 

"If you use OpenRC, the nfsmount service has been replaced with
nfsclient. If you were using nfsmount, please add nfsclient and
netmount to the same runlevel as nfsmount."

Regards
wabe

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Mon, 2 Feb 2015 00:32:34 +0100, wabenbau@gmail.com wrote:

> > #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs
> > indefinitely until I hit Ctrl-C.  If I then repeat the same command
> > immediately the mount succeeds.  This is the mysterious nfs black
> > magic I've run into many times over the years and makes me dread nfs
> > updates.  
> 
> Here is the postinstall info from the update to nfs-utils-1.3.1-r1.
> Maybe you run into that. 
> 
> "If you use OpenRC, the nfsmount service has been replaced with
> nfsclient. If you were using nfsmount, please add nfsclient and
> netmount to the same runlevel as nfsmount."

It's got nothing to do with the init system used. That message tells you
what to do to try to mount the NFS shares when you boot, but unless you
have suitable mount options or kernel config, that attempt will fail.


-- 
Neil Bothwick

Why is the word abbreviation so long?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

On 02/01/2015 03:32 PM, wabenbau@gmail.com wrote:
> Am Sonntag, 01.02.2015 um 14:41
> schrieb walt <w41ter@gmail.com>:
> 
>> On 02/01/2015 01:18 PM, walt wrote:
>>> I was happy with nfs3 until it stopped working for reasons I still
>>> don't understand :(
>>
>> Well, nfs3 still works, but only after failing on the first attempt:
>>
>> #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs
>> indefinitely until I hit Ctrl-C.  If I then repeat the same command
>> immediately the mount succeeds.  This is the mysterious nfs black
>> magic I've run into many times over the years and makes me dread nfs
>> updates.
> 
> Here is the postinstall info from the update to nfs-utils-1.3.1-r1.
> Maybe you run into that. 
> 
> "If you use OpenRC, the nfsmount service has been replaced with
> nfsclient. If you were using nfsmount, please add nfsclient and
> netmount to the same runlevel as nfsmount."

Thanks wabe.  I forgot to mention that I use systemd now, and I've
had to work out a few problems with nfs over past months because our
gentoo systemd scripts are lagging a bit behind upstream, which is
not surprising.

For example, I had to add the rpcbind.service to the multi-user
systemd target because even nfs3 seems to need it. (I knew when I
switched to systemd I was volunteering for some extra problems, but
I don't regret it.  Yet ;)

As I said in my earlier post, I've now disabled nfs4 in both kernel
and nfs-utils on all my machines, with the same result:  the first
attempt to mount an nfs3 share hangs indefinitely, but if I kill the
mount process and repeat it immediately, the mount succeeds.

I'd love to know if anyone else can reproduce this problem with nfs3
on either OpenRC or systemd.

Thanks!

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[wabenbau]

Am Montag, 02.02.2015 um 00:12
schrieb Neil Bothwick <neil@digimed.co.uk>:

> On Mon, 2 Feb 2015 00:32:34 +0100, wabenbau@gmail.com wrote:
> 
> > > #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs
> > > indefinitely until I hit Ctrl-C.  If I then repeat the same
> > > command immediately the mount succeeds.  This is the mysterious
> > > nfs black magic I've run into many times over the years and makes
> > > me dread nfs updates.  
> > 
> > Here is the postinstall info from the update to nfs-utils-1.3.1-r1.
> > Maybe you run into that. 
> > 
> > "If you use OpenRC, the nfsmount service has been replaced with
> > nfsclient. If you were using nfsmount, please add nfsclient and
> > netmount to the same runlevel as nfsmount."
> 
> It's got nothing to do with the init system used. That message tells
> you what to do to try to mount the NFS shares when you boot, but
> unless you have suitable mount options or kernel config, that attempt
> will fail.

Maybe I don't exactly understand what you are trying to tell me because
of my lousy English. 

Of course you also need the right mount options and kernel config. But
since nfsmount doesn't exist anymore, the "rpc stuff" isn't started by
the OpenRC init system until you add nfsclient to the right runlevel. 

Regards
wabe

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[wabenbau]

Am Sonntag, 01.02.2015 um 16:31
schrieb walt <w41ter@gmail.com>:

> Thanks wabe.  I forgot to mention that I use systemd now, and I've
> had to work out a few problems with nfs over past months because our
> gentoo systemd scripts are lagging a bit behind upstream, which is
> not surprising.
> 
> For example, I had to add the rpcbind.service to the multi-user
> systemd target because even nfs3 seems to need it. (I knew when I
> switched to systemd I was volunteering for some extra problems, but
> I don't regret it.  Yet ;)

I'm still on OpenRC and I don't wanna switch to systemd for some
reasons.

> As I said in my earlier post, I've now disabled nfs4 in both kernel
> and nfs-utils on all my machines, with the same result:  the first
> attempt to mount an nfs3 share hangs indefinitely, but if I kill the
> mount process and repeat it immediately, the mount succeeds.

I also have no nfs4 support in my kernel. Here is my kernel config for
the NFS stuff:

CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
# CONFIG_NFSD is not set
CONFIG_NFS_COMMON=y

> I'd love to know if anyone else can reproduce this problem with nfs3
> on either OpenRC or systemd.

I'm using nfs3 since many years but I never had this problem. I'm sorry
that I can't help you.

Regards
wabe

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[wabenbau]

Am Sonntag, 01.02.2015 um 16:31
schrieb walt <w41ter@gmail.com>:

> For example, I had to add the rpcbind.service to the multi-user
> systemd target because even nfs3 seems to need it. (I knew when I

I never used systemd, so I don't know if adding the rpcbind.service to
the multi-user systemd target is also starting rpc.statd. AFAIK this
process is also necessary for a proper working nfs.

This is the rpc stuff running on my nfs client system:

[rpciod]
/sbin/rpcbind
/sbin/rpc.statd --no-notify

Regards
wabe

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Rich Freeman]

On Sun, Feb 1, 2015 at 8:35 PM,  <wabenbau@gmail.com> wrote:
> Am Sonntag, 01.02.2015 um 16:31
> schrieb walt <w41ter@gmail.com>:
>
>> For example, I had to add the rpcbind.service to the multi-user
>> systemd target because even nfs3 seems to need it. (I knew when I
>
> I never used systemd, so I don't know if adding the rpcbind.service to
> the multi-user systemd target is also starting rpc.statd. AFAIK this
> process is also necessary for a proper working nfs.
>

I believe that starting nfs-client.service or nfs-server.service
starts everything needed EXCEPT rpcbind.  I'd have to re-trace
everything, but I think that there are multiple packages involved here
and the upstream units don't include the necessary dependencies (I
think nfs-server depends on rpcbind.target, but nothing in the target
forces the rpcbind service to run - going from memory here).

I believe this is only an issue for serving nfs.  If you're just using
the client then you're fine just starting nfs-client, and systemd will
start that if it mounts the nfs share (such as from fstab).

-- 
Rich

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Mon, 2 Feb 2015 02:01:11 +0100, wabenbau@gmail.com wrote:

> > It's got nothing to do with the init system used. That message tells
> > you what to do to try to mount the NFS shares when you boot, but
> > unless you have suitable mount options or kernel config, that attempt
> > will fail.  
> 
> Maybe I don't exactly understand what you are trying to tell me because
> of my lousy English. 
> 
> Of course you also need the right mount options and kernel config. But
> since nfsmount doesn't exist anymore, the "rpc stuff" isn't started by
> the OpenRC init system until you add nfsclient to the right runlevel. 
> 
The problem is that the mount command fails g=however you run it, from
either init system or from a shell. It fails with "invalid mount options"
because it now defaults to NFS V4.2 even if it is not enabled in
the kernel. You need to either enable 4.2 or specifically set nfsver=4 to
work around this.


-- 
Neil Bothwick

"Unthinking respect for authority is the greatest enemy of truth."
 (Albert Einstein)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[wabenbau]

Am Montag, 02.02.2015 um 08:37
schrieb Neil Bothwick <neil@digimed.co.uk>:

> On Mon, 2 Feb 2015 02:01:11 +0100, wabenbau@gmail.com wrote:
> 
> > > It's got nothing to do with the init system used. That message
> > > tells you what to do to try to mount the NFS shares when you
> > > boot, but unless you have suitable mount options or kernel
> > > config, that attempt will fail.  
> > 
> > Maybe I don't exactly understand what you are trying to tell me
> > because of my lousy English. 
> > 
> > Of course you also need the right mount options and kernel config.
> > But since nfsmount doesn't exist anymore, the "rpc stuff" isn't
> > started by the OpenRC init system until you add nfsclient to the
> > right runlevel. 
> > 
> The problem is that the mount command fails g=however you run it, from
> either init system or from a shell. It fails with "invalid mount
> options" because it now defaults to NFS V4.2 even if it is not
> enabled in the kernel. You need to either enable 4.2 or specifically
> set nfsver=4 to work around this.

Thanks for the explanation. My NFS servers are running Ubuntu 14.04.1
LTS. Only my clients are gentoo systems. And on the clients I have no
NFS 4 support in the kernel and I also don't have to specify nfsver=4. 
Maybe this problem only occurs with recent NFS versions on the server.

Regards
wabe

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Stefan G. Weichinger]

On 02.02.2015 16:19, wabenbau@gmail.com wrote:

> Thanks for the explanation. My NFS servers are running Ubuntu 14.04.1
> LTS. Only my clients are gentoo systems. And on the clients I have no
> NFS 4 support in the kernel and I also don't have to specify nfsver=4. 
> Maybe this problem only occurs with recent NFS versions on the server.

didn't read the whole thread, sorry ... but I also noticed my
nfsv4-server stopped working with that latest update.

Some systemd-service-files were renamed and/or removed, right?

Any working howtos anywhere?

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Rich Freeman]

On Mon, Feb 2, 2015 at 10:19 AM,  <wabenbau@gmail.com> wrote:
>
> Thanks for the explanation. My NFS servers are running Ubuntu 14.04.1
> LTS. Only my clients are gentoo systems. And on the clients I have no
> NFS 4 support in the kernel and I also don't have to specify nfsver=4.
> Maybe this problem only occurs with recent NFS versions on the server.
>

I've been running an nfs-root setup on a gentoo box (served from a
gentoo server) and I've run into a few issues along the way -
sometimes as a result of kernel upgrades.  Honestly, NFS seems like a
big bucket of fail to me - the older versions mostly work, but rely on
a cobblework of daemons/layers to provide various features and it is
completely insecure.  NFSv4 might as well be a completely different
filesystem and seems fairly complex to get working in a secure fashion
(kerberos, etc).  I could only imagine what it would be like to get it
to work for my root filesystem with PXE boot.

Whenever I run into people and talk to them about file servers on
linux it seems like they tend to end up just using samba (not even
POSIX) or something like sshfs (which is also a bit of a hack, but one
which seems far simpler to use).

It just seems like this is a huge gaping hole for linux to have.  That
said, fixing all the issues could have some far-reaching changes, like
switching to GUIDs for UIDs.

-- 
Rich

[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Holger Hoffstätte]

On Mon, 02 Feb 2015 16:33:53 +0100, Stefan G. Weichinger wrote:

> didn't read the whole thread, sorry ... but I also noticed my
> nfsv4-server stopped working with that latest update.
> 
> Some systemd-service-files were renamed and/or removed, right?

No, it's (ironically) a systemd-specific bug. openrc was fixed in -r1.

> Any working howtos anywhere?

https://bugs.gentoo.org/show_bug.cgi?id=538372

Explanations & fixes.I have it running on both server & client (with 
openrc). Refusing to set NFS_V4_2 on the client may break things since 
it's apparently the default for protocol negotiation, but that seems to 
fail when it's not even enabled in the kernel. So just set it.

-h

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Rich Freeman]

On Mon, Feb 2, 2015 at 10:55 AM, Holger Hoffstätte
<holger.hoffstaette@googlemail.com> wrote:
> On Mon, 02 Feb 2015 16:33:53 +0100, Stefan G. Weichinger wrote:
>
>> didn't read the whole thread, sorry ... but I also noticed my
>> nfsv4-server stopped working with that latest update.
>>
>> Some systemd-service-files were renamed and/or removed, right?
>
> No, it's (ironically) a systemd-specific bug. openrc was fixed in -r1.

I'm not having any problems with nfs on systemd right now, so it might
only affect users in specific circumstances.

Both the openrc and systemd init.d/unit files were renamed, however,
and this is the subject of a news item on the gentoo-dev mailing list.
The gist of it is in the ewarn messages after you install nfs-utils.

-- 
Rich

Re: [gentoo-user] [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Sun, Feb 1, 2015 at 4:18 PM, walt <w41ter@gmail.com> wrote:
>
> Everybody's favoritest cuddly FOSS personality Theo de Raadt is quoted in
> Wikipedia as saying: "NFS4 is not on our roadmap.  It's a horribly bloated
> protocol that they keep adding crap to."
>
> The latest nfs-utils package demonstrates why he's annoyed with NFS4:
>
> This morning I got this when mounting an nfs share that's been working for
> many months:
>
> #mount.nfs -v a6:/usr/portage /usr/portage/
> mount.nfs: timeout set for Sun Feb  1 13:09:39 2015
> mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.84,clientaddr=192.168.1.84'
> mount.nfs: mount(2): Invalid argument
> mount.nfs: an incorrect mount option was specified
>
> Note the "vers=4.2", which is brand new behavior.  My kernel doesn't have
> any config option for nfs-4.2 because I've never enabled nfs-4.1 and the
> 4.2 option is invisible in menuconfig without it.  Who knew?
>
> So, you either need to enable nfs-4.1 *and* nfs-4.2 in your kernel, or start
> using the nfsvers=4 mount option in fstab.
>
> Anyone got an opinion on the need for nfs-4.2?  Is it better, or just newer?
> I was happy with nfs3 until it stopped working for reasons I still don't
> understand :(

I've been setting "-o nfsvers=<vers>" systematically ever since nfsv4
was released... :(

You can use "/etc/nfsmount.conf" to control the behavior of mount.nfs{,4}.

Do you have "net-fs/nfs-utils nfsv41" in package.use? In the eix
output below, nfs-utils is compiled with "-nfsv41" by default:

# eix nfs-utils
[I] net-fs/nfs-utils
     Available versions:  1.2.9-r3^t ~1.3.0-r1^t 1.3.1-r1^t
~1.3.2-r1^t {caps ipv6 kerberos +libmount nfsdcld +nfsidmap +nfsv4
nfsv41 selinux tcpd +uuid}
     Installed versions:  1.3.1-r1^t(10:47:45 AM 01/27/2015)(libmount
nfsidmap nfsv4 uuid -caps -ipv6 -kerberos -nfsdcld -nfsv41 -selinux
-tcpd)
     Homepage:            http://linux-nfs.org/
     Description:         NFS client and server daemons

Should mount.nfs4 try an nfs4.1 mount if nfs-utils is compiled with
"-nfsv41"? Or is the use flag intended for rpc.nfsd only?

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Stefan G. Weichinger]

On 02.02.2015 16:55, Holger Hoffstätte wrote:

> https://bugs.gentoo.org/show_bug.cgi?id=538372
> 
> Explanations & fixes.I have it running on both server & client (with 
> openrc). Refusing to set NFS_V4_2 on the client may break things since 
> it's apparently the default for protocol negotiation, but that seems to 
> fail when it's not even enabled in the kernel. So just set it.

thanks for the pointer.

I applied the patch from Comment 9 to nfs-utils-1.3.2-r1 but
rpc-statd.service doesn't start either.

Do I have to downgrade as well?
I don't fully understand that from the comments there.

Stefan

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Sun, Feb 1, 2015 at 7:31 PM, walt <w41ter@gmail.com> wrote:
>
> For example, I had to add the rpcbind.service to the multi-user
> systemd target because even nfs3 seems to need it.

You must mean "because especially nfsv3 needs it" because,
theoretically, nfsv4 doesn't need rpcbind since an nfsv4 mount only
needs to now about rpc.nfsd's default port 2049.

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Sun, Feb 1, 2015 at 9:15 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> I believe that starting nfs-client.service or nfs-server.service
> starts everything needed EXCEPT rpcbind.  I'd have to re-trace
> everything, but I think that there are multiple packages involved here
> and the upstream units don't include the necessary dependencies (I
> think nfs-server depends on rpcbind.target, but nothing in the target
> forces the rpcbind service to run - going from memory here).

Wansn't it that the nfs units were changed from requiring
rpcbind.service to requiring rpcbind.target but rpcbind wasn't
shipping rpcbind.target?

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Mon, 02 Feb 2015 19:02:24 +0100, Stefan G. Weichinger wrote:

> I applied the patch from Comment 9 to nfs-utils-1.3.2-r1 but
> rpc-statd.service doesn't start either.
> 
> Do I have to downgrade as well?
> I don't fully understand that from the comments there.

You need to set CONFIG_NFS_V4_2.


-- 
Neil Bothwick

Hard work has a future payoff. Laziness pays off NOW!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Stefan G. Weichinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 02.02.2015 um 22:35 schrieb Neil Bothwick:
> On Mon, 02 Feb 2015 19:02:24 +0100, Stefan G. Weichinger wrote:
> 
>> I applied the patch from Comment 9 to nfs-utils-1.3.2-r1 but 
>> rpc-statd.service doesn't start either.
>> 
>> Do I have to downgrade as well? I don't fully understand that
>> from the comments there.
> 
> You need to set CONFIG_NFS_V4_2.

been there, done that.
pre-posting.

;-)

I will just wait a bit ... and follow things.
I don't *need* that nfs-server ...  just used it for portage in my LAN.

sounds lazy maybe ... yes.

;-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUz/CeAAoJEClcuD1V0PzmUOEP/RInQMj92+Y0wl6cisZbp8Cn
GrdxFRTaTrEBIqwQB88Fgglrlm//NuclVEn1UcZ9lcflCEPMlg1n4vwCo++wLjm4
tr8pAROTLImdPZSe4HbJd5zZA8lNyDLWUy259Vh+maPz2HgDATEe24Ht+11HAuBT
6JFMHsLozjZHAHcTJc/JzEHyOMSr4KFHeMnbhiBu78tIa+48u0+Bkju5qsmwXLnw
UJ7i0M+tuypG06AVZO9l8rqPIl3jy2Kpj5h9dp/3azqyOAhXKvKwQLjAYtSfaXja
DS0s4fqntW8yfS+QNA30C/K2bOIPBNlN1P628w0UFRSrqGcJ8C7f+tHE76VbHSWW
J/SfcZ8z/sqHda9BqllBAyOH41bWuXNk7vyF4UUJH0qnSUjmu3CKbuqu5wnyYmUb
qcfho/1wgW2fMGzrzo0qx7d8aULyjroqAnQscJaGm7BbbApwX/wDJzANjw10UWQv
uZ28COImf9HPR7XZ906kkC26lOh4tguj6YWw6CPTAZ1Kjb+XQ4GD08Zfj27iuTA1
Aw5mxkfbP+MEKHuiZIIM6WP6GLoPYWqc4zJEN+Qrm94mR7i/WtUG35TH64ACisXL
zOnZtQScCUhxfy+xjNAXxYuvn242TTI4quEWuMjhLlo1pQdTKYlHOfZqPlOMItIE
R/zzkvzZnseqJIgMAAd4
=K+1g
-----END PGP SIGNATURE-----

[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

On 02/02/2015 10:29 AM, Tom H wrote:
> On Sun, Feb 1, 2015 at 7:31 PM, walt <w41ter@gmail.com> wrote:
>>
>> For example, I had to add the rpcbind.service to the multi-user
>> systemd target because even nfs3 seems to need it.
> 
> You must mean "because especially nfsv3 needs it" because,
> theoretically, nfsv4 doesn't need rpcbind since an nfsv4 mount only
> needs to now about rpc.nfsd's default port 2049.

Tom, you obviously know nfs better than I do, so maybe you can answer
this question for me.

This morning I got "waiting on lockfile foo in /usr/portage/distfiles"
"locking not available" from my nfs3 clients when trying to download
needed source files.

I worked around this failure by using the nfs nolock mount option, and
then I gave up and restored nfs4 to all my kernels and nfs-utils packages.

I don't recall having this problem back in my former nfs3-only days.
Maybe I've forgotten something obvious that I did back then?

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Mon, Feb 2, 2015 at 8:46 PM, walt <w41ter@gmail.com> wrote:
> On 02/02/2015 10:29 AM, Tom H wrote:
>> On Sun, Feb 1, 2015 at 7:31 PM, walt <w41ter@gmail.com> wrote:
>>>
>>> For example, I had to add the rpcbind.service to the multi-user
>>> systemd target because even nfs3 seems to need it.
>>
>> You must mean "because especially nfsv3 needs it" because,
>> theoretically, nfsv4 doesn't need rpcbind since an nfsv4 mount only
>> needs to now about rpc.nfsd's default port 2049.
>
> This morning I got "waiting on lockfile foo in /usr/portage/distfiles"
> "locking not available" from my nfs3 clients when trying to download
> needed source files.
>
> I worked around this failure by using the nfs nolock mount option, and
> then I gave up and restored nfs4 to all my kernels and nfs-utils packages.
>
> I don't recall having this problem back in my former nfs3-only days.
> Maybe I've forgotten something obvious that I did back then?

There used to be an rpc.lockd daemon but lockd's been moved to a
kernel module for nfsv3 and to nfsd for nfsv4. RHEL 5 has it
(nfs-utils 1.09) and RHEL 6 doesn't (nfs-utils 1.2) so it must've been
dropped with v1.1 or v1.2. I don't know when it was dropped in Gentoo
terms (probably 6-7 years ago). Does this ring a bell?

Does file locking work for an nfsv3 mount after you re-enable nfsv4 in
your kernel config?

If yes, then you're missing some kernel config that's being enabled
automatically when you enable nfsv4. I can't think of what it might be
since AFAIK you can't enable NFS_FS or NFSD without enabling
FILE_LOCKING.

If no, then are you setting static ports for statd and lockd and
allowing access to these ports with iptables?

[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

On 02/03/2015 03:29 AM, Tom H wrote:
> On Mon, Feb 2, 2015 at 8:46 PM, walt <w41ter@gmail.com> wrote:

>> This morning I got "waiting on lockfile foo in /usr/portage/distfiles"
>> "locking not available" from my nfs3 clients when trying to download
>> needed source files.

>> I don't recall having this problem back in my former nfs3-only days.
>> Maybe I've forgotten something obvious that I did back then?
> 
> There used to be an rpc.lockd daemon but lockd's been moved to a
> kernel module for nfsv3 and to nfsd for nfsv4. RHEL 5 has it
> (nfs-utils 1.09) and RHEL 6 doesn't (nfs-utils 1.2) so it must've been
> dropped with v1.1 or v1.2. I don't know when it was dropped in Gentoo
> terms (probably 6-7 years ago). Does this ring a bell?

Yes, I remember rpc.lockd.

> Does file locking work for an nfsv3 mount after you re-enable nfsv4 in
> your kernel config?

Hm.  No, I still get the same "No locks available" error.

> If no, then are you setting static ports for statd and lockd and
> allowing access to these ports with iptables?

Noooo, that's way above my pay grade :)

I mentioned earlier in this thread that, when I run this command:

#mount.nfs a6://usr/portage /usr/portage -o nfsvers=3

it hangs indefinitely, but if I hit Ctrl-c and quickly re-run the same
command it succeeds. (I've been trying to measure what "quickly" means
but it seems to vary, seems random, but always less than a minute.)

I'm posting this info mainly for the benefit of future googlers because
nfs4 is working well and I don't really *need* nfs3.

If you're interested in this problem I'd be happy to try any/all debugging
experiments, but otherwise don't spend any more time on it.

Many thanks for your help, Tom

Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Tue, Feb 3, 2015 at 7:05 PM, walt <w41ter@gmail.com> wrote:
> On 02/03/2015 03:29 AM, Tom H wrote:
>> On Mon, Feb 2, 2015 at 8:46 PM, walt <w41ter@gmail.com> wrote:
>>>
>>> This morning I got "waiting on lockfile foo in /usr/portage/distfiles"
>>> "locking not available" from my nfs3 clients when trying to download
>>> needed source files.
>
>>> I don't recall having this problem back in my former nfs3-only days.
>>> Maybe I've forgotten something obvious that I did back then?
>>
>> There used to be an rpc.lockd daemon but lockd's been moved to a
>> kernel module for nfsv3 and to nfsd for nfsv4. RHEL 5 has it
>> (nfs-utils 1.09) and RHEL 6 doesn't (nfs-utils 1.2) so it must've been
>> dropped with v1.1 or v1.2. I don't know when it was dropped in Gentoo
>> terms (probably 6-7 years ago). Does this ring a bell?
>
> Yes, I remember rpc.lockd.
>
>> Does file locking work for an nfsv3 mount after you re-enable nfsv4 in
>> your kernel config?
>
> Hm.  No, I still get the same "No locks available" error.
>
>> If no, then are you setting static ports for statd and lockd and
>> allowing access to these ports with iptables?
>
> Noooo, that's way above my pay grade :)
>
> I mentioned earlier in this thread that, when I run this command:
>
> #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3
>
> it hangs indefinitely, but if I hit Ctrl-c and quickly re-run the same
> command it succeeds. (I've been trying to measure what "quickly" means
> but it seems to vary, seems random, but always less than a minute.)

I now remember you saying earlier. Sorry.

I can't think of how or why!

Does using "mount -v ..." show different outputs for the failing and
successful mounts?


> I'm posting this info mainly for the benefit of future googlers because
> nfs4 is working well and I don't really *need* nfs3.
>
> If you're interested in this problem I'd be happy to try any/all debugging
> experiments, but otherwise don't spend any more time on it.
>
> Many thanks for your help, Tom

You're welcome, with apologies for the delayed response.