and
test
it.
J. R. Okajima
--
/| |
\/ | Yair Yarom | System Group (DevOps)
[] | The Rachel and Selim Benin School
[] /\| of Computer Science and Engineering
[]//\\/ | The Hebrew University of Jerusalem
[// \\ | T +972-2-5494522 | F +97
else I can do.
Thanks,
--
/| |
\/ | Yair Yarom | System Group (DevOps)
[] | The Rachel and Selim Benin School
[] /\| of Computer Science and Engineering
[]//\\/ | The Hebrew University of Jerusalem
[// \\ | T +972-2-5494522 | F +972-2-5494522
Thanks, the patch works for me (we're usually not using acl, and that's
what I've checked).
Yair.
On Sun, Jan 22 2017, sf...@users.sourceforge.net wrote:
> Hello Yair,
>
> Yair Yarom:
>> We're also seeing this issue, where removexattr returns EINVAL. Our ro
>> branc
We're also seeing this issue, where removexattr returns EINVAL. Our ro
branch is nfs (without acl), and rw branch is tmpfs (without
xattr). Mounting with noacl or with +icex doesn't help. On kernel 4.8 it
worked fine.
Simply mv'ing a directory from ext4 to the aufs will complain:
$ mv /tmp/aaa
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
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.
#
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
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
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
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
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
Hi,
We have here diskless machines with aufsed /etc (rw tmpfs /etc_rw + ro
root /etc on /etc). When trying to run sungrid's qmaster daemon, we get
an oops. Without the aufsed /etc there's no oops (even when there are
other aufsed directories).
The kernel is 2.6.33.3 with aufs standalone from
Hi,
Thanks, I was hoping to avoid this since it tends to be one of the things you
forget to remove or forget they are there during an update (but my other
solution was to mount /sbin using aufs :)).
Thanks,
Yair.
sf...@users.sourceforge.net writes:
Hi,
David:
Why don't you just write
13 matches
Mail list logo
