Hello,
On 2019-10-26 19:45, Tomas M wrote:
Hello everybody.
I noticed that man didn't work for me in Slax recently (based on
Debian Buster) with the very same error message.
And I found how to fix that. I had to disable apparmor.
I confirm that disabling apparmor solved the problem.
Hello,
On 2019-10-24 09:57, J. R. Okajima wrote:
In the log, at the very early stage line 894, aufs produces BUG msg.
:::
It happened when mkdir[847] issues exit(2). At exitting, all opened
file descriptors are closed by kernel and aufs_release_dir() is
called.
By enabling
Hello,
Do you mean that you applied aufs4-mmap.patch from aufs4.19.63+ and
rebuild your kernel itself not only aufs module?
(but I am not sure whether aufs4-mmap.patch is the cause of the
problem)
Ah, so that file is a kernel patch, I thought that it is just a patch
for aufs itself.
I
Hello,
On 2019-10-21 20:01, J. R. Okajima wrote:
Christoph Pleger:
getfacl shows that all elements in the full path have only the normal
filesystem permissions. lsattr returns errors "Inappropriate ioctl for
device While reading flags on ...", but I also get these errors with
Debian
Hello,
On 2019-10-21 16:23, J. R. Okajima wrote:
At least with libuchardet (probably its the same with other libraries)
the problem is not in finding the correct library. The file tried to
be
opened in line 1464, /usr/lib/x86_64-linux-gnu/libuchardet.so.0, is a
valid symbolic link to a
Hello,
I don't think "bind + umount" is equivalent to "move".
I don't know who wrote this script, but I'd ask him the reason since
'Google >mount move "wrong fs"< for details' didn't give the answer.
If you can, try "move" instead of "bind + umount".
I replaced all combinations of "mount
Hello,
On 2019-10-18 15:08, J. R. Okajima wrote:
I forgot asking one question.
> I have attached the output of strace. Somehow I suspect the ioctl in
> line 2510 to be the problem, but I wonder how aufs can have an effect on
> that TTY operation.
I don't think it is related.
The last part
Hello,
tmpfs /live/cow tmpfs rw,relatime,mode=755 0 0
/dev/sda /live/image iso9660
ro,noatime,nojoliet,check=s,map=n,blocksize=2048 0 0
Is this iso9660 your rr branch?
Yes, you're right. Sorry, I forgot that in that special case I had
booted from a DVD that I had created from the NFSROOT.
Hello,
Will you provide me more details?
The mentioned files are, as far as available, packed in the attached
file. As I have aufs as an external dkms module, and I could not find a
file .config or so, I took the definitions from the make command, I hope
that is sufficient.
Regarding the
Hello,
I have an aufs on top of a read-only NFSROOT here and found that the man
command fails with exit-status 1. This does not happen when I use the
same NFSROOT without aufs, and it even does not happen with aufs if I
perform a chroot to the directory where the original NFSROOT is still
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
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"
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
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
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,
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
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
19 matches
Mail list logo
