Permissions for root user

[Christoph Pleger]

Hello,

how about permissions for the root user in an aufs filesystem? Should they
not be the same like on a local filesystem or an NFS filesystem with
no_root_squash set? I am using aufs over NFS to get a writable NFSROOT
filesystem, and as root, I cannot create a file in a directory which is
not "officially" writable by root, for example in my /var/lib/nfs:

***@name:/var/lib/nfs# ls -al
total 4
drwxr-xr-x 2 systemd-network nogroup .....
drwxr-xr-x 31 root root .....
***@name:/var/lib/nfs# touch file
touch: cannot touch 'file': Operation not supported

This is a real problem for me, because it prevents some boot time services
from being started successfully.

Regards
Christoph

[s***@users.sourceforge.net]

Hello Christoph,

Post by Christoph Pleger
how about permissions for the root user in an aufs filesystem? Should they
not be the same like on a local filesystem or an NFS filesystem with
no_root_squash set? I am using aufs over NFS to get a writable NFSROOT
filesystem, and as root, I cannot create a file in a directory which is

Basically aufs respects all permissions on branch fs and follows its
behaviour. Are you using aufs on NFS client with the writable NFS
branch, or export aufs on NFS server? Anyway the behaviour of aufs has
nothing special. If you want to gain the root access from NFS client,
you need to setup NFS server. I'd suggest you to read aufs manual,
especially the section "Exporting Aufs via NFS" if your aufs in on NFS
server.

And next time when you post, provide these info please.

(from aufs README)
----------------------------------------------------------------------
When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- /debug/aufs/* (if you have them)
- linux kernel version
if your kernel is not plain, for example modified by distributor,
the url where i can download its source is necessary too.
- aufs version which was printed at loading the module or booting the
system, instead of the date you downloaded.
- configuration (define/undefine CONFIG_AUFS_xxx)
- kernel configuration or /proc/config.gz (if you have it)
- behaviour which you think to be incorrect
- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net

Usually, I don't watch the Public Areas(Bugs, Support Requests, Patches,
and Feature Requests) on SourceForge. Please join and write to
aufs-users ML.
----------------------------------------------------------------------


J. R. Okajima

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net
Basically aufs respects all permissions on branch fs and follows its
behaviour. Are you using aufs on NFS client with the writable NFS
branch, or export aufs on NFS server?

I am exporting as readonly from the NFS server and I am using aufs on the
client to make files and directories writable there. To achieve this, I
changed/added some things in the initrd nfs script: Instead of mounting
the NFS filesystem to /root, the script mounts it to /roroot, then creates
a writable aufs filesystem by

ln -s /proc/mounts /etc/mtab
mount -t tmpfs tmpfs /tmpfs
mount -t aufs -o dirs=/tmp=rw:/roroot=ro union1 /root

Post by s***@users.sourceforge.net
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- kernel configuration or /proc/config.gz (if you have it)

This information is attached.

Post by s***@users.sourceforge.net
- linux kernel version
if your kernel is not plain, for example modified by distributor,
the url where i can download its source is necessary too.

Debian kernel version 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1
(2015-03-01) x86_64 GNU/Linux, downloadable from
http://ftp.debian.org/debian/pool/main/l/linux/

Post by s***@users.sourceforge.net
- aufs version which was printed at loading the module or booting the
system, instead of the date you downloaded.

aufs 3.16-20140908

Post by s***@users.sourceforge.net
- configuration (define/undefine CONFIG_AUFS_xxx)

This is part of the kernel configuration.

Regards
Christoph

[Yair Yarom]

Hello,

I think we encountered a similar issue, in our case with the /var/log/*
directories (and sometimes /var/cache/man). I don't think it's a real
permission issue as we get "Operation not supported" and not "Permission
denied".

I noticed that it happens if the rw branch doesn't contain the
directory. So in our case we solved it by creating all the directories
on the rw branch, something like:

# root is nfs ro mounted on / and on /boot/root
# /var_rw is local disk or tmpfs
# /var is mounted /var_rw=rw,/var=ro

cd /boot/root/var
for d in log `find log -mindepth 1`; do
dst="/var_rw/$d"
if [[ ! -e "$dst" ]]; then
if [[ -d "$d" ]]; then
echo "creating $dst"
mkdir "$dst"
chown --reference=$d "$dst"
chmod --reference=$d "$dst"
fi
fi
done


Regards,
Yair.

Post by Christoph Pleger
Hello,

Post by s***@users.sourceforge.net
Basically aufs respects all permissions on branch fs and follows its
behaviour. Are you using aufs on NFS client with the writable NFS
branch, or export aufs on NFS server?

I am exporting as readonly from the NFS server and I am using aufs on the
client to make files and directories writable there. To achieve this, I
changed/added some things in the initrd nfs script: Instead of mounting
the NFS filesystem to /root, the script mounts it to /roroot, then creates
a writable aufs filesystem by
ln -s /proc/mounts /etc/mtab
mount -t tmpfs tmpfs /tmpfs
mount -t aufs -o dirs=/tmp=rw:/roroot=ro union1 /root

Post by s***@users.sourceforge.net
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- kernel configuration or /proc/config.gz (if you have it)

This information is attached.

Post by s***@users.sourceforge.net
- linux kernel version
if your kernel is not plain, for example modified by distributor,
the url where i can download its source is necessary too.

Debian kernel version 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1
(2015-03-01) x86_64 GNU/Linux, downloadable from
http://ftp.debian.org/debian/pool/main/l/linux/

Post by s***@users.sourceforge.net
- aufs version which was printed at loading the module or booting the
system, instead of the date you downloaded.

aufs 3.16-20140908

Post by s***@users.sourceforge.net
- configuration (define/undefine CONFIG_AUFS_xxx)

This is part of the kernel configuration.
Regards
Christoph
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

[s***@users.sourceforge.net]

Hello Yair,

Post by Yair Yarom
I think we encountered a similar issue, in our case with the /var/log/*
directories (and sometimes /var/cache/man). I don't think it's a real
permission issue as we get "Operation not supported" and not "Permission
denied".

Are you using user-space NFS server too?
If so, does this script surely reproduce the problem?
This script prints "0" at the end when everything is fine.


J. R. Okajima

[Yair Yarom]

Post by s***@users.sourceforge.net

Post by Yair Yarom
I think we encountered a similar issue, in our case with the /var/log/*
directories (and sometimes /var/cache/man). I don't think it's a real
permission issue as we get "Operation not supported" and not "Permission
denied".

Are you using user-space NFS server too?
If so, does this script surely reproduce the problem?
This script prints "0" at the end when everything is fine.

Our nfs servers are NetAPP and FreeBSD machines (not user space...).

The script itself prints "0", however I currently don't have time to
thoroughly check it. In a couple of days when I have time I'll try to
see if I can make a script that reproduces the problem.

Yair.

[s***@users.sourceforge.net]

Post by Yair Yarom
Our nfs servers are NetAPP and FreeBSD machines (not user space...).

Ok.
And your NFS client is debian 3.16.7-ckt7-1 as Christoph's?

Post by Yair Yarom
The script itself prints "0", however I currently don't have time to
thoroughly check it. In a couple of days when I have time I'll try to
see if I can make a script that reproduces the problem.

Thanx in advance.


J. R. Okajima

[Yair Yarom]

Post by s***@users.sourceforge.net

Post by Yair Yarom
Our nfs servers are NetAPP and FreeBSD machines (not user space...).

Ok.
And your NFS client is debian 3.16.7-ckt7-1 as Christoph's?

Sorry, I've probably should have mentioned it, we compile our own
kernels (currently only with aufs patch, but sometimes with other
patches). I've seen this in 3.16.2, 3.17.8 and I think 3.18.1. When I
have time I will check exactly which kernels.

Yair.

[Yair Yarom]

Post by Yair Yarom

Post by s***@users.sourceforge.net
Are you using user-space NFS server too?
If so, does this script surely reproduce the problem?
This script prints "0" at the end when everything is fine.

Our nfs servers are NetAPP and FreeBSD machines (not user space...).
The script itself prints "0", however I currently don't have time to
thoroughly check it. In a couple of days when I have time I'll try to
see if I can make a script that reproduces the problem.

It seems the script doesn't mount the nfs, so I'm a bit puzzled about
what it was suppose to check.

In any case, though I don't think it was my original problem (but I
might be wrong), it appears that currently if the nfs is mounted with
"noacl", it might fail with Operation not supported even if the nfs
mount is rw and can be changed directly on the mount.

The attached script reproduces the Operation not supported when trying
to move a file on the aufs (though moving it on the nfs works). It's not
as nice as yours, it prints some stuff, and assumes nfs-kernel-server is
already running.

Yair.

[s***@users.sourceforge.net]

Post by Yair Yarom
It seems the script doesn't mount the nfs, so I'm a bit puzzled about
what it was suppose to check.

Oops!
I am afraid I remove the line accidentaly. Sorry.

Post by Yair Yarom
In any case, though I don't think it was my original problem (but I
might be wrong), it appears that currently if the nfs is mounted with
"noacl", it might fail with Operation not supported even if the nfs
mount is rw and can be changed directly on the mount.

Thanx for the script.

On my test system where NFS server is linux, the first mv back failed.
:::
exporting localhost:/tmp/irush/export
+ mv -v /tmp/irush/nfs/a/b /tmp/irush/nfs/a/c
`/tmp/irush/nfs/a/b' -> `/tmp/irush/nfs/a/c'
mv: cannot move `/tmp/irush/nfs/a/b' to `/tmp/irush/nfs/a/c': Permission denied
:::

Anyway ACL is a good hint actually.
While I cannot reproduce your problem on my side, I'd suggest you to try
a branch attribute "icexsys" for the writable branch such as
# mount -t aufs -o br:$tmp/rw=rw+icexsys:$tmp/nfs=ro aufs $tmp/union

For details, refer to
linux/Documentation/filesystems/aufs/design/xattr.txt and aufs manual in
aufs-util.git.


J. R. Okajima

[Yair Yarom]

Post by s***@users.sourceforge.net
On my test system where NFS server is linux, the first mv back failed.
exporting localhost:/tmp/irush/export
+ mv -v /tmp/irush/nfs/a/b /tmp/irush/nfs/a/c
`/tmp/irush/nfs/a/b' -> `/tmp/irush/nfs/a/c'
mv: cannot move `/tmp/irush/nfs/a/b' to `/tmp/irush/nfs/a/c': Permission denied

This is weird, assuming no_root_squash - it should work..

Post by s***@users.sourceforge.net
Anyway ACL is a good hint actually.
While I cannot reproduce your problem on my side, I'd suggest you to try
a branch attribute "icexsys" for the writable branch such as
# mount -t aufs -o br:$tmp/rw=rw+icexsys:$tmp/nfs=ro aufs $tmp/union

This didn't help. I still see "Operation not supported" in the aufs
mv. This time I tried on a freshly complied 3.19.3.


Yair.

[s***@users.sourceforge.net]

Post by Yair Yarom
This is weird, assuming no_root_squash - it should work..

Agreed, and I am afraid there is one more something wrong in my test
system.

Post by Yair Yarom

Post by s***@users.sourceforge.net
Anyway ACL is a good hint actually.
While I cannot reproduce your problem on my side, I'd suggest you to try
a branch attribute "icexsys" for the writable branch such as
# mount -t aufs -o br:$tmp/rw=rw+icexsys:$tmp/nfs=ro aufs $tmp/union

This didn't help. I still see "Operation not supported" in the aufs
mv. This time I tried on a freshly complied 3.19.3.

How was the configuration?
If CONFIG_AUFS_XATTR is enabled, try this patch and specify 'verbose'
option when mounting aufs. It will print the xattr name. If XATTR (ACL)
causes the problem, then this patch and 'verbose' will tell us.

# mount -t aufs -o br:$tmp/rw=rw:$tmp/nfs=ro,verbose aufs $tmp/union

If CONFIG_AUFS_XATTR is disabled, then XATTR/ACL is not the problem. I'd
ask you to enable CONFIG_AUFS_DEBUG and run

# echo 1 > /sys/module/aufs/parameter/debug
mv -v $tmp/union/a/{b,c}
# echo 0 > /sys/module/aufs/parameter/debug

It will print many debug messages which we can start narrowing down the
cause.


J. R. Okajima

[Yair Yarom]

Post by s***@users.sourceforge.net
How was the configuration?
If CONFIG_AUFS_XATTR is enabled, try this patch and specify 'verbose'
option when mounting aufs. It will print the xattr name. If XATTR (ACL)
causes the problem, then this patch and 'verbose' will tell us.
# mount -t aufs -o br:$tmp/rw=rw:$tmp/nfs=ro,verbose aufs $tmp/union

CONFIG_AUFS_XATTR is enabled. Adding verbose (and/or -v) doesn't print
anything that I could find, do I need another option for verbose? or
where should it be printed?

Post by s***@users.sourceforge.net
If CONFIG_AUFS_XATTR is disabled, then XATTR/ACL is not the problem. I'd
ask you to enable CONFIG_AUFS_DEBUG and run
# echo 1 > /sys/module/aufs/parameter/debug
mv -v $tmp/union/a/{b,c}
# echo 0 > /sys/module/aufs/parameter/debug

I've enabled debug (for the mount as well). For good measure, I'm
attaching all the relevant data (including dmesg output). The kernel is
3.19.3 with the patch you sent, and the only aufs mounted is the one
after running the script (when not unmounting it).

In the coming week, I probably won't have much time to check this
further.

Yair.

[s***@users.sourceforge.net]

Post by Yair Yarom
CONFIG_AUFS_XATTR is enabled. Adding verbose (and/or -v) doesn't print
anything that I could find, do I need another option for verbose? or
where should it be printed?

It the system logfile with the priority kern.err.

Post by Yair Yarom
I've enabled debug (for the mount as well). For good measure, I'm
attaching all the relevant data (including dmesg output). The kernel is
3.19.3 with the patch you sent, and the only aufs mounted is the one
after running the script (when not unmounting it).

Your case looks different a little bit from Christoph Pleger's, but it
must be same essentially. I've found linux NFS client always sets
MS_POSIXACL (which is a flag in VFS layer) even if it was mounted with
'noacl.' I don't think it illegal or violation something, but it surely
makes aufs (and me) confused. I may need some dirty workaround, but I'll
consider more and more.
When I found a solution, I'll send you a patch and ask a test.


J. R. Okajima

[s***@users.sourceforge.net]

Post by s***@users.sourceforge.net
Your case looks different a little bit from Christoph Pleger's, but it
must be same essentially. I've found linux NFS client always sets
MS_POSIXACL (which is a flag in VFS layer) even if it was mounted with
'noacl.' I don't think it illegal or violation something, but it surely
makes aufs (and me) confused. I may need some dirty workaround, but I'll
consider more and more.
When I found a solution, I'll send you a patch and ask a test.

Here is my current solution, a dirty work-around.
When you have time, pleast test.


J. R. Okajima

[Yair Yarom]

Post by s***@users.sourceforge.net

Post by s***@users.sourceforge.net
Your case looks different a little bit from Christoph Pleger's, but it
must be same essentially. I've found linux NFS client always sets
MS_POSIXACL (which is a flag in VFS layer) even if it was mounted with
'noacl.' I don't think it illegal or violation something, but it surely
makes aufs (and me) confused. I may need some dirty workaround, but I'll
consider more and more.
When I found a solution, I'll send you a patch and ask a test.

Here is my current solution, a dirty work-around.
When you have time, pleast test.

The patch indeed fixes my problem.

Thank you very much,
Yair.

[s***@users.sourceforge.net]

Post by Yair Yarom

Post by s***@users.sourceforge.net
Here is my current solution, a dirty work-around.
When you have time, pleast test.

The patch indeed fixes my problem.
Thank you very much,

Because the patch is related to the security, I will release it after
testing more and more. It may take some time.


J. R. Okajima

[s***@users.sourceforge.net]

Post by Christoph Pleger
I am exporting as readonly from the NFS server and I am using aufs on the
client to make files and directories writable there. To achieve this, I
changed/added some things in the initrd nfs script: Instead of mounting
the NFS filesystem to /root, the script mounts it to /roroot, then creates
a writable aufs filesystem by
ln -s /proc/mounts /etc/mtab
mount -t tmpfs tmpfs /tmpfs
mount -t aufs -o dirs=/tmp=rw:/roroot=ro union1 /root

The "mounts" attachment is empty.
But I can guess your /roroot is NFS, and it is exported readonly on NFS
server.

For NFS branch, there are two levels of permission check.
- dir's cached permission bits only, no server interaction.
- ask NFS server.

I guess your case has fallen to the second level, and the workaround wil
be necessary as Yair Yarom is doing. Also I am afraid that 'dirperm1'
option won't help.
But this is a little surprise to me since aufs has already solved this
issue many years before if I remember correctly. I wonder some recent
changes in NFS may be affected. I'll check when I have time.


J. R. Okajima

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net
The "mounts" attachment is empty.

A strange behaviour I did not know about before: scp
***@nfs_client:/proc/mounts indeed reproducably creates an empty file on
my workstation. First creating a local copy and then scp-ing it worked, I
attached the result.

Post by s***@users.sourceforge.net
But I can guess your /roroot is NFS, and it is exported readonly on NFS
server.
For NFS branch, there are two levels of permission check.
- dir's cached permission bits only, no server interaction.
- ask NFS server.
I guess your case has fallen to the second level

What I do not understand here, is why the NFS server does not allow the
operation, though it does if the directory is exported read-write (I
tested that).

Regards
Christoph

[s***@users.sourceforge.net]

Post by Christoph Pleger
What I do not understand here, is why the NFS server does not allow the
operation, though it does if the directory is exported read-write (I
tested that).

Exported with rw,no_root_squash? And root user on NFS client could not
create a file? Hmm, that is strange. I will check in a few days.


J. R. Okajima

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net

Post by Christoph Pleger
What I do not understand here, is why the NFS server does not allow the

operation, though it does if the directory is exported read-write (I
tested that).

Post by s***@users.sourceforge.net
Exported with rw,no_root_squash? And root user on NFS client could not

create a file? Hmm, that is strange. I will check in a few days.

Probably I did not describe detailed enough. Root can create a file in a
directory where he does not have 'official' write permissions if the NFS
server exports read-write and the client does not use aufs. Root cannot
create in such a directory if the NFS server exports read-only and the
client uses aufs.

Now, I found another strange thing with aufs:

***@nfs_client:/var/lib/nfs# ls -al
total 12
drwxr-xr-x 4 systemd-network nogroup 60 Mar 26 09:45 .
drwxr-xr-x 32 root root 120 Mar 26 09:36 ..
drwxr-xr-x 2 statd nogroup 4096 Feb 28 2009 sm
drwxr-xr-x 2 statd nogroup 4096 Feb 28 2009 sm.bak
-rw-r--r-- 1 root root 5 Mar 26 09:36 state
***@nfs_client:/var/lib/nfs# touch file
touch: cannot touch 'file': Operation not supported
***@nfs_client:/var/lib/nfs# echo >> state
***@nfs_client:/var/lib/nfs# touch file
***@nfs_client:/var/lib/nfs# ls -al
***@tombom:/var/lib/nfs# ls -al
total 12
drwxr-xr-x 4 systemd-network nogroup 80 Mar 26 09:47 .
drwxr-xr-x 32 root root 120 Mar 26 09:36 ..
-rw-r--r-- 1 root root 0 Mar 26 09:47 file
drwxr-xr-x 2 statd nogroup 4096 Feb 28 2009 sm
drwxr-xr-x 2 statd nogroup 4096 Feb 28 2009 sm.bak
-rw-r--r-- 1 root root 5 Mar 26 09:36 state

That is, after writing something to an already existing file, the
'Operation not supported' problem suddenly disappears.

Regards
Christoph

[s***@users.sourceforge.net]

Post by Christoph Pleger
That is, after writing something to an already existing file, the
'Operation not supported' problem suddenly disappears.

I guess it is due to the dir hierarchy is already copied-up.

I will try by myself in a few days, but I'd ask you to identify the
systemcall which returned the error. open(2) or other? Please try
# strace -o /tmp/s touch file
and post /tmp/s.
And is your NFS server Debian's 3.16.7-ckt7-1 too?

Another interesting issue in your example is that the size of 'state' is
not changed after "echo >> state".
That it strange too.


J. R. Okajima

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net
I will try by myself in a few days, but I'd ask you to identify the
systemcall which returned the error. open(2) or other? Please try
# strace -o /tmp/s touch file
and post /tmp/s.

I attached the resulting file.

Post by s***@users.sourceforge.net
And is your NFS server Debian's 3.16.7-ckt7-1 too?

I am using a user-space NFS-Server, unfs3. This is because the server runs
in a semi-virtualized machine where nfs kernel server does not work.

Regards
Christoph

[s***@users.sourceforge.net]

Post by Christoph Pleger
I am using a user-space NFS-Server, unfs3. This is because the server runs
in a semi-virtualized machine where nfs kernel server does not work.

Then I'd ask you to try kernel-space NFS server and compare the result.
Can't you try kernel-space NFS server temporary on the localhost?
For example,
- run kernel-space NFS server on the localhost
- mkdir -p /tmp/fake/var/lib/nfs
- export /tmp/fake with rw,no_root_squash
- mount -o ro localhost:/tmp/rodir /tmp/fake
- mount -t aufs -o br:/tmp/rwdir:/tmp/rodir none /tmp/u
- cd /tmp/u/var/lib/nfs
- touch file


J. R. Okajima

[Peppin bright]

Thanks for your words...

http://www.besanttechnologies.com/training-courses/data-warehousing-
training/hadoop-training-institute-in-chennai


------------------------------------------------------------------------------

[Christoph Pleger]

Hello,

Essentially aufs checks the permission by calling VFS routine or branch

fs's routine.

I still don't undrestand your situation. Does this script surely

reproduce the problem?

This script prints "0" at the end when everything is fine.

The script prints 0 - but it does not check the case where my error
occurs, when the directory where root wants to create a file does not
belong to root and root has no normal write permissions in that directory,
but he should be able to create a file because of superuser privileges.

Regards
Christoph

[s***@users.sourceforge.net]

Post by Christoph Pleger
The script prints 0 - but it does not check the case where my error
occurs, when the directory where root wants to create a file does not
belong to root and root has no normal write permissions in that directory,
but he should be able to create a file because of superuser privileges.

The owner of the dir is 'bin' instead of 'root.'
Isn't it enough?
Would you modify the script to reproduce the problem?


J. R. Okajima

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net
The owner of the dir is 'bin' instead of 'root.'
Isn't it enough?
Would you modify the script to reproduce the problem?

Sorry, after the result of the script was 0, I did a quick check of the
script code and obviously I missed the line where chown is called.

Now I found that the script was successful because the machine where I
tested it has another Debian version installed than the other machine. I
compared two Debian 7 nfs clients with two Debian 8 nfs clients, in Debian
7 file creation was successful, in Debian 8 it was not.

Regards
Christoph

[s***@users.sourceforge.net]

Post by Christoph Pleger
Now I found that the script was successful because the machine where I
tested it has another Debian version installed than the other machine. I
compared two Debian 7 nfs clients with two Debian 8 nfs clients, in Debian
7 file creation was successful, in Debian 8 it was not.

I guess it is related to ACL.
When CONFIG_NFS_V3_ACL is enabled, NFS client confirms whether NFS
server supports ACL or not. Your userspace NFS server doesn't seem to be
supporting ACL and it returns "Operation not supported."

As long as unfs3 doesn't support ACL, you need to disable
CONFIG_NFS_V3_ACL I am afraid.


J. R. Okajima

[Christoph Pleger]

Hello,#

Post by s***@users.sourceforge.net

Post by Christoph Pleger
Now I found that the script was successful because the machine where I
tested it has another Debian version installed than the other machine. I
compared two Debian 7 nfs clients with two Debian 8 nfs clients, in Debian
7 file creation was successful, in Debian 8 it was not.

I guess it is related to ACL.
When CONFIG_NFS_V3_ACL is enabled, NFS client confirms whether NFS
server supports ACL or not. Your userspace NFS server doesn't seem to be
supporting ACL and it returns "Operation not supported."
As long as unfs3 doesn't support ACL, you need to disable
CONFIG_NFS_V3_ACL I am afraid.

I switched from unfs3 to nfs-ganesha now, which supports NFSv4 with ACLs,
and with that, the problem disappeared.

Regards
Christoph

[Christoph Pleger]

Hallo,

Post by Christoph Pleger

Post by s***@users.sourceforge.net
I guess it is related to ACL.
When CONFIG_NFS_V3_ACL is enabled, NFS client confirms whether NFS
server supports ACL or not. Your userspace NFS server doesn't seem to be
supporting ACL and it returns "Operation not supported."
As long as unfs3 doesn't support ACL, you need to disable
CONFIG_NFS_V3_ACL I am afraid.

I switched from unfs3 to nfs-ganesha now, which supports NFSv4 with ACLs,
and with that, the problem disappeared.

I am coming back to this old thread from March/April 2015. Because, when
just switching from Debian 8 to Ubuntu 16.04 on the NFS client, without
changing anything on the NFS server, I get "Operation not supported" again
when trying to write anything to a read-write aufs on top of a read-only
NFS.

Kernel version is 4.4.0-47-generic from Ubuntu 16.04, the kernel source is
downloadable on

http://de.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-source-4.4.0_4.4.0-47.68_all.deb

This file must be extracted with ar x, then data.tar.xz must be extracted,
then the source is in usr/src .

Necessary files are attached.

Regards
Christoph Pleger

[s***@users.sourceforge.net]

Post by Christoph Pleger
I am coming back to this old thread from March/April 2015. Because, when
just switching from Debian 8 to Ubuntu 16.04 on the NFS client, without
changing anything on the NFS server, I get "Operation not supported" again
when trying to write anything to a read-write aufs on top of a read-only
NFS.

Amazingly old mail thread.
Anyway, would you try strace and find which systemcall returns the
error?
And if you can, try re-compiling aufs module with CONFIG_AUFS_DEBUG=y,
set the module parameter 'debug' to Y, and reproduce the problem. Then
we may be able to see something in the kernel log if we have a luck.


J. R. Okajima

------------------------------------------------------------------------------

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net

Post by Christoph Pleger
I am coming back to this old thread from March/April 2015. Because, when
just switching from Debian 8 to Ubuntu 16.04 on the NFS client, without
changing anything on the NFS server, I get "Operation not supported" again
when trying to write anything to a read-write aufs on top of a read-only
NFS.

Amazingly old mail thread.
Anyway, would you try strace and find which systemcall returns the
error?
And if you can, try re-compiling aufs module with CONFIG_AUFS_DEBUG=y,
set the module parameter 'debug' to Y, and reproduce the problem. Then
we may be able to see something in the kernel log if we have a luck.

After installing the new-compiled module to the initramfs, the test
computer does not boot as far as it did before, but I can see interesting
messages on the console, like this:

[ 193.1356342] aufs au_do_cpup_xattr:96:setupcon[987]: system.nfs4_acl,
err -95

I compared the kernel configs of Debian 8 and Ubuntu 16.04 and found that
that the Ubuntu kernel has an option "CONFIG_AUFS_XATTR", which is not
present in the Debian kernel.

Regards
Christoph


------------------------------------------------------------------------------

[s***@users.sourceforge.net]

Post by Christoph Pleger
[ 193.1356342] aufs au_do_cpup_xattr:96:setupcon[987]: system.nfs4_acl,
err -95

This message means that
- the internal copy-up happens.
- the file on the lower branch has an XATTR called "system.nfs4_acl".
- as a part of copy-up, aufs tries copying all XATTR from lower to
upper.
- but the upper branch doesn't support "system.nfs4_acl", and aufs gets
an error.

In other words, your lower nfs4 branch supports XATTR including its own
specific one, but obviously your upper tmpfs branch doesn't know such
XATTR at all.

Aufs has some branch attributes to address such case.
- read the manual, especially
.TP
.B icexsec | icexsys | icextr | icexusr | icexoth | icex
Ignore the error on copying\-up/down XATTR.
When an internal copy\-up/down happens, aufs tries copying all XATTRs.
Here an error can happen because of the XATTR support on the dst
branch may different from the src branch. If you know how the branch
supports or unsupports XATTR, you can specify these attributes.
`icexsec' means to ignore an error on copying\-up/down XATTR categorized
as "security" (for LSM and capability). And `icexsys,' `icextr,' and
`icexusr,' are for "system" (for posix ACL), "trusted" and "user"
categories individually.
`icexoth' is for any other category. To be convenient, `icex` sets them
all.
See also linux/Documentation/filesystems/aufs/design/06xattr.txt.

These attributes are essentially for the writable branches. But when you
use
.B
aufs_fhsm(5),
you may want to
specify them to the readonly branches too. So they are available for the
readonly branches.

- and specify "icexsys" attr to your upper rw branch, such like
# mount -t aufs -o br:/live/cow=rw+icexsys:/live/image none /your/aufs

For your case, there may exist some other workarounds such like
- specify 'noacl' to branches.
- re-configure and disable xattr.
- etc.
But I'd suggest you to try "icexsys" first, because it doesn't require
re-compiling.


J. R. Okajima

------------------------------------------------------------------------------

[Christoph Pleger]

Hello,

Post by s***@users.sourceforge.net
But I'd suggest you to try "icexsys" first, because it doesn't require
re-compiling.

It works with icexsys. Crazy that I had to re-build aufs-util myself,
because Ubuntu is so smart to use version 4.x+rcN in the kernel, but
version 3.x of aufs-util.

Regards
Christoph


------------------------------------------------------------------------------