Sorry,  fix this:  That will be easier for me to manage the aufs
   mount without the xino option.
   __________________________________________________________________

   Michael Mao



   From: [1]hom...@163.com
   Date: 2020-03-22 12:35
   To: [2]hooanon05g
   CC: [3]aufs-users
   Subject: Re: Re: LXC unpreviliged problem with aufs mounted on nfs

   Hi, Okajima San,
       Thanks. That will be easier for me to manage the aufs mount with
   the xino option.
       Yes, Problem is still there after I reboot the system.
       About the LSM, I just stop the AppArmor service, and setenforce 0
   to close the Selinux. It seems not work.
       About the XATTR, I found some info about fuse_xattrs , which can
   simulate the NFS XATTR. But infomation is too few to check it out.
       I am trying to building the kernel, but the network is slow, it
   will take a long time.
       I will try the packet dumping with tcpdump.  Only NFS packet data
   needed?
   __________________________________________________________________

   Michael Mao



   From: [4]J. R. Okajima
   Date: 2020-03-22 11:59
   To: [5]hom...@163.com
   CC: [6]aufs-users
   Subject: Re: LXC unpreviliged problem with aufs mounted on nfs

   "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

References

   1. mailto:hom...@163.com
   2. mailto:hooanon...@gmail.com
   3. mailto:aufs-users@lists.sourceforge.net
   4. mailto:hooanon...@gmail.com
   5. mailto:hom...@163.com
   6. mailto:aufs-users@lists.sourceforge.net


Reply via email to