[gentoo-user] nfs-utils broken on ~amd64?
Anyone else having problems mounting nfs shares with nfs-utils-1.2.1? 'mount.nfs' complains I'm passing it a bad nfs option no matter what options I give it, including no options. Strace shows that nfs.mount is passing a weird-looking IP address string to the 'mount' system call (man 2 mount), e.g.: mount(k2:/media/d, /mnt/nfs, nfs, 0, addr=192.168.0.100,vers=4,client...) = -1 EINVAL ^^ When I revert back to nfs-utils-1.1.4-r1 the IP address string is back to normal and the mount works correctly, e.g.: mount(k2:/media/d, /mnt/nfs, nfs, 0, addr=192.168.0.100) = 0 Something is tacking on those extra chars after the IP address, but I'm not sure yet where that string is actually generated. Any ideas?
[gentoo-user] check for nfs systems offered for mounting
Is there anyway to check for nfs filesystems that are mountable? Something like smbclient can do for cifs/smb shares. equery tools nfs-utils doesn't show anything likely.
Re: [gentoo-user] NFS and portage tree
On 09 November 2007, Neil Bothwick wrote: On Fri, 9 Nov 2007 12:06:11 +0200, Uwe Thiem wrote: Since some update lately, A can not nfs mount /usr/portage (or anything else) from B. NFS mount is broken. I know that emerging nfs-utils will cure the problem. On the other hand, I can not emerge nfs-utils on A without nfs working. Hic rhodos, hic salta! Set compatible CFLAGS etc. on B and emerge --buildpkgonly nfs-utils. Then copy the package from $PKGDIR/All/nfs-utils-* to A using sneakernet and unpack it into /. Then mount /usr/portage and emerge nfs-utils to make sure it is installed properly. Thanks, Neil. Fortunately, the idea about a livecd and chroot worked. A can nfs mount again. Alternative, and less kludgy, solution. Tar up /usr/portage on B, unpack it on A. Too big a thing for A. There is a reason why it doesn't have its own portage tree. ;-) Uwe -- If a man speaks in a forest, and no woman listens to him, is he still lying? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] NFS and portage tree
On Fri, 9 Nov 2007 12:06:11 +0200, Uwe Thiem wrote: Since some update lately, A can not nfs mount /usr/portage (or anything else) from B. NFS mount is broken. I know that emerging nfs-utils will cure the problem. On the other hand, I can not emerge nfs-utils on A without nfs working. Hic rhodos, hic salta! Set compatible CFLAGS etc. on B and emerge --buildpkgonly nfs-utils. Then copy the package from $PKGDIR/All/nfs-utils-* to A using sneakernet and unpack it into /. Then mount /usr/portage and emerge nfs-utils to make sure it is installed properly. Alternative, and less kludgy, solution. Tar up /usr/portage on B, unpack it on A. This reminds me of why I let each machine have its own portage tree and run a local rsync mirror :) -- Neil Bothwick Do not meddle in the affairs of dragons, for thou art crunchy. signature.asc Description: PGP signature
[gentoo-user] NFS and portage tree
Hi folks, here comes an interesting little problem. I have two boxes, A and B, both running gentoo. Box B has got a full portage tree, box A has none but nfs mounts it from B. This has worked for me for several years. Since some update lately, A can not nfs mount /usr/portage (or anything else) from B. NFS mount is broken. I know that emerging nfs-utils will cure the problem. On the other hand, I can not emerge nfs-utils on A without nfs working. Hic rhodos, hic salta! Anybody with an idea other than re-installing A? Hm... Maybe with a livecd and chrooting. Uwe -- If a man speaks in a forest, and no woman listens to him, is he still lying? -- [EMAIL PROTECTED] mailing list
[gentoo-user] NFS Server
Hi there everyody, Im trying to run a nfs server here, but im having some problems. My kernel is compiled to work with NFS as server or client and ive already emerge nfs-utils. Ok, but when i was starting the server, look what appears: (the /etc/exports is OK) br slackware # /etc/init.d/nfs status * status: stopped br slackware # /etc/init.d/nfs start * Starting idmapd ... [ ok ] * Starting NFS statd ... [ ok ] * Exporting NFS directories ... [ ok ] * Starting NFS daemon ... * Error starting NFS daemon [ !! ] * Starting NFS mountd ... Cannot register service: RPC: Timed out * Error starting NFS mountd [ !! ] br slackware # Well, slackware is only the directory that i was when i've tried to start the nfs :-) the dist. is Gentoo Does anyone knows what is happening ? Thanks for any awnser, Bruno Gola -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] NFS Server
Bruno, Looks like portmap isnt started. Make sure portmap is started would be what I would do next. P Bruno Gola wrote: Hi there everyody, Im trying to run a nfs server here, but im having some problems. My kernel is compiled to work with NFS as server or client and ive already emerge nfs-utils. Ok, but when i was starting the server, look what appears: (the /etc/exports is OK) br slackware # /etc/init.d/nfs status * status: stopped br slackware # /etc/init.d/nfs start * Starting idmapd ...[ ok ] * Starting NFS statd ... [ ok ] * Exporting NFS directories ... [ ok ] * Starting NFS daemon ... * Error starting NFS daemon [ !! ] * Starting NFS mountd ... Cannot register service: RPC: Timed out * Error starting NFS mountd [ !! ] br slackware # Well, slackware is only the directory that i was when i've tried to start the nfs :-) the dist. is Gentoo Does anyone knows what is happening ? Thanks for any awnser, Bruno Gola -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] NFS Server
Make sure portmap is installed... :) On 10/9/05, Bruno Gola [EMAIL PROTECTED] wrote: Hi there everyody, Im trying to run a nfs server here, but im having some problems. My kernel is compiled to work with NFS as server or client and ive already emerge nfs-utils. Ok, but when i was starting the server, look what appears: (the /etc/exports is OK) br slackware # /etc/init.d/nfs status * status: stopped br slackware # /etc/init.d/nfs start * Starting idmapd ... [ ok ] * Starting NFS statd ... [ ok ] * Exporting NFS directories ... [ ok ] * Starting NFS daemon ... * Error starting NFS daemon [ !! ] * Starting NFS mountd ... Cannot register service: RPC: Timed out * Error starting NFS mountd [ !! ] br slackware # Well, slackware is only the directory that i was when i've tried to start the nfs :-) the dist. is Gentoo Does anyone knows what is happening ? Thanks for any awnser, Bruno Gola -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] NFS Server
Oscar Carlsson wrote: Make sure portmap is installed... :) On 10/9/05, Bruno Gola [EMAIL PROTECTED] wrote: Hi there everyody, Im trying to run a nfs server here, but im having some problems. My kernel is compiled to work with NFS as server or client and ive already emerge nfs-utils. Ok, but when i was starting the server, look what appears: (the /etc/exports is OK) br slackware # /etc/init.d/nfs status * status: stopped br slackware # /etc/init.d/nfs start * Starting idmapd ... [ ok ] * Starting NFS statd ... [ ok ] * Exporting NFS directories ... [ ok ] * Starting NFS daemon ... * Error starting NFS daemon [ !! ] * Starting NFS mountd ... Cannot register service: RPC: Timed out * Error starting NFS mountd [ !! ] br slackware # Well, slackware is only the directory that i was when i've tried to start the nfs :-) the dist. is Gentoo Does anyone knows what is happening ? Thanks for any awnser, Bruno Gola -- gentoo-user@gentoo.org mailing list The problem was that my loopback network wasnt working before i've update... thanks for the comment! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] check for nfs systems offered for mounting
On Tuesday 28 July 2009 23:11:44 Harry Putnam wrote: Is there anyway to check for nfs filesystems that are mountable? Something like smbclient can do for cifs/smb shares. equery tools nfs-utils doesn't show anything likely. showmount -e [ip|hostname] part of sys-fs/nfs-utils It shows the server's exports list with directory and allowed IP range -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mount.nfs stale nfs handle
On Sun, 29 Jun 2014 21:34:07 +0200, Alexander Puchmayr wrote: After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. [snip] Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. That's not the latest nfs-utils in stable, it is 1.2.9-r3. Are you using openrc or systemd? There was a problem with some systemd service files in recent nfs-utils releases, fixed now. -- Neil Bothwick I'm not anti-social, I'm just not user friendly signature.asc Description: PGP signature
[gentoo-user] Re: nfs-utils update fails to compile: missing rpc/auth_gss.h
On 2017-05-15, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > During a routine update, emerge failed to compile nfs-utils: > > [...] > > context.c:40:26: fatal error: rpc/auth_gss.h: No such file or directory >#include And of course immediatly after posting this, I _did_ find it in bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=618544 I guess I'll block the nfs-utils update for the present. -- Grant Edwards grant.b.edwardsYow! Kids, don't gross me at off ... "Adventures with gmail.comMENTAL HYGIENE" can be carried too FAR!
[gentoo-user] OT - Need help with nfs after migrating to a new box
I've emerged nfs-utils on the new box and copied /etc/exports over from
the old box, but when I try to start nfs on the new box I get this:
baby ~ # /etc/init.d/nfs start
* Starting idmapd ...
[ ok ]
* Starting gssd ...
[ ok ]
* Starting svcgssd ...
[ !! ]
* Exporting NFS directories ...
exportfs: /etc/exports [1]: Neither 'subtree_check' or
'no_subtree_check' specified for export 70.234.122.250:/backup.
Assuming default behaviour ('subtree_check').
NOTE: this default will change with nfs-utils version 1.1.0
exportfs: /etc/exports [2]: Neither 'subtree_check' or
'no_subtree_check' specified for export
70.234.122.250:/home/michael/camera.
Assuming default behaviour ('subtree_check').
NOTE: this default will change with nfs-utils version 1.1.0
camille.espersunited.com:/home/michael/webspace/html/camera: Function
not implement [ ok ]
* Starting NFS daemon ...
* Error starting NFS daemon
[ !! ]
* Starting NFS mountd ...
* Error starting NFS mountd
[ !! ]
All /var/log/messages has to say on the subject is:
Apr 27 10:43:51 baby exportfs[17086]: /etc/exports [1]: Neither
'subtree_check' or 'no_subtree_check' specified for export
70.234.122.250:/backup. Assuming default behaviour
('subtree_check'). NOTE: this default will change with nfs-utils
version 1.1.0
Apr 27 10:43:51 baby exportfs[17086]: /etc/exports [2]: Neither
'subtree_check' or 'no_subtree_check' specified for export
70.234.122.250:/home/michael/camera. Assuming default behaviour
('subtree_check'). NOTE: this default will change with nfs-utils
version 1.1.0
Any hints?
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] mount.nfs stale nfs handle
Am Sonntag, 29. Juni 2014, 20:41:55 schrieb Neil Bothwick: On Sun, 29 Jun 2014 21:34:07 +0200, Alexander Puchmayr wrote: After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. [snip] Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. That's not the latest nfs-utils in stable, it is 1.2.9-r3. This morning it was masked; OK, emerge --sync emerge nfs-utils. After restarting all nfs relevant services it is still the same :-( Are you using openrc or systemd? There was a problem with some systemd service files in recent nfs-utils releases, fixed now. I'm using openrc. Alex
Re: [gentoo-user] mount.nfs stale nfs handle
On Sunday 29 June 2014 22:48:32 Alexander Puchmayr wrote: Am Sonntag, 29. Juni 2014, 20:41:55 schrieb Neil Bothwick: On Sun, 29 Jun 2014 21:34:07 +0200, Alexander Puchmayr wrote: After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. [snip] Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. That's not the latest nfs-utils in stable, it is 1.2.9-r3. This morning it was masked; OK, emerge --sync emerge nfs-utils. After restarting all nfs relevant services it is still the same :-( Just to confirm, did you update nfs-utils on both systems? -- Joost
Re: [gentoo-user] mount.nfs stale nfs handle
Yes. Both client and server have the actual version. Alex Gesendet mit AquaMail für Android http://www.aqua-mail.com Am 30. Juni 2014 09:30:01 schrieb Joost Roeleveld jo...@antarean.org: On Sunday 29 June 2014 22:48:32 Alexander Puchmayr wrote: Am Sonntag, 29. Juni 2014, 20:41:55 schrieb Neil Bothwick: On Sun, 29 Jun 2014 21:34:07 +0200, Alexander Puchmayr wrote: After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. [snip] Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. That's not the latest nfs-utils in stable, it is 1.2.9-r3. This morning it was masked; OK, emerge --sync emerge nfs-utils. After restarting all nfs relevant services it is still the same :-( Just to confirm, did you update nfs-utils on both systems? -- Joost !DSPAM:506,53b10f55576434764113543!
Re: [gentoo-user] nfs warning: mount version older than kernel
On 9/22/05, Dave Nebinger [EMAIL PROTECTED] wrote: dragonfly ~ # uname -a Linux dragonfly 2.6.12-gentoo-r6 #3 Thu Aug 4 06:43:20 PDT 2005 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux dragonfly ~ # myth14 ~ # uname -a Linux myth14 2.6.12-gentoo-r6 #2 Tue Aug 2 16:31:31 PDT 2005 i686 Intel(R) Celeron(R) CPU 2.26GHz GenuineIntel GNU/Linux myth14 ~ # What versions of nfs-utils are installed on the systems? Sorry. I printed that here in a terminal and the forgot to copy it into the first message. 1.06-r6 on both systems: dragonfly ~ # emerge -pv nfs-utils These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-fs/nfs-utils-1.0.6-r6 +tcpd 0 kB Total size of downloads: 0 kB dragonfly ~ # myth14 ~ # emerge -pv nfs-utils These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-fs/nfs-utils-1.0.6-r6 +tcpd 0 kB Total size of downloads: 0 kB myth14 ~ # -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge stalls - what to do ?
Zac Medico schrieb: There are also nfs services that you need to run on the client side. Maybe you need to do something like this: emerge --noreplace nfs-utils rc-update add nfs default /etc/init.d/nfs start If both client and server side services are running correctly then should just work. Hmm, I don't have nfs running on any of my other boxes (only nfsmount) and the nfs-mounted DISTDIR worked for a long time ... Anyway, I did what you recommended and now emerge runs fine. Might be that the reboot of the NFS-server also helped a bit. Thank you, Stefan -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nfs setup
On 8/31/05, John Dangler [EMAIL PROTECTED] wrote: I'm trying to get nfs setup between my gentoo boxes (both local)on the server, grep NFS /usr/src/linux/.config (on the server) returns:CONFIG_NFS_FS=mCONFIG_NFS_V3=yCONFIG_NFS_V4 is not setCONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=mCONFIG_NFSD_V4 is not setCONFIG_NFSD_TCP=yAre these settings right to get nfs working ?Thanks for the input.Those look ok but you will have to modprobe NFS and NFSD into the kernel NFSD only on the server to make it work. You will also need to emerge nfs-utils. Also make sure to add the NFS modules to your modules autoload file in case the power goes out and your are forced to reboot. -Mike-- Michael E. CruteSoftware DeveloperSoftGroup Development CorporationLinux, because reboots are for installing hardware.In a world without walls and fences, who needs windows and gates?
Re: [gentoo-user] nfsv4 issues
On Wed, Jul 20, 2016 at 10:51 PM, Adam Carter <adamcart...@gmail.com> wrote:
>> I don't use systemd on Gentoo but for the nfs-utils upstream-shipped
>> systemd units that I think that Gentoo's using, you have to re-run
>> nfs-config.service - or run the script that it calls - in order to
>> update the "/run/sysconfig/nfs-utils" environment file that's sourced
>> by the nfs-server.service unit.
>
> In /usr/lib/systemd/system/nfs-server.service
> [Service]
> EnvironmentFile=/etc/conf.d/nfs
Sorry. Looking at the ebuild, there's:
rm "${D}$(systemd_get_unitdir)"/nfs-config.service || die
sed -i -r \
-e "/^EnvironmentFile=/s:=.*:=${EPREFIX}/etc/conf.d/nfs:" \
-e '/^(After|Wants)=nfs-config.service$/d' \
-e 's:/usr/sbin/rpc.statd:/sbin/rpc.statd:' \
"${D}$(systemd_get_unitdir)"/* || die
so the upstream "nfs-config.service" waltz is avoided.
But that means that the variables in "/etc/conf.d/nfs" aren't renamed.
So the openrc nfs script uses "${OPTS_RPC_NFSD}", which is defined,
and the systemd service uses "$RPCNFSDARGS", which isn't.
>> Does "/var/lib/nfs/v4recovery/" exist?
>
> No
> # ls /var/lib/nfs/
> etab export-lock rmtab rpc_pipefs sm sm.bak state xtab
IIRC, it's needed to avoid this delay. I thought that I'd saved a url
about this but I can't find it.
Do you have a syslog message about "stable storage"? "man nfsdcltrack".
The openrc script has
mkdir_nfsdirs() {
local d
for d in v4recovery v4root ; do
d="/var/lib/nfs/${d}"
[ ! -d "${d}" ] && mkdir -p "${d}"
done
}
but systemd doesn't have anything equivalent. On RHEL and Ubuntu,
"/var/lib/nfs/v4recovery/" is created at installation time. Perhaps
the Gentoo ebuild should do the same or should ship a
"/usr/lib/tmpfiles.d/var-lib-nfs.conf" to create it at boot if it
doesn't exist.
Re: [gentoo-user] [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Sun, Feb 1, 2015 at 4:18 PM, walt w41...@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] NIS/NFS
On 1/23/06, Jeff [EMAIL PROTECTED] wrote: Is showmount a universal command, or is it part of NIS/NFS?It comes with the package nfs-utils in Gentoo. Worked like a charm btw. Thanks much. I've forgotten a lot of thecommands since we've switched to LDAP.Glad it helped!-- Ghislain Bourgeois---Linux System administrator
[gentoo-user] Nfs-utils update
Hello list, Today I was offered an update of net-fs/nfs-utils from 1.3.4 to 1.3.4-r1. It won't compile, complaining that there's no Kerberos v5 with GSS: "consider --disable-gss or --with-krb5=". But there's no Kerberos here and it's not in my USE flags, and if I specify USE=-kerberos on the command line it still fails the same way. Bug 618534 refers. Has anyone else seen this? -- Regards Peter
Re: [gentoo-user] nfsv4 issues
> >> I don't use systemd on Gentoo but for the nfs-utils upstream-shipped
> >> systemd units that I think that Gentoo's using, you have to re-run
> >> nfs-config.service - or run the script that it calls - in order to
> >> update the "/run/sysconfig/nfs-utils" environment file that's sourced
> >> by the nfs-server.service unit.
> >
> > In /usr/lib/systemd/system/nfs-server.service
> > [Service]
> > EnvironmentFile=/etc/conf.d/nfs
>
> Sorry. Looking at the ebuild, there's:
>
>
> rm "${D}$(systemd_get_unitdir)"/nfs-config.service || die
> sed -i -r \
> -e "/^EnvironmentFile=/s:=.*:=${EPREFIX}/etc/conf.d/nfs:" \
> -e '/^(After|Wants)=nfs-config.service$/d' \
> -e 's:/usr/sbin/rpc.statd:/sbin/rpc.statd:' \
> "${D}$(systemd_get_unitdir)"/* || die
>
>
> so the upstream "nfs-config.service" waltz is avoided.
>
> But that means that the variables in "/etc/conf.d/nfs" aren't renamed.
> So the openrc nfs script uses "${OPTS_RPC_NFSD}", which is defined,
> and the systemd service uses "$RPCNFSDARGS", which isn't.
>
I've added $RPCNFSDARGS to /etc/conf.d/nfs, restarted, and the nproc
setting works.
>
> >> Does "/var/lib/nfs/v4recovery/" exist?
> >
> > No
> > # ls /var/lib/nfs/
> > etab export-lock rmtab rpc_pipefs sm sm.bak state xtab
>
> IIRC, it's needed to avoid this delay. I thought that I'd saved a url
> about this but I can't find it.
>
> Do you have a syslog message about "stable storage"? "man nfsdcltrack".
>
There's no message about stable storage, but there's this;
kernel: [578030.628415] NFSD: the nfsdcld client tracking upcall will be
removed in 3.10. Please transition to using nfsdcltrack.
# which nfsdcltrack
which: no nfsdcltrack in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0:/usr/lib64/subversion/bin:/opt/vmware/bin)
# qlist nfs | grep nfsdcltrack
#
> The openrc script has
>
>
> mkdir_nfsdirs() {
> local d
> for d in v4recovery v4root ; do
> d="/var/lib/nfs/${d}"
> [ ! -d "${d}" ] && mkdir -p "${d}"
> done
> }
>
>
> but systemd doesn't have anything equivalent. On RHEL and Ubuntu,
> "/var/lib/nfs/v4recovery/" is created at installation time. Perhaps
> the Gentoo ebuild should do the same or should ship a
> "/usr/lib/tmpfiles.d/var-lib-nfs.conf" to create it at boot if it
> doesn't exist.
>
> I've added the directory, and after restarting syslog now has new entries;
kernel: [912267.948883] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4
state recovery directory
kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
directory
I will test shortly and report back - thanks!
Re: [gentoo-user] nfsv4 issues
On Fri, Jul 22, 2016 at 8:22 PM, Adam Carter <adamcart...@gmail.com> wrote:
>>>> Does "/var/lib/nfs/v4recovery/" exist?
>>>
>>> No
>>> # ls /var/lib/nfs/
>>> etab export-lock rmtab rpc_pipefs sm sm.bak state xtab
>>
>> IIRC, it's needed to avoid this delay. I thought that I'd saved a url
>> about this but I can't find it.
>>
>> Do you have a syslog message about "stable storage"? "man nfsdcltrack".
>
> There's no message about stable storage, but there's this;
> kernel: [578030.628415] NFSD: the nfsdcld client tracking upcall will be
> removed in 3.10. Please transition to using nfsdcltrack.
It's from
https://patchwork.kernel.org/patch/1730241/
> # which nfsdcltrack
> which: no nfsdcltrack in
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0:/usr/lib64/subversion/bin:/opt/vmware/bin)
> # qlist nfs | grep nfsdcltrack
> #
It depends on the nfs-utils USE settings:
# qlist -U nfs-utils
net-fs/nfs-utils (libmount nfsdcld nfsidmap nfsv4 nfsv41)
# qfile $(which nfsdcltrack)
net-fs/nfs-utils (/sbin/nfsdcltrack)
>> The openrc script has
>>
>>
>> mkdir_nfsdirs() {
>> local d
>> for d in v4recovery v4root ; do
>> d="/var/lib/nfs/${d}"
>> [ ! -d "${d}" ] && mkdir -p "${d}"
>> done
>> }
>>
>>
>> but systemd doesn't have anything equivalent. On RHEL and Ubuntu,
>> "/var/lib/nfs/v4recovery/" is created at installation time. Perhaps
>> the Gentoo ebuild should do the same or should ship a
>> "/usr/lib/tmpfiles.d/var-lib-nfs.conf" to create it at boot if it
>> doesn't exist.
>
> I've added the directory, and after restarting syslog now has new entries;
> kernel: [912267.948883] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4
> state recovery directory
> kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
> directory
>
> I will test shortly and report back - thanks!
Good luck. You're welcome.
[gentoo-user] Re: [~amd64] NFS server broken again :(
On 10/27/2014 08:22 PM, Tom H wrote:
The 1.2.9 nfs-utils ebuild has systemd_dounit
${FILESDIR}/nfsd.service where nfsd.service has
Requires=rpcbind.service and After=rpcbind.service.
The 1.3.0 nfs-utils ebuild has systemd_dounit
systemd/*.{mount,service,target} where nfs-server.service has
Requires=rpcbind.target and After=rpcbind.target.
Yes, and that little change caused the breakage that inspired this
thread in the first place :)
I have a Fedora 20 machine running in VirtualBox and I see they've
already fixed the same breakage by going back to 'rpcbind.service'
in their nfs-server.service file.
I see they also define all those $RPCFOO variables in /etc/sysconfig/nfs,
which are mostly null-strings anyway, which is why my nfs server is
working correctly without those variables.
(Working correctly *after* systemctl enable rpcbind, that is.)
[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
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] NFS configuration (tcp/ip MythTV)
On 8/2/05, Michael Crute [EMAIL PROTECTED] wrote: I would use 'sudo netstat -lp | grep nfs' to see what nfs is listening on. -Mike Thanks Mike, it appears that both ends are currently listening on tcp which is good. However, am I not supposed to also use the tcp mount option on the mythbackend server to tell it to mount /video using tcp? The man pages tell me the default for NFS mounts is udp. Or does the tcp build flag for nfs-utils override all of this? Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Sun, Feb 1, 2015 at 9:15 PM, Rich Freeman ri...@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] emerge stalls - what to do ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan G. Weichinger wrote:
Emerging (1 of 1) x11-libs/libsexy-0.1.11 to /
and then just hangs there, doing nothing.
That's right where it attempts to obtain a lock on the required
files in ${DISTDIR}. If that's on nfs and nfs isn't behaving
properly then it can cause problems like that. Check dmesg.
Correct, my ${DISTDIR} is normally mounted via nfs.
When I umount it, I can emerge ...
When mounted, dmesg gives me
lockd: cannot monitor ${IP_OF_NFS_SERVER}
lockd: failed to monitor ${IP_OF_NFS_SERVER}
What can I do to fix this? Restarting the nfs-service on the server did
not help yet.
There are also nfs services that you need to run on the client side.
Maybe you need to do something like this:
emerge --noreplace nfs-utils
rc-update add nfs default
/etc/init.d/nfs start
If both client and server side services are running correctly then
should just work.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHIQBD/ejvha5XGaMRAjscAKDtMwR9v/kk1si83X6Yw/bL8GscbgCdHGmC
t2spiSHCT+asZE7afFiJIHc=
=TrRr
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Sun, Feb 1, 2015 at 8:35 PM, waben...@gmail.com wrote: Am Sonntag, 01.02.2015 um 16:31 schrieb walt w41...@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] NFS trouble
On Tuesday, 10 March 2020 08:17:41 GMT netfab wrote: > Le 09/03/20 à 17:03, Peter Humphrey a tapoté : > > mount -t nfs 192.168.1.4:/mnt/nfs/portage /mnt/clrn/usr/portage # > > script on the client > > > > Result: > > * Mounting chroot dirs under /mnt/clrn ... > > mount.nfs: mounting 192.168.1.4:/mnt/nfs/portage failed, reason given > > by server: No such file or directory > > [...] > > > Can anyone see the problem? > > From the client, please try this : > > # mkdir /mnt/nfs4 > > # mount -t nfs4 192.168.1.4:/ /mnt/nfs4 > > # ls /mnt/nfs4 According to the following wiki page, with NFSv4 when mounting NFS from the client you use relative paths to the virtual root on the server. https://wiki.gentoo.org/wiki/Nfs-utils Therefore I also think the syntax netfab suggests above is how you should try it in the first instance; e.g.: mount -t nfs 192.168.1.4:portage /mnt/clrn/usr/portage or mount -t nfs 192.168.1.4:/portage /mnt/clrn/usr/portage signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] nfs-utils broken on ~amd64?
On Monday 15 February 2010 21:23:54 walt wrote: Anyone else having problems mounting nfs shares with nfs-utils-1.2.1? 'mount.nfs' complains I'm passing it a bad nfs option no matter what options I give it, including no options. Strace shows that nfs.mount is passing a weird-looking IP address string to the 'mount' system call (man 2 mount), e.g.: mount(k2:/media/d, /mnt/nfs, nfs, 0, addr=192.168.0.100,vers=4,client...) = -1 EINVAL At first glance I suspect you have nfs v4 support and the server does not like it. The USE flag changed at 1.1.6-r1 from nonfsv4 to nfsv4 so if you did not change USE you will get the exact opposite support between the earliest and most recent version in portage. pet hate Don't you just hate negative USE flags on the lines of no* ? You have to switch then on to not get something. Far better to have a positive flag and enable it by default in the profile. Not to mention the confusion that changing it later causes, witness this case here. ^^ When I revert back to nfs-utils-1.1.4-r1 the IP address string is back to normal and the mount works correctly, e.g.: mount(k2:/media/d, /mnt/nfs, nfs, 0, addr=192.168.0.100) = 0 Something is tacking on those extra chars after the IP address, but I'm not sure yet where that string is actually generated. Any ideas? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] check for nfs systems offered for mounting
+++ Harry Putnam [gentoo-user] [Tue, Jul 28, 2009 at 04:11:44PM -0500]: Is there anyway to check for nfs filesystems that are mountable? Something like smbclient can do for cifs/smb shares. equery tools nfs-utils doesn't show anything likely. Perhaps showmount -e host would be what you want? -- // Andrew MacKenzie | http://www.edespot.com // GPG public key: http://www.edespot.com/~amackenz/public.key // Civilization is the limitless multiplication of unnecessary necessities. // -- Mark Twain pgpyHy1ztV07h.pgp Description: PGP signature
Re: [gentoo-user] Is there a lock daemon for managing file locking on an NFS server? [SOLVED]
Neil Walker wrote: Amit Dor-Shifer wrote: e.g. 'lockd'? If so, which ebuild installs it? I abandoned nfs quite a while ago but, afaik, file locking is handled internally by the kernel. Be lucky, Neil http://www.neiljw.com rpc.lockd was removed starting of nfs-utils-1.1.0 (~May 2007). http://sourceforge.net/project/shownotes.php?group_id=14release_id=507588 Thanks to everyone who helped pointing me at the right direction. Amit
[gentoo-user] Re: chicken -- egg (NFS tty video)
On 05/14/2011 06:20 AM, Felix Miata wrote: My #1 problem to solve is NFS not working yet (nfs-utils aka libevent, portmap, rpc emerge failures), but it would also be very nice to get Grub to emerge. Logs: http://fm.no-ip.com/Tmp/Linux/G/ Looking at the config for libevent, the script can't find ccache. Do you have dev-util/ccache installed? Did you enable the 'ccache' FEATURE in /etc/make.conf?
[gentoo-user] nfs.confd.old on manifest not found
Hello, I anyone else bumping into this message after a recent emerge --sync followed by system and world update? !!! A file listed in the Manifest could not be found: /usr/portage/net-fs/nfs-utils/files/nfs.confd.old emerge system will complete but not emerge world. There isn't a bug filed but there is a comment on the issue on a related bug for stability of nfs-utils. Thanks for any inputs. -- Valmor -emerge --info Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.18.6 i686) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
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! pgpQ6Yadr8xMN.pgp Description: OpenPGP digital signature
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On Sat, Jul 26, 2014 at 9:51 AM, Alan McKinnon alan.mckin...@gmail.com wrote:
NFS uses RPC to do some heavy lifting - I don't know how familiar you
are with this, so here's the quick version:
When you mount something locally, and need to use the mounted
filesystem, kernel calls are used to get at the data. This works easily
as the source disk is local and the kernel can get to it. With NFS, the
source disk is remote and it's the remote kernel that must do the
accessing. RPC is a way to safely ask a remote kernel to do something
and get a result that behaves identical to a local kernel call.
Obviously, this is rather hard to implement correctly.
The original RPC was written by Sun and other newer implementations
exist, like libtirpc - to support useful features like not being stuck
with only UDP. That's what the ti means - Transport Independant.
RPC has been in a state of flux for some time and I too have run into
init-script oddities as things change.
In my case, I have nfs-utils-1.3.0, and rc-update configuredd to start
rpc.statd. This works because
depend() {
...
need portmap
...
}
and in the init.d file for rpcbind:
depend() {
...
provide portmap
}
So rpcbind starts at boot time and all my nfs mounts JustWork
To confirm the above, for nfs-utils-1.2.9-r3.
If I start nfs manually, all the associated daemons start too even
though I haven't added them to default (although idmapd is started
because of /etc/conf.d/nfs):
# ls -1 /etc/init.d/rpc*
/etc/init.d/rpc.idmapd
/etc/init.d/rpc.pipefs
/etc/init.d/rpc.statd
/etc/init.d/rpcbind
# rc-update | grep rpc
# rc-service nfs start
* Starting rpcbind ... [ ok ]
* Starting NFS statd ...[ ok ]
* Setting up RPC pipefs ... [ ok ]
* Starting idmapd ... [ ok ]
* Mounting nfsd filesystem in /proc ... [ ok ]
* Exporting NFS directories ... [ ok ]
* Starting NFS mountd ... [ ok ]
* Starting NFS daemon ... [ ok ]
* Starting NFS smnotify ... [ ok ]
#
[gentoo-user] Re: NFS mount fail
Richard Marzan wrote: I get this error when mounting an nfs share: mount.nfs: rpc.statd is not running but is required for remote locking Either use -o nolocks to keep locks local, or start statd. Anyone know what the problem might be? I followed the gentoo-wiki nfs guide @ http://gentoo-wiki.com/HOWTO_Share_Directories_via_NFS rsize and wsize have been set on my client. Did you add nfsmount to the default runlevel? rc-updated add nfsmount default This should start rpc.statd at boot time. You can also start it without rebooting: /etc/init.d/nfsmount start You need to have emerged sys-fs/nfs-utils for this to work. If you have already done all of the above, I'd look at your firewall rules. -- Remy signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Problems with kde and NIS/NFS users
Folks, i've tried install nfs-utils on my client boxes, and guess what !??! it worked !!!. I guess the rpc.statd is started when I start the nfs service on my client box. Anyway, i think my problem is solved(by now :) ) Thax all of you for the time and help. On 6/4/07, Dan Farrell [EMAIL PROTECTED] wrote: On Mon, 4 Jun 2007 15:34:23 -0300 Thiago Lüttig [EMAIL PROTECTED] wrote: When I start kde, i enter a dmesg command and the last output was this: statd: server localhost not responding, timed out rpc.statd needs to be running on NFS client hosts. -- [EMAIL PROTECTED] mailing list -- __ Atenciosamente, Thiago Lüttig MSN: [EMAIL PROTECTED] ICQ: 194392373 __
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On 02.02.2015 16:19, waben...@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] nfsv4 issues
On Sun, Jul 24, 2016 at 3:37 AM, Adam Carter <adamcart...@gmail.com> wrote: > I've added the directory, and after restarting syslog now has new entries; >> >> kernel: [912267.948883] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 >> state recovery directory >> kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery >> directory >> >> I will test shortly and report back - thanks! > > Confirmed - this fixes the 30 second delay. Good. > Should i log a bug for these issues? If I were you, I'd definitely file a bug reports against nfs-utils for: 1) the creation of "/var/lib/nfs/v4recovery/" when systemd is pid 1; 2) the systemd unit compatible envvars.
[gentoo-user] NFS vs. jumbo frames
I've been fiddling with this for some days and can't but assume it's a bug in one of the Gentoo patches to either the kernel or NFS tools: Basically, NFS locking breaks as soon as I enable jumbo frames on both server and client. touch foobar flock foobar ls works fine in my NFS-mounted home with an MTU of 1500. An MTU of 9000 is great for general net throughput so I wanted to use it on both the server and the clients, but the above sequence hangs indefinitely when I try. I'm aware flock() isn't supposed to work correctly with NFS anyway, but all kinds of stuff depends on it at least pretending to. The strange thing is, SuSE 10.1 as a client works fine with jumbo frames, just my Gentoo box doesn't. I tried enabling nfs_debug with sysctl and sniffing the wire with tcpdump and wireshark but with my pretty basic knowledge of NFS workings I didn't spot anything conspicuous other than that lookup(msbethke/foobar) nfs_update_inode(0:18/3424742 ct=1 info=0x6) nfs_fhget(0:18/1081970 ct=1) permission(0:18/1081970), mask=0x4, res=0 seems to be the exchange after which the hang occurs. Our server is running 2.6.18-hardened-r6 and nfs-utils-1.0.12. The clients are mostly SuSE 10.1 boxes with kernel 2.6.16.21-0.21-smp and nfs-utils-1.0.7-36 while my workstation has 2.6.20-gentoo-r6 (was linux-2.6.19-gentoo-r5 before) and the same ns-utils as the server. -- I prefer encrypted and signed messages. KeyID: FAC37665 Fingerprint: 8C16 3F0m A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665 pgpVv5f4MJwd6.pgp Description: PGP signature
[gentoo-user] Re: nfs-utils broken on ~amd64?
On 02/15/2010 12:28 PM, Alan McKinnon wrote: On Monday 15 February 2010 21:23:54 walt wrote: Anyone else having problems mounting nfs shares with nfs-utils-1.2.1? 'mount.nfs' complains I'm passing it a bad nfs option no matter what options I give it, including no options. Strace shows that nfs.mount is passing a weird-looking IP address string to the 'mount' system call (man 2 mount), e.g.: mount(k2:/media/d, /mnt/nfs, nfs, 0, addr=192.168.0.100,vers=4,client...) = -1 EINVAL At first glance I suspect you have nfs v4 support and the server does not like it. The USE flag changed at 1.1.6-r1 from nonfsv4 to nfsv4 so if you did not change USE you will get the exact opposite support between the earliest and most recent version in portage. pet hate Don't you just hate negative USE flags on the lines of no* ? You have to switch then on to not get something. Far better to have a positive flag and enable it by default in the profile. Not to mention the confusion that changing it later causes, witness this case here. I did not include nfs4 in my kernel because it was marked 'experimental'. (Hey, just because I choose to run ~amd64 doesn't mean I'm reckless ;o) I set the 'nonfsv4' USE flag and recompiled nfs-utils but got exactly the same error. The next step is to build a new kernel with nfs4 support and unset the 'nonfsv4' flag, but at the moment I'm running a ver-r-r-y long partition resize with gparted so that I can add more space to my experimental lvm2 volumes. (Working great so far.) I think I'll fall asleep before gparted is finished, so I'll supply more information tomorrow.
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Mon, 2 Feb 2015 00:32:34 +0100, waben...@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? pgpnhFLkIbNZz.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: [~amd64] NFS server broken again :(
On Mon, Oct 27, 2014 at 10:49 PM, Tom H tomh0...@gmail.com wrote:
Does rpcbind.target exist? Does rpcbind.service have a Requires or
Wants for rpcbind.target? Is rpcbind.service enabled?
...
I don't have access to a Gentoo box with nfs at the moment in order to
check this but IIRC Gentoo used to use OPTS_RPC_NFSD, OPTS_RPC_MOUNTD,
OPTS_RPC_STATD but it's now using upstream's RPCNFSDARGS,
RPCMOUNTDARGS, STATDARGS, at least in its systemd units. Again IIRC
the ebuild only changes the upstream EnvironmentFile= value and
deep-sixes nfs-config.service.
I've just had the unoriginal idea of looking at my portage tree's
nfs-utils and rpcbind ebuilds and files...
The 1.2.9 nfs-utils ebuild has systemd_dounit
${FILESDIR}/nfsd.service where nfsd.service has
Requires=rpcbind.service and After=rpcbind.service.
The 1.3.0 nfs-utils ebuild has systemd_dounit
systemd/*.{mount,service,target} where nfs-server.service has
Requires=rpcbind.target and After=rpcbind.target.
The rpcbind ebuild has systemd_dounit ${FILESDIR}/${PN}.service so
there's no ${PN}.target (and there isn't a .target unit in
$FILESDIR).
And, I was wrong:
cat $FILESDIR/nfs.confd
# /etc/conf.d/nfs
# If you wish to set the port numbers for lockd,
# please see /etc/sysctl.conf
# Optional services to include in default `/etc/init.d/nfs start`
# For NFSv4 users, you'll want to add rpc.idmapd here.
NFS_NEEDED_SERVICES=
# Number of servers to be started up by default
OPTS_RPC_NFSD=8
# Options to pass to rpc.mountd
# ex. OPTS_RPC_MOUNTD=-p 32767
OPTS_RPC_MOUNTD=
# Options to pass to rpc.statd
# ex. OPTS_RPC_STATD=-p 32765 -o 32766
OPTS_RPC_STATD=
# Options to pass to rpc.idmapd
OPTS_RPC_IDMAPD=
# Options to pass to rpc.gssd
OPTS_RPC_GSSD=
# Options to pass to rpc.svcgssd
OPTS_RPC_SVCGSSD=
# Options to pass to rpc.rquotad (requires sys-fs/quota)
OPTS_RPC_RQUOTAD=
# Timeout (in seconds) for exportfs
EXPORTFS_TIMEOUT=30
# Options to set in the nfsd filesystem (/proc/fs/nfsd/).
# Format is option=value. Multiple options are allowed.
#OPTS_NFSD=nfsv4leasetime=30 max_block_size=4096
so if you're using the 1.3.0 nfs-utils ebuild, you have to set up the
variables yourself, if you need to pass different values to the
daemons.
RE: [gentoo-user] nfs setup
Mike~ Thanks for the input. I'm going to emerge nfs-utils on the server and client now. I can't wait to get off this win machine! John -Original Message- From: Michael Crute [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 10:09 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] nfs setup On 8/31/05, John Dangler [EMAIL PROTECTED] wrote: I'm trying to get nfs setup between my gentoo boxes (both local) on the server, grep NFS /usr/src/linux/.config (on the server) returns: CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y Are these settings right to get nfs working ? Thanks for the input. Those look ok but you will have to modprobe NFS and NFSD into the kernel NFSD only on the server to make it work. You will also need to emerge nfs-utils. Also make sure to add the NFS modules to your modules autoload file in case the power goes out and your are forced to reboot. -Mike -- Michael E. Crute Software Developer SoftGroup Development Corporation Linux, because reboots are for installing hardware. In a world without walls and fences, who needs windows and gates? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] nfsv4 issues
On Tue, Jul 19, 2016 at 12:49 AM, Adam Carter <adamcart...@gmail.com> wrote: > > I'm trying to troubleshoot a newly setup nfs server, which, sometimes has a > 30 second pause (tcpdump shows its server waiting). > > # time touch /usr/portage/distfiles/testfile > > real0m30.088s > user0m0.000s > sys 0m0.001s > > I cant see anything in the nfs server debugging so i want to strace nfsd. > First i tell it to use single thread so i know i;m stracing the correct > thread, but; > > # grep OPTS_RPC_NFSD nfs > #OPTS_RPC_NFSD="8 -N2 -V 3 -V 4 -V 4.1" > OPTS_RPC_NFSD="1 -N2 -V 3 -V 4 -V 4.1" > # systemctl restart nfs-server > # pgrep -lf nfsd > 23546 nfsd4_callbacks > 23548 nfsd > 23549 nfsd > 23550 nfsd > 23551 nfsd > 23552 nfsd > 23553 nfsd > 23554 nfsd > 23555 nfsd > > So its not respecting the nproc setting. Any ideas? I also tried changing > EXPORTFS_TIMEOUT= since its currently set at 30. It didnt help, but perhaps > that's because its being ignored too. Are the nfsd versions that you're setting being respected? You can check with "rpcinfo -s" or "cat /proc/fs/nfsd/versions". You can change the number of threads on the fly with "echo 1 > /proc/fs/nfsd/threads". I don't use systemd on Gentoo but for the nfs-utils upstream-shipped systemd units that I think that Gentoo's using, you have to re-run nfs-config.service - or run the script that it calls - in order to update the "/run/sysconfig/nfs-utils" environment file that's sourced by the nfs-server.service unit. Does "/var/lib/nfs/v4recovery/" exist? Does adding the client to "/etc/hosts" - or to your reverse dns zone - eliminate the delay?
[gentoo-user] NFS problem
Hello list,
Since I set up IPv6 on my LAN, I've been unable to NFS-export a directory on
machine A (an Atom serving portage via git, among other things) and mount it
on machine B (this workstation). It was working fine until then, but now mount
commands fail. In both kernels I have NFSv4 selected, but not 4.x; no fancy
extras like ACLs.
I went back to the Gentoo nfs-utils wiki page and made sure I had everything
right, then searched for other people's problems. Nothing has helped so far.
On the server:
$ cat /etc/conf.d/nfs
NFS_NEEDED_SERVICES="rpc.idmapd"
OPTS_RPC_NFSD="1 -N 2 -N 3 -V 4 -N 4.1"
OPTS_RPC_MOUNTD="-p 32767"
OPTS_RPC_STATD="-p 32765 -o 32766"
OPTS_RPC_IDMAPD=""
OPTS_RPC_GSSD=""
OPTS_RPC_SVCGSSD=""
OPTS_RPC_RQUOTAD=""
EXPORTFS_TIMEOUT=30
$ cat /etc/exports
mnt/nfs 192.168.1.5/24(rw,no_subtree_check,crossmnt,fsid=0) \
fe80::5/64(rw,sync,no_subtree_check,crossmnt,fsid=0)
/mnt/nfs/portage
192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1) \
fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1)
/mnt/nfs/port.resc
192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2) \
fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2)
$ grep nfs /etc/fstab
/usr/portage/mnt/nfs/portagenonebind
0 0
On the client:
$ grep nfs /etc/fstab
192.168.1.2:/mnt/nfs/portage/mnt/atom/usr/portage nfs4
noauto,rw,_netdev 0 0
Now I try to mount /usr/portage from the host on /mnt/atom/usr/portage (which
does exist) and get this:
# mount /mnt/atom/usr/portage
mount.nfs4: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given by
server: No such file or directory
# mount 192.168.1.2:/mnt/nfs/portage /mnt/atom/usr/portage
mount.nfs: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given by
server: No such file or directory
# mount [fe80::2]:/mnt/nfs/portage /mnt/atom/usr/portage
mount.nfs: mount system call failed
It doesn't seem to be a firewall problem, because I get the same result if I
start both machines without their firewalls - I don't do that very often! Ping
works fine in both directions, whether IPv4 or v6. Do I have to tweak mapd
somehow?
I'm feeling a bit clueless...
--
Regards,
Peter.
Re: [gentoo-user] Re: [~amd64] NFS server broken again :(
On Mon, Oct 27, 2014 at 5:46 PM, walt w41...@gmail.com wrote: On 10/27/2014 12:56 PM, Canek Peláez Valdés wrote: On Mon, Oct 27, 2014 at 1:38 PM, walt w41...@gmail.com wrote: Last night when I powered off my machines NFS was working perfectly. Today it's broken again for the nth time: #systemctl status nfs-server ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib64/systemd/system/nfs-server.service; enabled) Active: failed (Result: exit-code) since Mon 2014-10-27 11:50:38 PDT; 25min ago Process: 896 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS) Process: 893 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS) Process: 939 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=1/FAILURE) I think I know the answer. Some days ago you moved /etc/conf.d for NetworkManager to work, right? Where does the environment variable RPCNFSDARGS is defined? I'm willing to bet that is in a /etc/conf.d file. Could you please post here the contents of nfs-server.service, and if it exists, the files inside /etc/systemd/system/nfs-server.service.d and their contents? Bingo again :) Your question led me to the answer, which I think is a bug in /usr/lib64/systemd/system/nfs-server.service. Here's why the bug showed up just this morning: way back at the beginning of systemd I stole some .service files from RedHat Fedora, including one named 'nfs.service'. Gentoo nfs-utils package still doesn't include a systemd unit file, really? With a perfunctory look at /usr/portage/net-fs/nfs-utils/files, I see several *.service files. I highly recommend using the unit files provided by the Gentoo devs. Turns out the foreign RedHat file was starting rpcbind for me all those months and, when I deleted it last night, rpcbind didn't get started this morning by nfs-server.service from gentoo (which I think is a bug). #cat nfs-server.service [Unit] Description=NFS server and services Requires= network.target proc-fs-nfsd.mount rpcbind.target Requires= nfs-mountd.service Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service Wants=rpc-statd-notify.service After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service After= nfs-idmapd.service rpc-statd.service After= rpc-gssd.service rpc-svcgssd.service Before= rpc-statd-notify.service [Service] EnvironmentFile=/etc/conf.d/nfs Type=oneshot RemainAfterExit=yes ExecStartPre=/usr/sbin/exportfs -r ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS ExecStop=/usr/sbin/rpc.nfsd 0 ExecStopPost=/usr/sbin/exportfs -au ExecStopPost=/usr/sbin/exportfs -f ExecReload=/usr/sbin/exportfs -r [Install] WantedBy=multi-user.target I can see that rpcbind.target is Required, but NOT rpcbind.service. AFAICT rpc.target does nothing (please explain if I'm wrong about that). I have no idea; I haven't set an NFS server in years. However, most target units usually are kinda virtuals; the bring other units up. BTW, /etc/conf.d/nfs doesn't define RPCNFSDARGS because it is intended for use by openrc (another bug?): Something should define RPCNFSDARGS; perhaps a drop-in? #cat /etc/conf.d/nfs # /etc/conf.d/nfs # If you wish to set the port numbers for lockd, # please see /etc/sysctl.conf # Optional services to include in default `/etc/init.d/nfs start` # For NFSv4 users, you'll want to add rpc.idmapd here. NFS_NEEDED_SERVICES=rpc.idmapd # Number of servers to be started up by default OPTS_RPC_NFSD=8 # Options to pass to rpc.mountd # ex. OPTS_RPC_MOUNTD=-p 32767 OPTS_RPC_MOUNTD= # Options to pass to rpc.statd # ex. OPTS_RPC_STATD=-p 32765 -o 32766 OPTS_RPC_STATD= # Options to pass to rpc.idmapd OPTS_RPC_IDMAPD= # Options to pass to rpc.gssd OPTS_RPC_GSSD= # Options to pass to rpc.svcgssd OPTS_RPC_SVCGSSD= # Options to pass to rpc.rquotad (requires sys-fs/quota) OPTS_RPC_RQUOTAD= # Timeout (in seconds) for exportfs EXPORTFS_TIMEOUT=30 # Options to set in the nfsd filesystem (/proc/fs/nfsd/). # Format is option=value. Multiple options are allowed. #OPTS_NFSD=nfsv4leasetime=30 max_block_size=4096 Thanks Canek! Walt, from time to time run systemd-delta and see what configurations of yours differ from upstream (either systemd and/or Gentoo). I think you should be using nfs-utils' included unit files. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: [~amd64] NFS server broken again :(
On Tue, Oct 28, 2014 at 6:18 PM, walt w41...@gmail.com wrote:
On 10/27/2014 08:22 PM, Tom H wrote:
The 1.2.9 nfs-utils ebuild has systemd_dounit
${FILESDIR}/nfsd.service where nfsd.service has
Requires=rpcbind.service and After=rpcbind.service.
The 1.3.0 nfs-utils ebuild has systemd_dounit
systemd/*.{mount,service,target} where nfs-server.service has
Requires=rpcbind.target and After=rpcbind.target.
Yes, and that little change caused the breakage that inspired this
thread in the first place :)
I have a Fedora 20 machine running in VirtualBox and I see they've
already fixed the same breakage by going back to 'rpcbind.service'
in their nfs-server.service file.
I see they also define all those $RPCFOO variables in /etc/sysconfig/nfs,
which are mostly null-strings anyway, which is why my nfs server is
working correctly without those variables.
(Working correctly *after* systemctl enable rpcbind, that is.)
systemctl enable rpcbind or systemctl start rpcbind? (Or
systemctl enable rpcbind and reboot?)
I've been wondering about rpcbind.target. I'm not using systemd on
Gentoo but on my laptop running Ubuntu 15.04 (yes, 15 with systemd
215), /lib/systemd/system/rpcbind.target is provided by systemd.
It's also part of the upstream tarball so it must be part of the
Gentoo package - and, I have to assume, part of the Fedora systemd
package since Lennart's its maintainer there.
Since Gentoo's rpcbind.service has Wants=rpcbind.target and
Before=rpcbind.target, having nfs-server.service depend on
rpcbind.target rather than rpcbind.service should work as long as
rpcbind.service is enabled.
But having Requires=rpcbind.service and After=rpcbind.service,
like nfsd.service has/had, means that you don't have to enable
rpcbind.service.
[gentoo-user] [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
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 :(
Re: [gentoo-user] nfsv4 issues
Are the nfsd versions that you're setting being respected? You can > check with "rpcinfo -s" or "cat /proc/fs/nfsd/versions". > Yep; # cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2 > You can change the number of threads on the fly with "echo 1 > > /proc/fs/nfsd/threads". > That works too, but then; # ps -ef | grep nfsd root 1454 1426 0 12:47 pts/000:00:00 grep --colour=auto nfsd root 23546 2 0 Jul19 ?00:00:00 [nfsd4_callbacks] root 23548 2 0 Jul19 ?00:00:00 [nfsd] # strace -p 23548 strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted > I don't use systemd on Gentoo but for the nfs-utils upstream-shipped > systemd units that I think that Gentoo's using, you have to re-run > nfs-config.service - or run the script that it calls - in order to > update the "/run/sysconfig/nfs-utils" environment file that's sourced > by the nfs-server.service unit. > In /usr/lib/systemd/system/nfs-server.service [Service] EnvironmentFile=/etc/conf.d/nfs Does "/var/lib/nfs/v4recovery/" exist? > > No # ls /var/lib/nfs/ etab export-lock rmtab rpc_pipefs sm sm.bak state xtab Does adding the client to "/etc/hosts" - or to your reverse dns zone - > eliminate the delay? > > DNS is setup and both client and server can forward and reverse lookup each other.
[gentoo-user] nfs-utils update fails to compile: missing rpc/auth_gss.h
During a routine update, emerge failed to compile nfs-utils: [...] context.c:40:26: fatal error: rpc/auth_gss.h: No such file or directory #include ^ compilation terminated. make[2]: *** [Makefile:660: gssd-context.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/var/tmp/portage/net-fs/nfs-utils-1.3.4-r1/work/nfs-utils-1.3.4/utils/gssd' make[1]: *** [Makefile:450: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/net-fs/nfs-utils-1.3.4-r1/work/nfs-utils-1.3.4/utils' make: *** [Makefile:474: all-recursive] Error 1 * ERROR: net-fs/nfs-utils-1.3.4-r1::gentoo failed (compile phase): * emake failed And gcc is correct: there is no such include file: $ ls -l /usr/include/rpc total 116 -rw-r--r-- 1 root root 3559 Jan 5 14:02 auth_des.h -rw-r--r-- 1 root root 6636 Jan 5 14:02 auth.h -rw-r--r-- 1 root root 2914 Jan 5 14:02 auth_unix.h -rw-r--r-- 1 root root 12531 Jan 5 14:02 clnt.h -rw-r--r-- 1 root root 3383 Jan 5 14:02 des_crypt.h -rw-r--r-- 1 root root 11756 Jan 5 14:02 key_prot.h -rw-r--r-- 1 root root 2897 Jan 5 14:02 netdb.h -rw-r--r-- 1 root root 3837 Jan 5 14:02 pmap_clnt.h -rw-r--r-- 1 root root 3810 Jan 5 14:02 pmap_prot.h -rw-r--r-- 1 root root 2311 Jan 5 14:02 pmap_rmt.h -rw-r--r-- 1 root root 2485 Jan 5 14:02 rpc_des.h -rw-r--r-- 1 root root 3938 Jan 5 14:02 rpc.h -rw-r--r-- 1 root root 4753 Jan 5 14:02 rpc_msg.h -rw-r--r-- 1 root root 1976 Jan 5 14:02 svc_auth.h -rw-r--r-- 1 root root 11524 Jan 5 14:02 svc.h -rw-r--r-- 1 root root 3233 Jan 5 14:02 types.h -rw-r--r-- 1 root root 14577 Jan 5 14:02 xdr.h I've been googling, but haven't been able to find anything that looks relevent other than a Sabayon user posting on a Gentoo list/forum many years ago about the exact same error message. He was told to go away. Where is rpc/auth_gss.h supposed to come from, and why does the nfs-utils ebuild suddenly expect it to be present? -- Grant Edwards grant.b.edwardsYow! Catsup and Mustard all at over the place! It's the gmail.comHuman Hamburger!
[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On 02/02/2015 10:29 AM, Tom H wrote: On Sun, Feb 1, 2015 at 7:31 PM, walt w41...@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)
Am Sonntag, 01.02.2015 um 14:41 schrieb walt w41...@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
[gentoo-user] rpc time outs
hi, I have a central distfile server, and time after time i get on my clients this error when they try to connect: mount: RPC: Timed out The same with new gentoo installes when i try to connect with the live cd 2004.3 to the disftfile server. portmap version:5b-r9 nfs-utils:1.0.7 Kernel: 2.4.26-gentoo-r9 I have tried with this options on the client side: mount -t nfs -o rw,intr,hard TIA Patrick -- gentoo-user@gentoo.org mailing list
[gentoo-user] netmount vs. nfsmount
Hi, I have noticed that I have two init scripts for mounting NFS filesystems, netmount from sys-apps/openrc and nfsmount from net-fs/nfs-utils. At the moment I have both of them in my default bootlevel but I think that just one of them would be enough, am I right? And if so, which one should I choose (which is more up to date). I am mainly using NFSv4. Regards, -- Dan Johansson, http://www.dmj.nu *** This message is printed on 100% recycled electrons! ***
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
Am 27.07.2014 18:25, schrieb Stefan G. Weichinger: Only last week I re-attacked this topic as I start using puppet here to manage my systems ... and one part of this might be sharing /usr/portage via NFSv4. One client host mounts it without a problem, the thinkpads don't do so ... just another example ;-) As so often ... my fault: thinkpads did have NFSv4 in the kernel, but no nfs-utils installed ... ;-) sorry, S
Re: [gentoo-user] Nfs-utils update
On Tuesday 16 May 2017 14:52:49 Neil Bothwick wrote: > On Tue, 16 May 2017 13:37:15 +0100, Peter Humphrey wrote: > > Today I was offered an update of net-fs/nfs-utils from 1.3.4 to > > 1.3.4-r1. It won't compile, complaining that there's no Kerberos v5 > > with GSS: "consider --disable-gss or --with-krb5=". But there's no > > Kerberos here and it's not in my USE flags, and if I specify > > USE=-kerberos on the command line it still fails the same way. > > > > Bug 618534 refers. > > > > Has anyone else seen this? > > The solution is given in one of the bug reports > > EXTRA_ECONF="--disable-gss" emerge -1a nfs-utils > > although the report also says it's fixed, so sync again. Ah, so it does now. Thanks Neil. It's https://bugs.gentoo.org/show_bug.cgi?id=618544 in case anyone else is interested. -- Regards Peter
Re: [gentoo-user] Nfs-utils update
On Tue, 16 May 2017 13:37:15 +0100, Peter Humphrey wrote: > Today I was offered an update of net-fs/nfs-utils from 1.3.4 to > 1.3.4-r1. It won't compile, complaining that there's no Kerberos v5 > with GSS: "consider --disable-gss or --with-krb5=". But there's no > Kerberos here and it's not in my USE flags, and if I specify > USE=-kerberos on the command line it still fails the same way. > > Bug 618534 refers. > > Has anyone else seen this? The solution is given in one of the bug reports EXTRA_ECONF="--disable-gss" emerge -1a nfs-utils although the report also says it's fixed, so sync again. -- Neil Bothwick If Wile E. Coyote had enough money to buy all that ACME crap, why didn't he just buy dinner? pgpaZFyQzwckM.pgp Description: OpenPGP digital signature
Re: [gentoo-user] chicken -- egg (NFS tty video)
On 2011/05/14 09:20 (GMT-0400) Felix Miata composed: My #1 problem to solve is NFS not working yet (nfs-utils aka libevent, portmap, rpc emerge failures), but it would also be very nice to get Grub to emerge. Logs: http://fm.no-ip.com/Tmp/Linux/G/ Now as noted in the econf failed thread I've succeeded in emerging nfs-utils and grub, but neither work right. I have two Gentoo stanzas in my primary bootloader, one to load the kernel, another to chainload Gentoo's Grub. Loading the kernel works, but chainload gives error 13 invalid executable format. I named the bzImage copied to /boot kernel-2.6.37-r4f, and symlinked it a vmlinuz. vmlinuz is the name I use in the Grub stanzas. Is Gentoo's Grub expecting the kernel to have a particular name, and I picked a wrong one? Or maybe what it doesn't like is that I uncommented splashimage=(hd0,6)/boot/grub/splash.xpm.gz in menu.lst? The errors from NFS are different than I originally encountered, and indicate that neither portmap nor rpcbind are running. Which of the two did nfs-utils actually install (or both?), and what exactly is its name I need to use with rc-update or start one or the other manually to get my server's exports mounted locally? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On 02/01/2015 03:32 PM, waben...@gmail.com wrote: Am Sonntag, 01.02.2015 um 14:41 schrieb walt w41...@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!
[gentoo-user] NFS tutorial for the brain dead sysadmin?
In this case, the brain dead sysadmin would be moi :) For years I've been using NFS to share /usr/portage with all of the gentoo machines on my LAN. Problem: occasionally it stops working for no apparent reason. Example: two days ago I updated two ~amd64 gentoo machines, both of which have been mounting /usr/portage as NFS3 shares for at least a year with no problems. One machine worked normally after the update, the other was unable to mount /usr/portage because rpc.statd wouldn't start correctly. After two frustrating days I discovered that I had never enabled the rpcbind.service on the broken machine. So I enabled rpcbind, which fixed the breakage. So, why did the broken machine work normally for more than a year without rpcbind until two days ago? (I suppose because nfs-utils was updated to 1.3.0 ?) The real problem here is that I have no idea how NFS works, and each new version is more complicated because the devs are solving problems that I don't understand or even know about. So, please, what's the best way to learn and understand NFS? Thanks for any clues.
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Mon, Feb 2, 2015 at 8:46 PM, walt w41...@gmail.com wrote: On 02/02/2015 10:29 AM, Tom H wrote: On Sun, Feb 1, 2015 at 7:31 PM, walt w41...@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?
Re: [gentoo-user] chicken -- egg (NFS tty video) (part solved)
On 2011/05/15 22:18 (GMT-0400) Felix Miata composed: The errors from NFS are different than I originally encountered, and indicate that neither portmap nor rpcbind are running. Which of the two did nfs-utils actually install (or both?), and what exactly is its name I need to use with rc-update or start one or the other manually to get my server's exports mounted locally? This one is solved. I looked in /etc/init.d/ and saw rpcbind, got it working manually, then set it automatic on boot with 'rc-update add rpcbind default'. :-) -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
Am Sonntag, 01.02.2015 um 16:31 schrieb walt w41...@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] [nfs] nfs mount settings
Alan McKinnon writes: On Tuesday 28 July 2009 09:39:40 Alex Schuster wrote: man 5 exports (at least my localized german version) lists the map_daemon option, which allows mapping of UIDs / GIDs between server and client. This needs the rpc.ugidd to be running on server side. I never did this, I don't even know where to get rpc.ugidd from, and I'm pretty sure it won't work at all with opensolaris, but at least with linux it should be possible then, theoretically. That's good to know - I don't have anything like that here in my man pages. Well, at east the sed man page in german is quite different from the englisch one, maybe that's the case here, too. Does yours explain the (no_)subtree_check option? I had t look them up online. I have nfs-utils-1.2.0, what version are you running? 1.1.4-r1. Bug #116269 from end of 2005 misses the rpc.ugidd, the answer there is that nfs-utils does not yet support it. And I doubt it ever will, I just read that this is a feature of user space NFS, which seems to be deprecated. A kernel based NFS does not have it. So, so seem to be right, ID mapping just is not possible (any more). But what about NFS v4? Is has user authentification, maybe then there's a mapping feature, too? Wonko
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
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] How to enable NFS v2
Dear Jack, Jack 于2022年7月27日周三 06:59写道： > This list prefers bottom posting. See below. > > On 2022.07.23 21:52, Fabulous Zhang Zheng wrote: > > Dear Jack, > > > > thanks for your reply, I reconfigured menuconfig. > > > > NFS v2 support I found is client support, and I can't still find v2 > > support > > for server ( sorry for not mentioning it in my ambiguous question ) > > I also looked up in forum and wiki, and recent posts seem to indicate > > the removal of nfs v2 server support. > > > > I followed this link for open genera > > ( https://archives.loomcom.com/genera/genera-install.html ) > > not in portage or an overlay. > > > > Best regards :) > > > > Jack 于2022年7月24日周日 03:30写道： > > > > > On 2022.07.23 01:25, Fabulous Zhang Zheng wrote: > > > > Dear genteel users, > > > > > > > > > > > > Recently I'm trying to run Open Genera on Gentoo, which requires > > the > > > > old > > > > NFS v2 protocol for communication. > > > > > > > > I successfully run it on a Ubuntu 16.04 virtual machine, which > > > > enables it > > > > by default. > > > > > > > > In 5.18.12 it seems deprecated and not supported, am I supposed to > > > > revert > > > > back to a kernel version before its removal, or manually patch it > > > > into the > > > > current kernel ? Or there might be some more elegant methods ? > > > > > > > > It will be much appreciated if anyone could help :) > > > > > > > Looking at the config for 5.18.14, I see no evidence V2 has been > > > deprecated. However, your kernel may well have been configured to > > not > > > use V2. Note the kernel has different client and server settings > > for > > > this. Most likely, you just need to reconfigure and recompile your > > > kernel. > > > > > > Also, I don't see any genera available in portage. If it is in an > > > overlay, I would check for any documentation in the overlay about > > > necessary kernel configuration. > > > > > > Jack > > > > > > > > > I am aware that NFSv2 is likely to be deprecated due to security > concerns, but it hasn't happened yet in the Linux kernel. > > The entry (5.18.14) for "NFS server support (NFSD)" or CONFIG_NFSD: says > > - > Choose Y here if you want to allow other computers to access files > residing on this system using Sun's Network File System protocol. To > compile the NFS server support as a module, choose M here: the module > will be called nfsd. > > You may choose to use a user-space NFS server instead, in which case > you can choose N here. > > To export local file systems using NFS, you also need to install user > space programs which can be found in the Linux nfs-utils package, > available from http://linux-nfs.org/. More detail about the Linux NFS > server implementation is available via the exports(5) man page. > > Below you can choose which versions of the NFS protocol are available > to clients mounting the NFS server on this system. Support for NFS > version 2 (RFC 1094) is always available when CONFIG_NFSD is selected. > - > > In addition, from just a very brief search, it is likely that there are > other configuration files you may need to alter in order for the nfs > server to actually respond to V2 requests. This is likely how some > distributions have blocked V2 from the default configuration. Google > is your friend. > > Jack > > Sorry for the late reply, I found this commit <https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=2c2c36c59fa1de2ff7fd28917e54700ecb39b730> of last November, which might be the reason. 2.5.4 might be the last version with such support. I emerged manually changed ebuild and $( rpcinfo -p localhost | grep nfs ) explicitly indicates the version 2 of nfs, which runs successfully. Thanks again for your dedicated and detailed reply, and also the bottom-posting reminder. Best regards :)
Re: [gentoo-user] NFS trouble
On Tuesday, 10 March 2020 09:27:54 GMT Michael wrote: > On Tuesday, 10 March 2020 08:17:41 GMT netfab wrote: > > Le 09/03/20 à 17:03, Peter Humphrey a tapoté : > > > mount -t nfs 192.168.1.4:/mnt/nfs/portage /mnt/clrn/usr/portage # > > > script on the client > > > > > > Result: > > > * Mounting chroot dirs under /mnt/clrn ... > > > mount.nfs: mounting 192.168.1.4:/mnt/nfs/portage failed, reason given > > > by server: No such file or directory > > > > [...] > > > > > Can anyone see the problem? > > > > From the client, please try this : > > > # mkdir /mnt/nfs4 > > > # mount -t nfs4 192.168.1.4:/ /mnt/nfs4 > > > # ls /mnt/nfs4 > > According to the following wiki page, with NFSv4 when mounting NFS from the > client you use relative paths to the virtual root on the server. > > https://wiki.gentoo.org/wiki/Nfs-utils > > Therefore I also think the syntax netfab suggests above is how you should > try it in the first instance; e.g.: > > mount -t nfs 192.168.1.4:portage /mnt/clrn/usr/portage > > or > > mount -t nfs 192.168.1.4:/portage /mnt/clrn/usr/portage Well, even after all the times I read that wiki, I still hadn't picked that up. I'm sure I used to be able to read, once upon a time. :( Thank you both for the clue. No more head-banging for the moment. -- Regards, Peter.
Re: [gentoo-user] NFS problem
What happens when you remove the IPv6 adresses from the NFS config? As you are using IPv4, those should not be needed. I haven't had time to enable IPv6 yet, so can't check locally what works and what doesn't. On 23 December 2019 17:50:58 CET, Peter Humphrey wrote: >Hello list, > >Since I set up IPv6 on my LAN, I've been unable to NFS-export a >directory on >machine A (an Atom serving portage via git, among other things) and >mount it >on machine B (this workstation). It was working fine until then, but >now mount >commands fail. In both kernels I have NFSv4 selected, but not 4.x; no >fancy >extras like ACLs. > >I went back to the Gentoo nfs-utils wiki page and made sure I had >everything >right, then searched for other people's problems. Nothing has helped so >far. > >On the server: >$ cat /etc/conf.d/nfs >NFS_NEEDED_SERVICES="rpc.idmapd" >OPTS_RPC_NFSD="1 -N 2 -N 3 -V 4 -N 4.1" >OPTS_RPC_MOUNTD="-p 32767" >OPTS_RPC_STATD="-p 32765 -o 32766" >OPTS_RPC_IDMAPD="" >OPTS_RPC_GSSD="" >OPTS_RPC_SVCGSSD="" >OPTS_RPC_RQUOTAD="" >EXPORTFS_TIMEOUT=30 >$ cat /etc/exports >mnt/nfs 192.168.1.5/24(rw,no_subtree_check,crossmnt,fsid=0) \ >fe80::5/64(rw,sync,no_subtree_check,crossmnt,fsid=0) >/mnt/nfs/portage >192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1) \ >fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1) >/mnt/nfs/port.resc >192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2) \ >fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2) >$ grep nfs /etc/fstab >/usr/portage/mnt/nfs/portagenonebind >0 0 > >On the client: >$ grep nfs /etc/fstab >192.168.1.2:/mnt/nfs/portage/mnt/atom/usr/portage nfs4 >noauto,rw,_netdev 0 0 > >Now I try to mount /usr/portage from the host on /mnt/atom/usr/portage >(which >does exist) and get this: ># mount /mnt/atom/usr/portage >mount.nfs4: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given >by server: No such file or directory ># mount 192.168.1.2:/mnt/nfs/portage /mnt/atom/usr/portage >mount.nfs: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given >by server: No such file or directory ># mount [fe80::2]:/mnt/nfs/portage /mnt/atom/usr/portage >mount.nfs: mount system call failed > >It doesn't seem to be a firewall problem, because I get the same result >if I >start both machines without their firewalls - I don't do that very >often! Ping >works fine in both directions, whether IPv4 or v6. Do I have to tweak >mapd >somehow? > >I'm feeling a bit clueless... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: nfs export/remote mount problem
On 5/10/05, Richard Fish [EMAIL PROTECTED] wrote: Mark Knecht wrote: 2) The contents o the hosts.allow and hosts.deny files. Where are these files? They do not seem to be present on my machine? Should they not be created by some part of the baseline system install? The files hosts.allow and hosts.deny are the configuration files for TCP wrappers/tcpd access control. Anything that runs under tcpd (or is built with +tcpd) will use these files to determine what machines can (hosts.allow) or cannot (hosts.deny) access the server. Humm...so am I *required to have the files? Maybe that's part of the problem! dragonfly ~ # emerge -pv nfs-utils These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-fs/nfs-utils-1.0.6-r6 +tcpd 0 kB Total size of downloads: 0 kB dragonfly ~ # So if you USE +tcpd (usually a good idea!), you'll want to read man hosts.allow. * sys-apps/xinetd I don't know if inetd is required, but if so, this is the one you want on the server. It's not shown as needed on this Gentoo Wiki: http://gentoo-wiki.com/index.php?title=HOWTO_Share_Directories_via_NFS -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
-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-
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Mon, Feb 2, 2015 at 10:55 AM, Holger Hoffstätte holger.hoffstae...@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] NFS problem
On Monday, 23 December 2019 16:50:58 GMT Peter Humphrey wrote: > Hello list, > > Since I set up IPv6 on my LAN, I've been unable to NFS-export a directory on > machine A (an Atom serving portage via git, among other things) and mount > it on machine B (this workstation). It was working fine until then, but now > mount commands fail. In both kernels I have NFSv4 selected, but not 4.x; no > fancy extras like ACLs. > > I went back to the Gentoo nfs-utils wiki page and made sure I had everything > right, then searched for other people's problems. Nothing has helped so > far. > > On the server: > $ cat /etc/conf.d/nfs > NFS_NEEDED_SERVICES="rpc.idmapd" > OPTS_RPC_NFSD="1 -N 2 -N 3 -V 4 -N 4.1" > OPTS_RPC_MOUNTD="-p 32767" > OPTS_RPC_STATD="-p 32765 -o 32766" > OPTS_RPC_IDMAPD="" > OPTS_RPC_GSSD="" > OPTS_RPC_SVCGSSD="" > OPTS_RPC_RQUOTAD="" > EXPORTFS_TIMEOUT=30 > $ cat /etc/exports > mnt/nfs 192.168.1.5/24(rw,no_subtree_check,crossmnt,fsid=0) \ > fe80::5/64(rw,sync,no_subtree_check,crossmnt,fsid=0) > /mnt/nfs/portage > 192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1) \ > fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=1) > /mnt/nfs/port.resc > 192.168.1.5/24(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2) \ > fe80::5/64(rw,no_subtree_check,anonuid=250,anongid=250,fsid=2) $ grep nfs > /etc/fstab > /usr/portage/mnt/nfs/portagenonebind >0 0 > > On the client: > $ grep nfs /etc/fstab > 192.168.1.2:/mnt/nfs/portage/mnt/atom/usr/portage nfs4 > noauto,rw,_netdev 0 0 > > Now I try to mount /usr/portage from the host on /mnt/atom/usr/portage > (which does exist) and get this: > # mount /mnt/atom/usr/portage > mount.nfs4: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given by > server: No such file or directory # mount 192.168.1.2:/mnt/nfs/portage > /mnt/atom/usr/portage > mount.nfs: mounting 192.168.1.2:/mnt/nfs/portage failed, reason given by > server: No such file or directory # mount [fe80::2]:/mnt/nfs/portage > /mnt/atom/usr/portage > mount.nfs: mount system call failed > > It doesn't seem to be a firewall problem, because I get the same result if I > start both machines without their firewalls - I don't do that very often! > Ping works fine in both directions, whether IPv4 or v6. Do I have to tweak > mapd somehow? > > I'm feeling a bit clueless... Is anyone feeling less clueless than me? I'm out of ideas now and hoping for some help. -- Regards, Peter.
Re: [gentoo-user] [nfs] nfs mount settings
On Tuesday 28 July 2009 09:39:40 Alex Schuster wrote: Alan McKinnon writes: Golden rule with nfs: It was designed for the case of a diskless client mounts it's home or root directories over the network, while exporting passwd and shadow files over NIS. That is evident in it's design and there is no facility to change uids and gids on the fly. man 5 exports (at least my localized german version) lists the map_daemon option, which allows mapping of UIDs / GIDs between server and client. This needs the rpc.ugidd to be running on server side. I never did this, I don't even know where to get rpc.ugidd from, and I'm pretty sure it won't work at all with opensolaris, but at least with linux it should be possible then, theoretically. Wonko That's good to know - I don't have anything like that here in my man pages. I have nfs-utils-1.2.0, what version are you running? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
Am 26.07.2014 04:47, schrieb walt: So, why did the broken machine work normally for more than a year without rpcbind until two days ago? (I suppose because nfs-utils was updated to 1.3.0 ?) The real problem here is that I have no idea how NFS works, and each new version is more complicated because the devs are solving problems that I don't understand or even know about. I double your search for understanding ... my various efforts to set up NFSv4 for sharing stuff in my LAN also lead to unstable behavior and frustration. Only last week I re-attacked this topic as I start using puppet here to manage my systems ... and one part of this might be sharing /usr/portage via NFSv4. One client host mounts it without a problem, the thinkpads don't do so ... just another example ;-) Additional in my context: using systemd ... so there are other (different?) dependencies at work and services started. I'd be happy to get that working in a reliable way. I don't remember unstable behavior with NFS (v2 back then?) when we used it at a company I worked for in the 90s. Stefan
Re: [gentoo-user] Can't fetch distfiles in chroot
On Thu, Apr 26, 2018 at 4:12 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > So, again, I went off half-cocked (sorry about the noise). The problem is that > the NFS mount in the chroot picks different ports each time, so the client's > firewall drops all NFS packets. > > Now I just have to find out why that happens. Set up static ports for mountd and statd in "/etc/conf.d/nfs". Set up static ports for lockd in "/etc/modprobe.d/" or "/etc/sysctl.d/" (depending on how you compiled your kernel). Non-official but more or less conventional ports (IIRC, first used in an old Slackware howto): mountd: "--port 32767" statd: "--port 32765 --outgoing-port 32766" lockd-sysctl.d: fs.nfs.nlm_udpport=32768 fs.nfs.nlm_tcpport=32768 lockd--modprobe.d: options lockd nlm_udpport=32768 nlm_tcpport=32768 [ If you want to be "modern," the nfs-utils tarball (v2.1.1 and above) includes "nfs.conf" that you can copy into "/etc/" and edit ]
[gentoo-user] mount.nfs stale nfs handle
Hi there, After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. Symptoms: $ mount -v -t nfs poseidon:/datadisk/ /mnt/gentoo/ mount.nfs: timeout set for Sun Jun 29 19:33:40 2014 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle [...] mount.nfs: Connection timed out $ [Poseidon is my server at 192.168.1.6, the client is at 192.168.1.2] Server disk to be exported is a ~9TB raid array with XFS. I'm using nfs3 with ACL and no idmapd; nfs4+ is not compiled into kernel (neither on client nor on server); Why it is trying nfs4 first as seen in the log above I don't know. nfs-utils has been compiled with USE=-nfsv4 Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. What I checked: /etc/exports: /datadisk 192.168.1.0/24(rw,async,subtree_check) portmapper, nfs-services are running normal, as far I can see. Does anyone have any suggestion? Thanks, Alex
Re: [gentoo-user] [OT] NFSv4: 32-bit server versus 64-bit client?
I'm trying to be a good gentoo netizen by nfs-sharing /usr/portage between my three local gentoo machines, and failing :( After weeks of fiddling, I discovered today that my problems come from using a 32-bit machine to serve my two 64-bit NFS clients(!) (I'll mention up front that NFSv3 works perfectly -- only NFSv4 is bad.) this is due to different authentication methods used in nfs3 and nfs4 and does not rely on installation arch (32/64bit). you have to tune up nfs4 infrastructure. on both client and server make sure you have - nfs4 and inotify support in kernel - net-fs/nfs-utils installed with nfs4 support - grep NFS_NEEDED_SERVICES /etc/conf.d/nfs shows 'NFS_NEEDED_SERVICES=rpc.idmapd' - grep Domain /etc/idmapd.conf shows 'Domain = your local domain' - rpc.idmapd daemon is running (if it does not, restart nfs stack) - surely portage uid/gid are the same on all nfs-ed machines server side: /etc/exports: /usr/portage 192.168.1.0/24(async,no_root_squash,rw,no_subtree_check) client side: grep nfs /etc/fstab: server:/usr/portage /usr/portage nfs4 defaults,rw 0 1 consult rpc.idmapd(8) for details that way i'm sharing portage at home. works pretty good for months i've migrated to nfs4 hth
Re: [gentoo-user] How to enable NFS v2
This list prefers bottom posting. See below. On 2022.07.23 21:52, Fabulous Zhang Zheng wrote: Dear Jack, thanks for your reply, I reconfigured menuconfig. NFS v2 support I found is client support, and I can't still find v2 support for server ( sorry for not mentioning it in my ambiguous question ) I also looked up in forum and wiki, and recent posts seem to indicate the removal of nfs v2 server support. I followed this link for open genera ( https://archives.loomcom.com/genera/genera-install.html ) not in portage or an overlay. Best regards :) Jack 于2022年7月24日周日 03:30写道： > On 2022.07.23 01:25, Fabulous Zhang Zheng wrote: > > Dear genteel users, > > > > > > Recently I'm trying to run Open Genera on Gentoo, which requires the > > old > > NFS v2 protocol for communication. > > > > I successfully run it on a Ubuntu 16.04 virtual machine, which > > enables it > > by default. > > > > In 5.18.12 it seems deprecated and not supported, am I supposed to > > revert > > back to a kernel version before its removal, or manually patch it > > into the > > current kernel ? Or there might be some more elegant methods ? > > > > It will be much appreciated if anyone could help :) > > > Looking at the config for 5.18.14, I see no evidence V2 has been > deprecated. However, your kernel may well have been configured to not > use V2. Note the kernel has different client and server settings for > this. Most likely, you just need to reconfigure and recompile your > kernel. > > Also, I don't see any genera available in portage. If it is in an > overlay, I would check for any documentation in the overlay about > necessary kernel configuration. > > Jack > > I am aware that NFSv2 is likely to be deprecated due to security concerns, but it hasn't happened yet in the Linux kernel. The entry (5.18.14) for "NFS server support (NFSD)" or CONFIG_NFSD: says - Choose Y here if you want to allow other computers to access files residing on this system using Sun's Network File System protocol. To compile the NFS server support as a module, choose M here: the module will be called nfsd. You may choose to use a user-space NFS server instead, in which case you can choose N here. To export local file systems using NFS, you also need to install user space programs which can be found in the Linux nfs-utils package, available from http://linux-nfs.org/. More detail about the Linux NFS server implementation is available via the exports(5) man page. Below you can choose which versions of the NFS protocol are available to clients mounting the NFS server on this system. Support for NFS version 2 (RFC 1094) is always available when CONFIG_NFSD is selected. - In addition, from just a very brief search, it is likely that there are other configuration files you may need to alter in order for the nfs server to actually respond to V2 requests. This is likely how some distributions have blocked V2 from the default configuration. Google is your friend. Jack
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
Am Montag, 02.02.2015 um 00:12 schrieb Neil Bothwick n...@digimed.co.uk: On Mon, 2 Feb 2015 00:32:34 +0100, waben...@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] NFS and portage tree
On Fri, 9 Nov 2007 13:27:54 +0200, Uwe Thiem wrote: Alternative, and less kludgy, solution. Tar up /usr/portage on B, unpack it on A. Too big a thing for A. There is a reason why it doesn't have its own portage tree. ;-) You could get away with copying only the directories you need. Or just stick the directories on a USB stick and do PORTDIR_OVERLAY=/media/sda1 emerge nfs-utils -- Neil Bothwick Women live longer than men because they have so many clothes that they wouldn't be caught dead in. signature.asc Description: PGP signature
RE: [gentoo-user] nfs warning: mount version older than kernel
dragonfly ~ # uname -a Linux dragonfly 2.6.12-gentoo-r6 #3 Thu Aug 4 06:43:20 PDT 2005 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux dragonfly ~ # myth14 ~ # uname -a Linux myth14 2.6.12-gentoo-r6 #2 Tue Aug 2 16:31:31 PDT 2005 i686 Intel(R) Celeron(R) CPU 2.26GHz GenuineIntel GNU/Linux myth14 ~ # What versions of nfs-utils are installed on the systems? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: nfs-utils broken on ~amd64?
=== On Mon, 02/15, walt wrote: === The next step is to build a new kernel with nfs4 support and unset the 'nonfsv4' flag, but at the moment I'm running a ver-r-r-y long partition resize with gparted so that I can add more space to my experimental lvm2 volumes. (Working great so far.) I think I'll fall asleep before gparted is finished, so I'll supply more information tomorrow. === I had this problem. My solution was to have an fstab line like this: server:/mnt/vol1/home/home /althome nfsnfsvers=3 0 0 Note the nfsvers option. -- Keith Dart -- -- ~ Keith Dart ke...@dartworks.biz public key: ID: 19017044 http://www.dartworks.biz/ =
[gentoo-user] Re: nfs-utils broken on ~amd64?
On 02/15/2010 10:51 PM, Keith Dart wrote: === On Mon, 02/15, walt wrote: === The next step is to build a new kernel with nfs4 support and unset the 'nonfsv4' flag... I had this problem. My solution was to have an fstab line like this: server:/mnt/vol1/home/home /althome nfsnfsvers=3 0 0 Note the nfsvers option. Thanks, that works. On the command line I added -o nfsvers=3, which does the same thing. That certainly violates the principle of least surprise, IMO. The man page (written in 2006) says that nfs3 is assumed if no version is specified.
[gentoo-user] Re: [almost SOLVED] NFSv4: 32-bit server versus 64-bit client?
On 08/05/2011 03:51 AM, victor romanchuk wrote: I'm trying to be a good gentoo netizen by nfs-sharing /usr/portage between my three local gentoo machines, and failing :( After weeks of fiddling, I discovered today that my problems come from using a 32-bit machine to serve my two 64-bit NFS clients(!) (I'll mention up front that NFSv3 works perfectly -- only NFSv4 is bad.) this is due to different authentication methods used in nfs3 and nfs4 and does not rely on installation arch (32/64bit). you have to tune up nfs4 infrastructure. on both client and server make sure you have - nfs4 and inotify support in kernel - net-fs/nfs-utils installed with nfs4 support - grep NFS_NEEDED_SERVICES /etc/conf.d/nfs shows 'NFS_NEEDED_SERVICES=rpc.idmapd' - grep Domain /etc/idmapd.conf shows 'Domain = your local domain' That was a good hint, thanks. I finally figured out by trial and error that the correct gentoo way to start idmapd is by starting /etc/init.d/nfsmount on the client. That fixed the bad uid/gid numbers I was seeing. But, I still have a permissions problem I can't figure out. The exported /usr/portage mounts okay on the client with rw privileges, but I still get a read-only filesystem error when I try to write to it. Again by trial and error I discovered that restarting the nfs server fixes the write problem, but with a gotcha: the first write to the mounted NFS filesystem hangs for about a minute before it finally succeeds. Everything works normally after that. That first write process hangs in a D+ state, apparently waiting for something to time out after a minute or so. Any idea what could cause that? Many thanks!
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Mon, Feb 2, 2015 at 10:19 AM, waben...@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
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
Am Montag, 02.02.2015 um 08:37 schrieb Neil Bothwick n...@digimed.co.uk: On Mon, 2 Feb 2015 02:01:11 +0100, waben...@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] How to enable NFS v2
On 2022.07.29 12:54, Fabulous Zhang Zheng wrote: Dear Jack, Jack 于2022年7月27日周三 06:59写道： > This list prefers bottom posting. See below. > > On 2022.07.23 21:52, Fabulous Zhang Zheng wrote: > > Dear Jack, > > > > thanks for your reply, I reconfigured menuconfig. > > > > NFS v2 support I found is client support, and I can't still find v2 > > support > > for server ( sorry for not mentioning it in my ambiguous question ) > > I also looked up in forum and wiki, and recent posts seem to indicate > > the removal of nfs v2 server support. > > > > I followed this link for open genera > > ( https://archives.loomcom.com/genera/genera-install.html ) > > not in portage or an overlay. > > > > Best regards :) > > > > Jack 于2022年7月24日周日 03:30写道： > > > > > On 2022.07.23 01:25, Fabulous Zhang Zheng wrote: > > > > Dear genteel users, > > > > > > > > > > > > Recently I'm trying to run Open Genera on Gentoo, which requires > > the > > > > old > > > > NFS v2 protocol for communication. > > > > > > > > I successfully run it on a Ubuntu 16.04 virtual machine, which > > > > enables it > > > > by default. > > > > > > > > In 5.18.12 it seems deprecated and not supported, am I supposed to > > > > revert > > > > back to a kernel version before its removal, or manually patch it > > > > into the > > > > current kernel ? Or there might be some more elegant methods ? > > > > > > > > It will be much appreciated if anyone could help :) > > > > > > > Looking at the config for 5.18.14, I see no evidence V2 has been > > > deprecated. However, your kernel may well have been configured to > > not > > > use V2. Note the kernel has different client and server settings > > for > > > this. Most likely, you just need to reconfigure and recompile your > > > kernel. > > > > > > Also, I don't see any genera available in portage. If it is in an > > > overlay, I would check for any documentation in the overlay about > > > necessary kernel configuration. > > > > > > Jack > > > > > > > > > I am aware that NFSv2 is likely to be deprecated due to security > concerns, but it hasn't happened yet in the Linux kernel. > > The entry (5.18.14) for "NFS server support (NFSD)" or CONFIG_NFSD: says > > - > Choose Y here if you want to allow other computers to access files > residing on this system using Sun's Network File System protocol. To > compile the NFS server support as a module, choose M here: the module > will be called nfsd. > > You may choose to use a user-space NFS server instead, in which case > you can choose N here. > > To export local file systems using NFS, you also need to install user > space programs which can be found in the Linux nfs-utils package, > available from http://linux-nfs.org/. More detail about the Linux NFS > server implementation is available via the exports(5) man page. > > Below you can choose which versions of the NFS protocol are available > to clients mounting the NFS server on this system. Support for NFS > version 2 (RFC 1094) is always available when CONFIG_NFSD is selected. > - > > In addition, from just a very brief search, it is likely that there are > other configuration files you may need to alter in order for the nfs > server to actually respond to V2 requests. This is likely how some > distributions have blocked V2 from the default configuration. Google > is your friend. > > Jack > > Sorry for the late reply, I found this commit <https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=2c2c36c59fa1de2ff7fd28917e54700ecb39b730> of last November, which might be the reason. 2.5.4 might be the last version with such support. I emerged manually changed ebuild and $( rpcinfo -p localhost | grep nfs ) explicitly indicates the version 2 of nfs, which runs successfully. Thanks again for your dedicated and detailed reply, and also the bottom-posting reminder. Best regards :) I don't fully understand the interactions and relationship, but there are obviously some differences between the kernel nfs and userland nfs. Glad you got it working for you.
Re: [gentoo-user] mount.nfs stale nfs handle
On Sunday 29 June 2014 21:34:07 Alexander Puchmayr wrote: Hi there, After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. Symptoms: $ mount -v -t nfs poseidon:/datadisk/ /mnt/gentoo/ mount.nfs: timeout set for Sun Jun 29 19:33:40 2014 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle [...] mount.nfs: Connection timed out $ [Poseidon is my server at 192.168.1.6, the client is at 192.168.1.2] Server disk to be exported is a ~9TB raid array with XFS. I'm using nfs3 with ACL and no idmapd; nfs4+ is not compiled into kernel (neither on client nor on server); Why it is trying nfs4 first as seen in the log above I don't know. nfs-utils has been compiled with USE=-nfsv4 Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. What I checked: /etc/exports: /datadisk 192.168.1.0/24(rw,async,subtree_check) portmapper, nfs-services are running normal, as far I can see. Does anyone have any suggestion? I have this occasionally due to the backup system I am using: - stop the nfs export - umount the filesystem - take LVM snapshot - remound filesystem - re-enable the nfs export When that happens, I run the following on the server: # exportfs -au sleep 1 mount -a sleep 1 exportfs -r The sleeps are necessary, without them, it doesn't always work. -- Joost
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On 26/07/2014 04:47, walt wrote:
In this case, the brain dead sysadmin would be moi :)
For years I've been using NFS to share /usr/portage with all of the
gentoo machines on my LAN.
Problem: occasionally it stops working for no apparent reason.
Example: two days ago I updated two ~amd64 gentoo machines, both of
which have been mounting /usr/portage as NFS3 shares for at least a
year with no problems.
One machine worked normally after the update, the other was unable to
mount /usr/portage because rpc.statd wouldn't start correctly.
After two frustrating days I discovered that I had never enabled the
rpcbind.service on the broken machine. So I enabled rpcbind, which
fixed the breakage.
So, why did the broken machine work normally for more than a year
without rpcbind until two days ago? (I suppose because nfs-utils was
updated to 1.3.0 ?)
The real problem here is that I have no idea how NFS works, and each
new version is more complicated because the devs are solving problems
that I don't understand or even know about.
So, please, what's the best way to learn and understand NFS?
I think you are asking for the impossible :-)
NFS is not easy to set up, and even harder to describe. It is easy to
*use* once it's set up correctly - you just mount something and the only
difference to a local mount is you add an IP address.
NFS uses RPC to do some heavy lifting - I don't know how familiar you
are with this, so here's the quick version:
When you mount something locally, and need to use the mounted
filesystem, kernel calls are used to get at the data. This works easily
as the source disk is local and the kernel can get to it. With NFS, the
source disk is remote and it's the remote kernel that must do the
accessing. RPC is a way to safely ask a remote kernel to do something
and get a result that behaves identical to a local kernel call.
Obviously, this is rather hard to implement correctly.
The original RPC was written by Sun and other newer implementations
exist, like libtirpc - to support useful features like not being stuck
with only UDP. That's what the ti means - Transport Independant.
RPC has been in a state of flux for some time and I too have run into
init-script oddities as things change.
In my case, I have nfs-utils-1.3.0, and rc-update configuredd to start
rpc.statd. This works because
depend() {
...
need portmap
...
}
and in the init.d file for rpcbind:
depend() {
...
provide portmap
}
So rpcbind starts at boot time and all my nfs mounts JustWork
Looks to me like your problem is actually with rpc and more specifically
with what things are currently named today (which could be different to
yesterday). Unfortunately I don't know of a place where this is all
nicely described in a sane manner except inside the init files themselves.
--
Alan McKinnon
alan.mckin...@gmail.com
[gentoo-user] nfs failing to start
I've apparently forgotten whatever little I may have know about setting up nfs from having used it long ago. I found a brief help page on google that I used to get this far along at: http://linux-bsd-sharing.blogspot.com/2008/09/howto-setup-nfs-server-on-gentoo.html Its very brief and has no debugging info. Also I see nothing about debugging in /etc/conf.d/nfs either. After setting all nfs related kernel items and booting the kernel. Checking that mods appears to be installed and running. Making sure portmapper is running. Then when I try to start nfs service if it fails. Producing these messages in syslogd: Jan [...] nfsd[29077]: nfssvc: Protocol not supported Jan [...' : RPC: failed to contact local rpcbind server (errno 5). Only one of the nfssvc lines appear but the RPC line appears several times. I got the impression from google that nfssvc was related to nfs4 so may not mean too much ... but not sure. I don't really know what info would be helpfull but have included output from emerge, rpcinfo, lsmod and related kernel settings: qlop [...] Sat Jan 10 18:30:11 2009 net-libs/libnfsidmap-0.21-r1 Sat Jan 10 18:30:30 2009 net-nds/portmap-6.0 Sat Jan 10 18:31:20 2009 dev-libs/libevent-1.4.9 Sat Jan 10 18:32:39 2009 net-fs/nfs-utils-1.1.4 = * = * = * = kernel: # grep 'NFS\|RPC' .config # CONFIG_AF_RXRPC is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_REGISTER_V4=y CONFIG_RPCSEC_GSS_KRB5=m # CONFIG_RPCSEC_GSS_SPKM3 is not set = * = * = * = rpcinfo -p localhost # rpcinfo -p localhost program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000241 udp 34971 status 1000241 tcp 43460 status 151 udp 34365 mountd 151 tcp 44349 mountd 152 udp 34365 mountd 152 tcp 44349 mountd 153 udp 34365 mountd 153 tcp 44349 mountd = * = * = * = lsmod Module Size Used by nfs 206772 0 nfsd 185008 9 lockd 55160 2 nfs,nfsd nfs_acl 2688 2 nfs,nfsd auth_rpcgss28548 1 nfsd sunrpc144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss exportfs3456 1 nfsd fuse 42268 0 usbhid 13588 0 usbmouse3712 0 usbkbd 4992 0 floppy 45348 0 pcspkr 2176 0 i2c_i8017952 0 r8169 26500 0 i2c_core 17680 1 i2c_i801 mii 4224 1 r8169 snd_intel8x0 25500 0 snd_ac97_codec 88352 1 snd_intel8x0 ehci_hcd 28684 0 uhci_hcd 18444 0 ac97_bus1536 1 snd_ac97_codec snd_pcm48008 2 snd_intel8x0,snd_ac97_codec snd_timer 15364 1 snd_pcm snd34788 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer usbcore 104760 6 usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd snd_page_alloc 7304 2 snd_intel8x0,snd_pcm intel_agp 22588 1 agpgart25520 1 intel_agp button 5904 0
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On 27 July 2014 18:25:24 CEST, Stefan G. Weichinger li...@xunil.at wrote: Am 26.07.2014 04:47, schrieb walt: So, why did the broken machine work normally for more than a year without rpcbind until two days ago? (I suppose because nfs-utils was updated to 1.3.0 ?) The real problem here is that I have no idea how NFS works, and each new version is more complicated because the devs are solving problems that I don't understand or even know about. I double your search for understanding ... my various efforts to set up NFSv4 for sharing stuff in my LAN also lead to unstable behavior and frustration. Only last week I re-attacked this topic as I start using puppet here to manage my systems ... and one part of this might be sharing /usr/portage via NFSv4. One client host mounts it without a problem, the thinkpads don't do so ... just another example ;-) Additional in my context: using systemd ... so there are other (different?) dependencies at work and services started. I'd be happy to get that working in a reliable way. I don't remember unstable behavior with NFS (v2 back then?) when we used it at a company I worked for in the 90s. Stefan I use NFS for filesharing between all wired systems at home. Samba is only used for MS Windows and laptops. Few things I always make sure are valid: - One partition per NFS share - No NFS share is mounted below another one - I set the version to 3 on the clients - I use LDAP for the user accounts to ensure the UIDs and GIDs are consistent. NFS4 requires all the exports to be under a single foldertree. I haven't had any issues in the past 7+ years with this and in the past 5+ years I had portage, distfiles and packages shared. /etc/portage is symlinked to a NFS share as well, allowing me to create binary packages on a single host (inside a chroot) which are then used to update the different machines. If anyone wants a more detailed description of my setup. Let me know and I will try to write something up. Kind regards Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] chicken -- egg (NFS tty video)
On 2011/05/14 12:52 (GMT+0100) Mick composed: BTW, my 3rd kernel did solve my video on ttys problem, and get me access to my EXT2 partition. :-) Have you read and applied http://www.gentoo.org/doc/en/xorg-config.xml to find out how to configure your card and xorg? Reading section 2.2 there is how I realized what it was that I had misconfigured previously to cause my video on ttys problem. ;-) My #1 problem to solve is NFS not working yet (nfs-utils aka libevent, portmap, rpc emerge failures), but it would also be very nice to get Grub to emerge. Logs: http://fm.no-ip.com/Tmp/Linux/G/ -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
On Mon, 2 Feb 2015 02:01:11 +0100, waben...@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) pgpnoXQkLNYN8.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)
Am Sonntag, 01.02.2015 um 16:31 schrieb walt w41...@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
[gentoo-user] [~amd64] NFS server broken again :(
Last night when I powered off my machines NFS was working perfectly. Today it's broken again for the nth time: #systemctl status nfs-server ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib64/systemd/system/nfs-server.service; enabled) Active: failed (Result: exit-code) since Mon 2014-10-27 11:50:38 PDT; 25min ago Process: 896 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS) Process: 893 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS) Process: 939 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=1/FAILURE) Process: 936 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 939 (code=exited, status=1/FAILURE) Oct 27 11:50:38 a6 rpc.nfsd[939]: rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused) Oct 27 11:50:38 a6 rpc.nfsd[939]: rpc.nfsd: unable to set any sockets for nfsd Oct 27 11:50:38 a6 systemd[1]: nfs-server.service: main process exited, code=exited, status=1/FAILURE Oct 27 11:50:38 a6 systemd[1]: Failed to start NFS server and services. Oct 27 11:50:38 a6 systemd[1]: Unit nfs-server.service entered failed state. #rpc.nfsd -d rpc.nfsd: Checking netconfig for visible protocols. rpc.nfsd: Enabling inet udp. rpc.nfsd: Enabling inet tcp. rpc.nfsd: Enabling inet6 udp. rpc.nfsd: Enabling inet6 tcp. rpc.nfsd: knfsd is currently down rpc.nfsd: Writing version string to kernel: -2 +3 +4 rpc.nfsd: Creating inet TCP socket. rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused) rpc.nfsd: Creating inet6 TCP socket. rpc.nfsd: writing fd to kernel failed: errno 97 (Address family not supported by protocol) rpc.nfsd: unable to set any sockets for nfsd Same kernel (3.16.6-gentoo) and nfs-utils-1.3.0-r1 I've been using for weeks with no trouble, so why today? Packages updated yesterday have (I think) nothing to do with nfs: #qlop -l |grep 'Oct 26' Fri Oct 26 03:07:58 2012 app-text/calibre-0.9.4 Fri Oct 26 03:08:13 2012 app-mobilephone/obexd-0.46 Fri Oct 26 13:41:39 2012 sys-fs/fuse-2.9.1-r1 Fri Oct 26 13:41:47 2012 sys-fs/mtpfs-1.1 Sat Oct 26 15:34:57 2013 media-video/avidemux-2.5.6-r2 Sun Oct 26 07:09:51 2014 sys-libs/timezone-data-2014i-r1 Sun Oct 26 07:10:10 2014 dev-python/py-1.4.26 Sun Oct 26 07:10:25 2014 dev-python/pytest-2.6.4 Sun Oct 26 07:14:05 2014 dev-lang/perl-5.20.1-r2 Sun Oct 26 07:14:28 2014 dev-perl/DBI-1.631.0 Sun Oct 26 07:14:49 2014 net-libs/polarssl-1.3.9 Sun Oct 26 07:15:25 2014 dev-python/pillow-2.5.3-r1 Sun Oct 26 08:41:38 2014 net-libs/webkit-gtk-2.4.7 Any ideas on how to debug this? Thanks.
