search

sahlberg / libnfs

NFS client library
Other
525 stars 202 forks source link

NFS Fails to connect with "RPC Packet not accepted by the server" on Linux > 3.8.8 #33

Closed evanpurkhiser closed 11 years ago

evanpurkhiser commented 11 years ago

Hi,

When I upgraded my NFS server to Linux 3.9.3 the other day I noticed that I was no longer to connect to the NFS share through XBMC (which I believe makes use of this library).

The error in the logs is "RPC Packet not accepted by the server".

I have two outstanding forum threads open about this, one on the XBMC forums and one on the Arch Linux forums.

I can still mount the share just fine from the CLI using nfs-utils with mount -t nfs4, but of course, this requires root.

wumpyr commented 11 years ago

+1

Upgrade from 3.8.4 to 3.9.3 kernel on my NFS server broke openelec 3.0.3 on raspberry pi NFS shares through xbmc. Same error as OP. Mounting share via CLI ok. Only NFSD v3 here.

Downgrade to 3.8.4 fixed it/workaround.

sahlberg commented 11 years ago

libnfs does not support NFSv4 :-(

Can you verify that your server supports NFS v3 and/or enable it ?

On Thu, May 23, 2013 at 1:18 PM, wumpyr notifications@github.com wrote:

+1

Upgrade from 3.8.4 to 3.9.3 kernel on my NFS server broke openelec 3.0.3 on raspberry pi NFS shares through xbmc. Same error as OP. Mounting share via CLI ok. Only NFSD v3 here.

Downgrade to 3.8.4 fixed it/workaround.

— Reply to this email directly or view it on GitHubhttps://github.com/sahlberg/libnfs/issues/33#issuecomment-18368931 .

wumpyr commented 11 years ago

I am hitting this issue only using nfsv3 server.

# grep NFSD .config
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
sahlberg commented 11 years ago

Can you take a network trace of when you run mount and one where you try and use xbmc and send to me?

Latest git master of libnfs contain an example program nfs-ls can you try that utility if it works and take a network trace of it too?

On Thu, May 23, 2013 at 3:43 PM, wumpyr notifications@github.com wrote:

I am hitting this issue only using nfsv3 server. grep NFSD .config

CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4 is not set

— Reply to this email directly or view it on GitHubhttps://github.com/sahlberg/libnfs/issues/33#issuecomment-18376503 .

wumpyr commented 11 years ago

My traces show xbmc/libnfs sending gid of 0xffff. In new kernels NFSD is now returning AUTH_ERROR, bad cred when the gid is -1, 0xffff.

There was a change in the kernel. See https://patchwork.kernel.org/patch/2138181/

Also, reported here: https://bugzilla.redhat.com/show_bug.cgi?id=964319

I tried the proposed patch there but didn't work for me. Ronnie - is xbmc sending gid 0xffff or is this internal to libnfs? Even though they are looking to handle -1 uid/gid, if there is also a fix from your side, that would be great.

sahlberg commented 11 years ago

Hi,

That makes sense. For libnfs running on unix, this was a bug and I have fixed it.

https://github.com/sahlberg/libnfs/commit/43e0e7a7e6cbec9ba55db89eac368d42e969ad55

Basically when creating a rpc/nfs context libnfs will create a context containing an initial default rpc authentication blob. On unix, it created this with -1 for the gid but now it uses getgid() so it creates it using the same gid as the user has.

On windows, which is what most XBMC users use, things are more difficult :

if defined(WIN32)

rpc->auth = authunix_create("LibNFS", 65535, 65535, 0, NULL);

else

rpc->auth = authunix_create_default();

endif

Here I dont know If I have any better solution than setting -1/-1 for uid/gid as the default. I dont think there are any better choice there.

On windows I think the application and/or user will have to either pick a hardcoded value for uid/gid or offer a configuration option to select what to use. And then set it explicitely from the application code using :

rpc_set_auth(rpc, libnfs_authunix_create("hostname", uid, gid, 0, NULL))

and have the application / user decide "which uid/gid should i pretend to be when talking to my server".

On Fri, May 24, 2013 at 5:19 PM, wumpyr notifications@github.com wrote:

My traces show xbmc/libnfs sending gid of 0xffff. In new kernels NFSD is now returning AUTH_ERROR, bad cred when the gid is -1, 0xffff.

There was a change in the kernel. See https://patchwork.kernel.org/patch/2138181/

Also, reported here: https://bugzilla.redhat.com/show_bug.cgi?id=964319

I tried the proposed patch there but didn't work for me. Ronnie - is xbmc sending gid 0xffff or is this internal to libnfs? Even though they are looking to handle -1 uid/gid, if there is also a fix from your side, that would be great.

— Reply to this email directly or view it on GitHubhttps://github.com/sahlberg/libnfs/issues/33#issuecomment-18436558 .

sahlberg commented 11 years ago

If you run on linux/unix can you try git master for libnfs. If this works for you I can prepare a new release of libnfs with this change.

On Sat, May 25, 2013 at 6:42 AM, ronnie sahlberg ronniesahlberg@gmail.comwrote:

Hi,

That makes sense. For libnfs running on unix, this was a bug and I have fixed it.

https://github.com/sahlberg/libnfs/commit/43e0e7a7e6cbec9ba55db89eac368d42e969ad55

Basically when creating a rpc/nfs context libnfs will create a context containing an initial default rpc authentication blob. On unix, it created this with -1 for the gid but now it uses getgid() so it creates it using the same gid as the user has.

On windows, which is what most XBMC users use, things are more difficult :

if defined(WIN32)

rpc->auth = authunix_create("LibNFS", 65535, 65535, 0, NULL);

else

rpc->auth = authunix_create_default();

endif

Here I dont know If I have any better solution than setting -1/-1 for uid/gid as the default. I dont think there are any better choice there.

On windows I think the application and/or user will have to either pick a hardcoded value for uid/gid or offer a configuration option to select what to use. And then set it explicitely from the application code using :

rpc_set_auth(rpc, libnfs_authunix_create("hostname", uid, gid, 0, NULL))

and have the application / user decide "which uid/gid should i pretend to be when talking to my server".

On Fri, May 24, 2013 at 5:19 PM, wumpyr notifications@github.com wrote:

My traces show xbmc/libnfs sending gid of 0xffff. In new kernels NFSD is now returning AUTH_ERROR, bad cred when the gid is -1, 0xffff.

There was a change in the kernel. See https://patchwork.kernel.org/patch/2138181/

Also, reported here: https://bugzilla.redhat.com/show_bug.cgi?id=964319

I tried the proposed patch there but didn't work for me. Ronnie - is xbmc sending gid 0xffff or is this internal to libnfs? Even though they are looking to handle -1 uid/gid, if there is also a fix from your side, that would be great.

— Reply to this email directly or view it on GitHubhttps://github.com/sahlberg/libnfs/issues/33#issuecomment-18436558 .

cjmayo commented 11 years ago

Applying 43e0e7a7e6cbec9ba55db89eac368d42e969ad55 to libnfs-1.5.0 (from Gentoo) gets xbmc-12.2 connecting to an nfs server running Linux 3.9.2 for me. Thanks.

evanpurkhiser commented 11 years ago

I can also confirm that building from master fixes the issue in XBMC.

If anyone is interested, here is a PKGBUILD for Arch Linux file that builds from master

sahlberg commented 11 years ago

Fix confirmed by two users. I just released version 1.6 on libnfs to address this issue (and officialize AROS/Amiga support)