Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#8486 - [nfs-utils] NFSv4 utils: idmapd + gss init script, gssd

Attached to Project: Arch Linux
Opened by Anonymous (abelstern) - Friday, 02 November 2007, 16:21 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 15 June 2009, 20:19 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


Currently Arch doesn't support NFSv4, and because of it's advantages over NFSv3 (secure auth, speed, for two) it seems a good idea to support it. Doing this is quite easy: the only thing Arch lacks is autostarted rpc.idmapd and rpc.gssd daemons.

The rpc.gssd is not compiled in nfs-utils and can easily added by deleting the --disable-gss flag in the PKGBUILD.

The rpc.idmapd needs a default /etc/idmapd.conf.

Both gssd and idmapd need an init script like Debian's nfs-common script, maybe controlled by some conf.d to be able to disable them (as an NFSv3 user doesn't need either of the daemons).

(Personal NFSv4 support init script attached)
(Quite generic /etc/idmapd.conf attached)
This task depends upon
 FS#8509 - Add nfs4 to netfs automounts. 

Closed by  Tobias Powalowski (tpowa)
Monday, 15 June 2009, 20:19 GMT
Reason for closing:  Implemented
Additional comments about closing:  nfs-utils 1.2.0-1
Comment by Anonymous (abelstern) - Friday, 02 November 2007, 17:01 GMT
It seems necessary also to mount rpc_pipefs on /var/lib/nfs/rpc_pipefs. Doing this, then starting idmapd makes NFSv4 work here!
Comment by Tobias Powalowski (tpowa) - Sunday, 04 November 2007, 09:31 GMT
please add the correct files here
Comment by Attila (attila) - Sunday, 04 November 2007, 11:02 GMT
Thanks Abel for your work because some months ago i try the same and have no success. My question is could it be that you have installed some other own packages too? On ther be listed libgssglue and librpcsecgss as requirements and without them ./configure (i '--disable-gss' with '--enable-nfsv4') fails with 'checking for RPCSECGSS... no'. After making my own packages for them both ./configure fails with 'checking for GSSAPI... configure: error: Package requirements (libgssapi >= 0.11)'. There is a big patch for nfs-utils but i don't know if it will helps.
Comment by Anonymous (abelstern) - Sunday, 04 November 2007, 11:58 GMT
Tthe packages are present but not the headers and all, so I indeed had to compile them myself.
I will to upload the needed packages to AUR, add the init scripts and a patch for the netfs init script (nfs4 is not in the list of mounted FSes) and add a howto on the wiki.
I compiled:
libgssglue, libgssapi, librpcsecgss and nfs-utils with --enable-gss.

When the work is done, I'll comment here again.
Comment by Attila (attila) - Sunday, 04 November 2007, 18:25 GMT
Your plan looks very nice, thanks again.
I found a way to compile nfs-utils by including this lines in the PKGBUILD first after 'build() {':
export GSSAPI_CFLAGS='-I/usr/include/gssglue'
export GSSAPI_LIBS='-lgssapi -ldl'
The problem is that the heimdal package has the libs and the gssapi.h but no pkgconfig file for it.
Comment by Anonymous (abelstern) - Sunday, 04 November 2007, 20:42 GMT
I've uploaded librpcsecgss, libgssglue and nfs4-utils to AUR.
I included an /etc/rc.d/nfs4-common init script in nfs4-utils starting the idmap and gss daemons.
I filed a bug for the netfs init script, for nfs4 is not in the list of automounted filesystems there.
A very minimal HOWTO is now on the wiki:

To be continued.
Comment by Anonymous (abelstern) - Tuesday, 06 November 2007, 12:01 GMT
Everything seems to be working now, except for the netfs init script that has yet to be fixed (
The wiki is improved as are the packages on AUR. Attila, would you be willing to test it?

It might even be a good idea to just add those features to nfs-utils: the nfs4-common init script, the /etc/idmapd.conf, the /etc/gssapi_mech.conf (from and rpc.gssd (with two additional dependencies, though:
libgssglue ( and
librpcsecgss (
(And as the GSSAPI provided by heimdal includes no pkg-config entries, either those need to be added, or something similar to
export GSSAPI_CFLAGS='-I/usr/include/gssapi'
export GSSAPI_LIBS='-lgssapi -ldl'
to the PKGBUILD in order for nfs-utils to compile with GSS).

It seems rational to add NFSv4 support to ArchLinux by default, because of the advantages NFSv4 has over NFSv3: strong authentication and integrity via Kerberos and SPKM-3, improved performance, safe file caching, lock migration, ACLs and better support for Windows file sharing semantics.
Comment by Attila (attila) - Tuesday, 13 November 2007, 16:43 GMT
Oh, if forgot to say that i have tested it with arch as client and opensuse 10.3 (in qemu) as server which works as described in your wiki. Perhaps another one could test arch as an nfs4 server. From my view, i don't see a reason which speak against to put the packages to community (or to core) and to append the suggested files to nfs-utils because nfs4 is optional so it shouldn't disturb in environments which wants to stay with nfs3.
Comment by Glenn Matthys (RedShift) - Thursday, 19 June 2008, 11:33 GMT
What's the status of this issue?
Comment by Andrej Podzimek (andrej) - Sunday, 27 July 2008, 16:55 GMT
It would be fine if NFSv4 was supported. It's boring to compile all the libgss stuff manually, then recompile nfs-utils and so forth...