You are not logged in.
I just upgraded my system, now all ACLs on ZFS are broken. I have a ZFS root install.
Relevant packages:
linux 4.5-1
spl-git 0.6.5.6_r0_g5079f5b_4.5.0_1-1 (archzfs-git)
spl-utils-git 0.6.5.6_r0_g5079f5b_4.5.0_1-1 (archzfs-git)
zfs-git 0.6.5.6_r0_g21f21fe_4.5.0_1-1 (archzfs-git)
zfs-utils-git 0.6.5.6_r0_g21f21fe_4.5.0_1-1 (archzfs-git)
Previously, I was running these versions:
core/linux 4.4.5-1
demz-repo-core/spl-git 0.6.5.5_r0_gbb0eec6_4.4.5_1-1
demz-repo-core/spl-utils-git 0.6.5.5_r0_gbb0eec6_4.4.5_1-1
demz-repo-core/zfs-git 0.6.5.5_r0_g504ff59_4.4.5_1-1
demz-repo-core/zfs-utils-git 0.6.5.5_r0_g504ff59_4.4.5_1-1
I have acl set to posixacl and xattr set to on.
I first noticed that sytemd-tmpfiles was acting up again. Then I found none of my ACLs were still active. Indeed, any call to getfacl or setfacl results in “Invalid argument”. Even on files/directories that don’t have any ACLs at all. ls doesn’t show a + either.
strace:
[root@server ~]# strace getfacl /
execve("/usr/bin/getfacl", ["getfacl", "/"], [/* 20 vars */]) = 0
brk(NULL) = 0x1021000
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=93119, ...}) = 0
mmap(NULL, 93119, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f97e8a21000
close(3) = 0
open("/usr/lib/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300 \0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=35384, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97e8a20000
mmap(NULL, 2130592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97e860c000
mprotect(0x7f97e8614000, 2093056, PROT_NONE) = 0
mmap(0x7f97e8813000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f97e8813000
close(3) = 0
open("/usr/lib/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\0000\10\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1960896, ...}) = 0
mmap(NULL, 3803536, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97e826b000
mprotect(0x7f97e8403000, 2093056, PROT_NONE) = 0
mmap(0x7f97e8602000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f97e8602000
mmap(0x7f97e8608000, 14736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f97e8608000
close(3) = 0
open("/usr/lib/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\24\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18736, ...}) = 0
mmap(NULL, 2113912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97e8066000
mprotect(0x7f97e806a000, 2093056, PROT_NONE) = 0
mmap(0x7f97e8269000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f97e8269000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97e8a1f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97e8a1e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97e8a1d000
arch_prctl(ARCH_SET_FS, 0x7f97e8a1e700) = 0
mprotect(0x7f97e8602000, 16384, PROT_READ) = 0
mprotect(0x7f97e8269000, 4096, PROT_READ) = 0
mprotect(0x7f97e8813000, 4096, PROT_READ) = 0
mprotect(0x604000, 4096, PROT_READ) = 0
mprotect(0x7f97e8a38000, 4096, PROT_READ) = 0
munmap(0x7f97e8a21000, 93119) = 0
brk(NULL) = 0x1021000
brk(0x1042000) = 0x1042000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3531264, ...}) = 0
mmap(NULL, 3531264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f97e7d07000
close(3) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=24, ...}) = 0
getxattr("/", "system.posix_acl_access", 0x7ffc8734ade0, 132) = -1 EINVAL (Invalid argument)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2997, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 3072) = 2997
read(3, "", 3072) = 0
close(3) = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/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, "getfacl: /: Invalid argument\n", 29getfacl: /: Invalid argument
) = 29
exit_group(1) = ?
+++ exited with 1 +++
Regular extended attributes (ie the user namespace) are still working fine!
It was working previously and it still works when I create an ext4 filesystem image and loop mount it.
I’m mainly looking for others that can reproduce this behavior on their systems to tell if this really is a ZFS bug or my machine is just messed up. It puzzles me that I find absolutely nothing on Google or the ZFS on Linux bug tracker, even when version 0.6.5.6 has been available since March 23.
Last edited by fuzzy2 (2016-05-04 17:30:07)
Offline
I have the same issue on my system. I also posed this question on the zfs-git AUR page.
I don't know whether the problem is with this ZFS version, kernel 4.5.0-1 or the combo of both.
Edit: see https://bbs.archlinux.org/viewtopic.php … 2#p1601272 for a temporary fix for /var/log/journal...
Last edited by ukhippo (2016-04-16 22:32:48)
Offline
Thank you for your answer. I’m not really interested in workarounds though.
In the meantime, I built the ZFS 0.6.5.5 packages from AUR for kernel 4.5 and encountered the same error. So I guess there was some API change in 4.5 that results in this message.
But even more interesting is that the ACLs are still in effect! I have default ACLs set on a directory to allow read access from all users. If I create a new file in this directory, it is world-readable even though umask is 0027! Elsewhere, the mask is applied as expected.
[fuzzy@server Public]$ getfacl .
getfacl: .: Invalid argument
[fuzzy@server Public]$ umask
0027
[fuzzy@server Public]$ touch my-test-file
[fuzzy@server Public]$ ls -l my-test-file
-rw-r--r-- 1 fuzzy fuzzy 0 Apr 18 20:46 my-test-file
[fuzzy@server Public]$ cd
[fuzzy@server ~]$ touch my-test-file
[fuzzy@server ~]$ ls -l my-test-file
-rw-r----- 1 fuzzy fuzzy 0 Apr 18 20:48 my-test-file
This is some seriously strange stuff.
Offline
I believe the problem is caused by this (admittedly serious) regression in ZoL...
https://github.com/zfsonlinux/zfs/commi … 3f8e6b24be
Edit: Ah, I see you've already been replied there too...
https://github.com/zfsonlinux/zfs/issues/4537
Edit2: However, even with that commit applied, I still get the "Invalid argument" error. Hmmm...
Last edited by kerberizer (2016-04-18 19:53:30)
“Don't climb the mountain to conquer it. Climb it to conquer yourself.”
Offline
To wrap things up: It was indeed a bug in ZFS resulting from ACL API changes in Linux 4.5. It is fixed now, the fix should ship in the next release of ZFS on Linux.
Offline