Packages

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Broken package
  • Category core
  • Assigned To No-one
  • Operating System
  • Severity Medium
  • Priority Normal
  • Reported Version Stable
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Packages
Opened by René Herman (rene) - 2015-11-29

FS#1254 - NFSv3 not working out of the box.

https://chakraos.org/forum/viewtopic.php?id=14435

Chakra installs a /usr/lib/systemd/system/nfs-client.target unit file which comments,

==
# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=nfs-blkmap.service rpc-statd-notify.service
==

Yet mount.nfs does not on Chakra seem to do anything of the sort; NFSv3 mounts fail due to rpc.statd not running. I've worked around this locally by copying /usr/lib/systemd/rpc-statd.service to /etc/systemd/system and adding at the end,

==
[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target
==

One can then manually enable/start rpc-statd through

$ sudo systemctl enable rpc-statd.service
$ sudo systemctl start rpc-statd.service

but I expect that whomever packages mount.nfs may want to look in to this? Or otherwise whomever packages said nfs-client.target unit file?
Description:

* package version(s) nfs-utils 1.3.2-1

This task does not depend on any other tasks.

René Herman (rene)
Sunday, 29 November 2015, 23:44 GMT
Believe I should have called this a "Bug Report" rather than "Broken Package"; can't change it now.
Neofytos Kolokotronis (tetris4)
Sunday, 21 February 2016, 00:51 GMT
nfs-client.targetHi rene,

Am way out of my league on this one, but I notice we ship this package similarly to Arch. Both nfs-client.target and rpc-statd.service files are the ones that ship by upstream. Are you sure this workaround is needed? Did you try just following the ArchWiki?
https://wiki.archlinux.org/index.php/NFS
René Herman (rene)
Sunday, 21 February 2016, 13:13 GMT
Not currently using Chakra (and too busy to experiment now) but yes, at the time of writing this was needed. And yes, I looked at the Arch wiki; am in fact a former Arch user and back then also had frequent issues with systemd (-setup) changing out from under my/arch's setup without seemingly anyone caring or even noticing. That is part of the "former" bit.

It should be easy to test; have a NFSv3 only server (such as an older home NAS, but certainly a so configured general linux box will do as well) export something and try to mount it on a vanilla Chakra box. The quoted comment in the systemd unit file says that under the specific setup it supports, mount.nfs is expected to dynamically start rpc.statd in that situation. It probably does on Fedora, likely does not on Arch, certainly did not on Chakra when this was filed.

rpc.statd is not needed for NFSv4 and it is therefore not considered polite any more to just start it unconditionally at boot. Which makes sense if the described interaction with mount.ns works, but breaks all not v4-only setups otherwise. As in the report, my solution was to start it unconditionally anyway; the better one is to have mount.nfs comply. Maybe Fedora will show how to?

Loading...