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 to
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 a
"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
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
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
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
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 somethi
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 meas
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:
> 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 "icexs
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 `/t
"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
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 n
On Mon, Mar 30 2015, Yair Yarom 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 NetAPP and
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 scr
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
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?
> 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
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
>>
"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 superus
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 cas
Hello Yair,
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?
"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 lo
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 usin
"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 retur
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
"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 c
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
"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,
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
di
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 cre
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
32 matches
Mail list logo
