Hi, Okajima San,
I found the error in packetdump2: setattr ERROR: Operation not
permitted
I think aufs works well when mount the local path as the first
writable branch. Maybe local container using fuse, so container root
user can do setattr success. But in nfs server side, no fuse filesystem
using, so the remote container( relate to the nfs server side) can't do
setattr to the nfs server file?
__________________________________________________________________
Michael Mao
From: [1][email protected]
Date: 2020-03-22 13:15
To: [2]hooanon05g
CC: [3]aufs-users
Subject: Re: Re: LXC unpreviliged problem with aufs mounted on nfs
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: [email protected]
Date: 2020-03-22 13:10
To: hooanon05g
CC: 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: [email protected]
Date: 2020-03-22 12:35
To: hooanon05g
CC: 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: [email protected]
CC: aufs-users
Subject: Re: LXC unpreviliged problem with aufs mounted on nfs
"[email protected]":
> 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][email protected]
CC: [3]aufs-users
Subject: Re: LXC unpreviliged problem with aufs mounted on nfs
"[email protected]":
> 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:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
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][email protected]
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][email protected]
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: [email protected]
CC: aufs-users
Subject: Re: LXC unpreviliged problem with aufs mounted on nfs
"[email protected]":
> 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][email protected]
CC: [3]aufs-users
Subject: Re: LXC unpreviliged problem with aufs mounted on nfs
"[email protected]":
> 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:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
References
1. mailto:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
4. mailto:[email protected]
5. mailto:[email protected]
6. mailto:[email protected]
References
1. mailto:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
