Hello,
> 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
"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
Hello,
> "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
"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
Yair Yarom:
On Sat, Apr 04 2015, sf...@users.sourceforge.net wrote:
:::
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
Hello,#
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
On Sat, Apr 04 2015, sf...@users.sourceforge.net wrote:
sf...@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
sf...@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,
On Wed, Apr 01 2015, sf...@users.sourceforge.net wrote:
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.
#
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.
I've enabled debug (for the mount as well). For good
On Tue, Mar 31 2015, sf...@users.sourceforge.net wrote:
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
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.
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
On Mon, Mar 30 2015, Yair Yarom ir...@cs.huji.ac.il wrote:
On Sat, Mar 28 2015, sf...@users.sourceforge.net wrote:
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
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.
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.
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
On Mon, Mar 30 2015, sf...@users.sourceforge.net wrote:
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
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
On Sat, Mar 28 2015, sf...@users.sourceforge.net wrote:
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.
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
Hello,
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
Hello,
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
Hello,
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.
And is your NFS server Debian's 3.16.7-ckt7-1 too?
I am using a
Hello Christoph,
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
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
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
Hello,
The mounts attachment is empty.
A strange behaviour I did not know about before: scp
root@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.
But I can guess your /roroot is
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
27 matches
Mail list logo
