NeilBrown [neilb@xxxxxxx] wrote: > Mount with NFSv4 and it takes about the same. However: > > ..... > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2974 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2975 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2976 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2977 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2978 > drwxr-xr-x 2 u2979 root 4096 Oct 8 16:19 2979 > drwxr-xr-x 2 u2980 root 4096 Oct 8 16:19 2980 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2981 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2982 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2983 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2984 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2985 > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2986 > .... > > > tcpdump shows the server is returning the write stuff, but something if going > wrong on the client. I've tried unmounting/remounting and killing/restarting > rpc.idmapd. As you know 4294967294 is (-2, nfs nobody), I have seen this issue with NFS server sending numeric ids by default in AUTH_SYS (commit e9541ce8efc22c233a045f091c2b969923709038), but the client can't handle them (lack of commit 5cf36cfdc8caa2724738ad0842c5c3dd02f309dc in client code). I hand patched server commit, but my client was an older one. That is how I got into my issue. Not sure, if you are running into a similar issue. Regards, Malahal. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
