Gluster devs,
I'm running gluster v3.6.3 (both
server and client side). Since my application requires more than 32
groups, I don't mount with ACLs on the client. If I mount with ACLs
between the bricks and set a default ACL on the server, I think I'm
right in stating that the server should respect that ACL whenever a new
file or folder is made. Maybe an example is in order:We first set up a test directory with setgid bit so that our new subdirectories inherit the group.
[root@gfs01a hpc_shared]# mkdir test; cd test; chown pglomski.users .; chmod 2770 .; getfacl .
# file: .
# owner: pglomski
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
New subdirectories share the group, but the umask leads to them being group read-only.
[root@gfs01a test]# mkdir a; getfacl a
# file: a
# owner: root
# group: users
# flags: -s-
user::rwx
group::r-x
other::r-x
Setting default ACLs on the server allows group write to new directories made on the server.
[root@gfs01a test]# setfacl -m d:g::rwX ./; mkdir b; getfacl b
# file: b
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
[root@gfs01a test]# setfacl -m d:g::rwX ./; mkdir b; getfacl b
# file: b
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
The respect for ACLs is (correctly) shared across bricks.
[root@gfs02a test]# getfacl b
# file: b
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
[root@gfs02a test]# mkdir c; getfacl c
# file: c
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
[root@gfs02a test]# getfacl b
# file: b
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
[root@gfs02a test]# mkdir c; getfacl c
# file: c
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
However, when folders are created client-side, the default ACLs appear on the server, but don't seem to be correctly applied.
[root@client test]# mkdir d; getfacl d
# file: d
# owner: root
# group: users
# flags: -s-
user::rwx
group::r-x
other::---
[root@gfs01a test]# getfacl d
# file: d
# owner: root
# group: users
# flags: -s-
user::rwx
group::r-x
other::---
default:user::rwx
default:group::rwx
default:other::---
[root@client test]# mkdir d; getfacl d
# file: d
# owner: root
# group: users
# flags: -s-
user::rwx
group::r-x
other::---
[root@gfs01a test]# getfacl d
# file: d
# owner: root
# group: users
# flags: -s-
user::rwx
group::r-x
other::---
default:user::rwx
default:group::rwx
default:other::---
As
no groups or users were specified, I shouldn't need to specify a mask
for the ACL and, indeed, specifying a mask doesn't help.
If it helps diagnose the problem, the volume options are as follows:
Options Reconfigured:
performance.io-thread-count: 32
performance.cache-size: 128MB
performance.write-behind-window-size: 128MB
server.allow-insecure: on
network.ping-timeout: 10
storage.owner-gid: 100
geo-replication.indexing: off
geo-replication.ignore-pid-check: on
changelog.changelog: on
changelog.fsync-interval: 3
changelog.rollover-time: 15
server.manage-gids: on
This approach to server-side ACLs
worked properly with previous versions of gluster. Can anyone assess the
situation for me, confirm/deny that something changed, and possibly suggest how I
can achieve inherited groups with write permission for new
subdirectories in a >32-group environment?
Options Reconfigured:
performance.io-thread-count: 32
performance.cache-size: 128MB
performance.write-behind-window-size: 128MB
server.allow-insecure: on
network.ping-timeout: 10
storage.owner-gid: 100
geo-replication.indexing: off
geo-replication.ignore-pid-check: on
changelog.changelog: on
changelog.fsync-interval: 3
changelog.rollover-time: 15
server.manage-gids: on
Thanks for your time,
Patrick_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
