"hom...@163.com": > I thought the xino option is necessary for aufs mount when has branch of > nfs filesystem.
Generally you don't need to specify xino option. Refer to aufs manual for its default path. > When I reboot the system, the xino option works. Now I add the xino > option to mount again. Now I didn't find that warnning in kernel log. But the problem of chown still remains, right? Even if we make the kernel log very verbose (by chaging printk under procfs), it didn't give us good info. Hmm, have you ever tried collecting network packet, by wireshark or something? If we can see the packets between nfs client and server, we may be able find which side the problem exists on. I thought the problem is related to XATTR or LSM because there ever have benn the similar problems. But your repoort indicated it was not. Now I'd like to narrow down the range (layers) where the problem happens. Current candidates are vfs, aufs, nfs(client) and the server side. Since you have no experience building your kernel, we have no good method to see vfs and aufs. If we can see the packets between nfs server and client, and the client sends the request correctly, then it means the problem exists on the server side. Can you try packet dumping? J. R. Okajima
