ps: last packetdump1 is the tcp data of command running:
useradd newuser,
and got the warnning: useradd: failure while writing changes to
/etc/shadow
this attachment packetdump2 is the data of command:
chown _apt:root aaae
and got the warnning: chown: changing ownership of './aaae':
Operation not permitted
__________________________________________________________________
Michael Mao
From: [1]hom...@163.com
Date: 2020-03-22 13:10
To: [2]hooanon05g
CC: [3]aufs-users
Subject: Re: Re: LXC unpreviliged problem with aufs mounted on nfs
Hi, Okajima San,
Please refer to the attachment of the tcp packdump file.
__________________________________________________________________
Michael Mao
From: [4]hom...@163.com
Date: 2020-03-22 12:35
To: [5]hooanon05g
CC: [6]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: J. R. Okajima
Date: 2020-03-22 11:59
To: hom...@163.com
CC: 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
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: [1]J. R. Okajima
Date: 2020-03-22 11:59
To: [2]hom...@163.com
CC: [3]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:hooanon...@gmail.com
2. mailto:hom...@163.com
3. mailto:aufs-users@lists.sourceforge.net
References
1. mailto:hom...@163.com
2. mailto:hooanon...@gmail.com
3. mailto:aufs-users@lists.sourceforge.net
4. mailto:hom...@163.com
5. mailto:hooanon...@gmail.com
6. mailto:aufs-users@lists.sourceforge.net
packetdump2
Description: Binary data
