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 /usr/
mv: preserving permissions for ‘/usr/aaa’: Invalid argument
Our kernel is 4.9.1 with the aufs patch (commit d75e77a on 4.9 branch)
Regards,
Yair.
a.tgz
Description: proc and sys
trace
Description: strace
On Fri, Jan 20 2017, Justin Cormack <justin.corm...@docker.com> wrote:
> removexattr seems to behave differently on aufs on kernel 4.9. Guessing
> that this was missed in the xattr changes in the port.
>
> doing a cp -rp on 4.4 kernel I got:
>
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tt"..., 1024) = 462
> read(3, "", 1024) = 0
> close(3) = 0
> geteuid() = 0
> stat("/bar", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/bar/foo", 0x7ffdad662030) = -1 ENOENT (No such file or
> directory)
> mkdir("/bar/foo", 0700) = 0
> lstat("/bar/foo", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
> open("/foo", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents(3, /* 2 entries */, 32768) = 48
> getdents(3, /* 0 entries */, 32768) = 0
> close(3) = 0
> utimensat(AT_FDCWD, "/bar/foo", [{1484927717, 203576439}, {1484927716, 0}],
> 0) = 0
> lchown("/bar/foo", 0, 0) = 0
> getxattr("/foo", "system.posix_acl_access", 0x7ffdad661c30, 132) = -1
> ENODATA (No data available)
> stat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getxattr("/foo", "system.posix_acl_default", 0x7ffdad661c30, 132) = -1
> ENODATA (No data available)
> stat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> setxattr("/bar/foo", "system.posix_acl_access",
> "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\5\0\377\377\377\377
> \0\5\0\377\377\377\377", 28, 0) = 0
> removexattr("/bar/foo", "system.posix_acl_default") = 0
>
> but on 4.9 I get:
>
>
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tt"..., 1024) = 476
> read(3, "", 1024) = 0
> close(3) = 0
> geteuid() = 0
> stat("/bar", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/bar/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> open("/foo", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents(3, /* 2 entries */, 32768) = 48
> getdents(3, /* 0 entries */, 32768) = 0
> close(3) = 0
> utimensat(AT_FDCWD, "/bar/foo", [{1484927717, 203576439}, {1484927716, 0}],
> 0) = 0
> getxattr("/foo", "system.posix_acl_access", 0x7fff6a3446e0, 132) = -1
> ENODATA (No data available)
> stat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getxattr("/foo", "system.posix_acl_default", 0x7fff6a3446e0, 132) = -1
> ENODATA (No data available)
> stat("/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> setxattr("/bar/foo", "system.posix_acl_access",
> "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\5\0\377\377\377\377
> \0\5\0\377\377\377\377", 28, 0) = 0
> removexattr("/bar/foo", "system.posix_acl_default") = -1 EINVAL (Invalid
> argument)
> open("/usr/lib/x86_64-linux-gnu/charset.alias", O_RDONLY|O_NOFOLLOW) = -1
> ENOENT (No such file or directory)
> write(2, "cp: ", 4cp: ) = 4
> write(2, "preserving permissions for '/bar"..., 37preserving permissions
> for '/bar/foo') = 37
> write(2, ": Invalid argument", 18: Invalid argument) = 18
> write(2, "\n", 1
>
> This makes the call fail, as removexattr is now returning EINVAL in 4.9
>
> Both systems are running 20161219 aufs standalone
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
