With the latest nfs package and kernel in portage the nfsv4 server does not work. The problem that I get is when trying to mount a nfs4 filesystem mount locks up and cannot be killed. While this dead(ish) mount process is floating around lots of the following error message appear in the system log of the client: Nov 9 22:26:36 oprah decode_getfattr: xdr error 10008! Nov 9 22:26:47 oprah decode_getfattr: xdr error 10008! Nov 9 22:26:52 oprah decode_getfattr: xdr error 10008! No errors or other such oddness appear on the server. Both the server and the client were running idmapd-1.5 and nfs-utils-1.0.6-r4, and everything relating to nfs4 is enabled in both kernels (2.6.9). To make things more interesting the client system does mount nfs4 from a debian server, however debian also has trouble mounting the nfs4 share from the gentoo server. I managed to get the server to work by updating nfs-utils using the latest CITI patch and nfsidmap. I put together some new ebuilds and will post them later.
Created attachment 43696 [details] nfs-utils with CITI patch This ebuild disables gss/krb5... I have not yet tested krb5 yet. The CITI patch also addes idmapd to nfs-utils, so the old idmapd package is no longer needed. Also, idmapd is now /usr/sbin/rpc.idmapd This also requires a new package nfsidmap.
Created attachment 43697 [details] nfsidmap library ebuild nfsidmap depends on ldap for one of it's idmapping methods. There isn't a clean way to disable it, so openldap is needed even if it won't actually be used :-( Also note that I have not yet tested idmapping, but at least it builds, which is a good first step.
Created attachment 43698 [details] nfs rc script update of the nfs rc script for the idmapd name change
Created attachment 43699 [details] idmapd config file (/etc/idmapd.conf) needed for idmapd in nfs-utils Note that all settings must go in here, idmapd doesn't take command arguments anymore.
Created attachment 43700 [details] idmapd rc script updated idmapd rc script for nfs-utils
This should be everyting needed to get a useable nfs4 server running. Nothing fancy like gss and I don't know if idmapping works or not. But at the very least clients can actually mount it now.
You never had the "NFSv4 not supported!" message? Because, that what I get and I'm just wondering if all of this here will fix it or if it's for completely different things.
Where did you see a "NFSv4 not supported!" message? I recall seeing a message in nfs-utils to emerge idmapd for nfsv4, but not an unsupported message. Anyway, yes, these packages will hopefully get you running with nfs4. I never managed to get ACLs to work and never even looked at gss stuff, but the basics like user mapping and mounting works for me now.
I get the "NFSv4 not supported!" if I try to mount with nfsvers=4 option on the client. I'm sure it's a message coded in mount. Anyhow, I'm in the process of importing your ebuilds here for testing purposes. I'm also doing some minor modifications, like a nfsv4 use switch and small other changes for having ebuilds that will build old v3 nfs as normal as possible. When everything works ok here, I'll somehow submit them to you by email for reviewing. I don't want to "polute" this noise, but rather keep it clean to seriously get nfsv4 going on Gentoo. I'm guessing that the nfsidmap superseed the current idmapd ebuild? Also, on the CITI website, the patches seem to apply to kernel 2.6.10. DO you think the current mm-sources-2.6.9-r1 that I'm using will work?
[quote="comment #1"] The CITI patch also addes idmapd to nfs-utils, so the old idmapd package is no longer needed. Also, idmapd is now /usr/sbin/rpc.idmapd [/quote] Disregard my question. I should open my eyes. 8|
nfsidmap is simply a library that is now required by the new rpc.idmap `mount -t nfs -o vers=4` will not work, you have to mount with `mount -t nfs4` Also, the nfs4 modules in the standard 2.6.9 kernel is enough to get started with. I have not tried any kernel patches, that may be why ACLs don't work for me, I don't know.
Ok, I have worked on this thrue ssh session during the week-end. The ebuilds all build succesfully and the nfsv4 use switch was trivial. The way the service dependency work in nfs (ie: need portmap idmapd) never worked on my system and I don't know why. I start them manually and I guess I could hardcode them in the init script. There's seem to be more then meet the eye. On the client I get errors about portmap failing to be contacted on the localhost. It's sunday late at night and I just made my first attempt. I now go to rest and will get back to it when I arrive at the lab tomorrow.
I just put nfs-utils-1.0.7 into portage with a local USE-flag nfsv4 (since it pulls in kerberos). Does this solve any problems in this bug or create any new ones?
kerberos is not required (i have a few local patches to work around that hard dep), i just didnt get around to testing all of it fully so i hadnt committed it yet
I've never used nfsv4 with kerberos, so the patches to avoid it would be a good thing.
everything should be in cvs now ... i just broke up the nfsv4/kerberos logic into sep USE flags please open a new bug about any problems you have with current work
