Re: Permissions for root user
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 --
Re: Permissions for root user
"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 --
Re: Permissions for root user
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 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 --
Re: Permissions for root user
"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 --
Re: Permissions for root user
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 after testing more and more. It may take some time. J. R. Okajima -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
Re: Permissions for root user
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 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 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
Re: Permissions for root user
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 '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. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
Re: Permissions for root user
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, 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 a.patch.bz2 Description: BZip2 compressed data -- 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/
Re: Permissions for root user
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.
# 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?
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.
aufs.data.tgz
Description: application/gtar-compressed
--
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/
Re: Permissions for root user
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 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 -- 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/
Re: Permissions for root user
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 `/tmp/irush/nfs/a/b' to `/tmp/irush/nfs/a/c': Permission denied ::: This is weird, assuming no_root_squash - it should work.. 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. -- 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/
Re: Permissions for root user
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 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
a.patch.bz2
Description: BZip2 compressed data
--
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/
Re: Permissions for root user
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 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. c.sh.bz2 Description: BZip2 compressed data -- 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/
Re: Permissions for root user
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 -- 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/
Re: Permissions for root user
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 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 -- 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/
Re: Permissions for root user
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 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. -- 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/
Re: Permissions for root user
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 -- 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/
Re: Permissions for root user
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. 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. -- 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/
Re: Permissions for root user
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 -- 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/
Re: Permissions for root user
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 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 -- 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/
Re: Permissions for root user
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 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: root@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 rootroot 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 rootroot 5 Mar 26 09:36 state root@nfs_client:/var/lib/nfs# touch file touch: cannot touch 'file': Operation not supported root@nfs_client:/var/lib/nfs# echo state root@nfs_client:/var/lib/nfs# touch file root@nfs_client:/var/lib/nfs# ls -al root@tombom:/var/lib/nfs# ls -al total 12 drwxr-xr-x 4 systemd-network nogroup 80 Mar 26 09:47 . drwxr-xr-x 32 rootroot 120 Mar 26 09:36 .. -rw-r--r-- 1 rootroot 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 rootroot 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 -- 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/
Re: Permissions for root user
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 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
execve(/usr/bin/touch, [touch, file], [/* 23 vars */]) = 0
brk(0) = 0x1729000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb3f7f85000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=17856, ...}) = 0
mmap(NULL, 17856, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb3f7f8
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\34\2\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1729984, ...}) = 0
mmap(NULL, 3836448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb3f79be000
mprotect(0x7fb3f7b5d000, 2097152, PROT_NONE) = 0
mmap(0x7fb3f7d5d000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f000) = 0x7fb3f7d5d000
mmap(0x7fb3f7d63000, 14880, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb3f7d63000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb3f7f7f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb3f7f7e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb3f7f7d000
arch_prctl(ARCH_SET_FS, 0x7fb3f7f7e700) = 0
mprotect(0x7fb3f7d5d000, 16384, PROT_READ) = 0
mprotect(0x60d000, 4096, PROT_READ) = 0
mprotect(0x7fb3f7f87000, 4096, PROT_READ) = 0
munmap(0x7fb3f7f8, 17856) = 0
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3847568, ...}) = 0
mmap(NULL, 3847568, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb3f7612000
close(3)= 0
brk(0) = 0x1729000
brk(0x174a000) = 0x174a000
open(file, O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EOPNOTSUPP
(Operation not supported)
utimensat(AT_FDCWD, file, NULL, 0)= -1 ENOENT (No such file or directory)
open(/usr/share/locale/locale.alias, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2492, ...}) = 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb3f7f75000
read(3, # Locale name alias data base.\n#..., 32768) = 2492
read(3, , 32768) = 0
close(3)= 0
munmap(0x7fb3f7f75000, 32768) = 0
open(/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/share/locale/en/LC_MESSAGES/coreutils.mo, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/lib/charset.alias, O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file
or directory)
write(2, touch: , 7touch: ) = 7
write(2, cannot touch 'file', 19cannot touch 'file') = 19
open(/usr/share/locale/en_US/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such
file or directory)
write(2, : Operation not supported, 25: Operation not supported) = 25
write(2, \n, 1
) = 1
close(1)= 0
close(2)= 0
exit_group(1) = ?
+++ exited with 1 +++--
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/
Permissions for root user
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: root@name:/var/lib/nfs# ls -al total 4 drwxr-xr-x 2 systemd-network nogroup . drwxr-xr-x 31 root 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 -- 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/
Re: Permissions for root user
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 file in a directory which is not officially writable by root, for example in my /var/lib/nfs: 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 -- 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/
Re: Permissions for root user
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. On Wed, Mar 25 2015, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, 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 - /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. - 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/ - aufs version which was printed at loading the module or booting the system, instead of the date you downloaded. aufs 3.16-20140908 - 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/ -- 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/
Re: Permissions for root user
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 -- 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/
Re: Permissions for root user
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 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 mounts Description: Binary data -- 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/
Re: Permissions for root user
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 -- 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/
