Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Does anyone know how many user ACL's ZFS can handle?

With other words: for how many users can I set ACL's like this one for the same directory?

setfacl -m user:test1:rwxpDdaARWcCos:fd----:allow /mnt/project1

Or an estimate would also be good. E.g. are we talking 100, 500, 1000, or more?

Update

121 is not a bug on FreeBSD 9.

  • ZFS ACL limit is 1024.
  • FreeBSD ACL limit is 254.
  • FreeBSD NFSv4 ACL limit is about half of 254.

See /sys/sys/acl.h

share|improve this question
2  
Dunno about ZFS, but in ext and xfs, ACLs are kept in extended attributes. That translates to 4KiB limit for ext2/3/4 and no limit for xfs. But then you have to search them linearly to find out if a user can access a file so the practical limit may be around a thousand or so even if the file system doesn't have a limit. –  Hubert Kario Dec 5 '12 at 23:06
add comment

3 Answers

up vote 5 down vote accepted

According to ZFS source code, the maximum number is set to 1024. I can confirm 1024 ACLs can be set on a file on ZFS under Solaris. There might be a lower limit either in ZFS or setfacl implementation on FreeBSD

# cat maxacl
#!/bin/ksh

touch file
i=1
while true; do
  for u in $(getent passwd | nawk -F: '{print $1}'); do
    chmod A+user:$u:read_data:allow file || break 2
    printf "%d %s\n" $i $u
    i=$((i+1))
  done
  ls -v file | head
  ls -v file | wc -l
done

# ls -v file | head
-rw-r--r--+  1 root     root           0 déc   6 13:05 file
     0:user:utku3:read_data:allow
     1:user:utku2:read_data:allow
     2:user:utku1:read_data:allow
     3:user:utku0:read_data:allow
     4:user:utwww:read_data:allow
     5:user:jlliagre:read_data:allow
     6:user:nobody4:read_data:allow
     7:user:noaccess:read_data:allow
     8:user:nobody:read_data:allow
# ls -v file | tail
     1017:user:root:read_data:allow
     1018:owner@:execute:deny
     1019:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     1020:group@:write_data/append_data/execute:deny
     1021:group@:read_data:allow
     1022:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     1023:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow
share|improve this answer
    
That is very interesting! FreeBSD's ZFS have the same limit in the source code. What would the equivalent of chmod A+user:$u:read_data:allow file be on FreeBSD? svn.freebsd.org/base/user/eri/pf45/head/sys/cddl/contrib/… –  Sandra Dec 6 '12 at 19:24
1  
I have no FreeBSD system to investigate. I guess the right tools would be truss and dtrace to find out why setfacl stops earlier. Another thing that would be interesting would be to send/receive a pool containing a file with 1024 acls from Solaris to FreeBSD. –  jlliagre Dec 6 '12 at 20:55
add comment

I'm guessing you're the same person that asked on the FreeBSD forum and it was tested as being 127, at which point the file system gave 'no space left' errors.

share|improve this answer
add comment

After writing a script myself, I got the limit at 121 on FreeBSD 9 64bit.

setfacl -b /tank/project1

i=0
for u in $(ypcat passwd|awk -F':' '{print $1}'); do
    setfacl -m user:$u:rwxpDdaARWcCos:fd----:allow /tank/project1
    let i=i+1
    echo $i $u
done
share|improve this answer
    
@notpeter Updated post with FreeBSD 9 64bit. –  Sandra Dec 6 '12 at 18:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.