Is it safe to disable extended attributes/ACL lists, and would this enhance performance?

Doogie

Dabbler
Joined
Mar 9, 2014
Messages
24
I have a FreeNAS 11.2 whose sole purpose is to serve media and store archival data for home use by one person. No jails are running. All file and directory permissions are and should be set for a single user. It shares with Linux, Kodi/Android, and occasionally Windows systems using SMB shares. File sizes are frequently large, >10GB. I run a 10GoE system with Intel X540-T2s. Performance is important.

I've run into permissions issues with files/directories being created with non-default ownership that then cause rsync to fail to backup servers. I have been able to fix permissions using chgrp/chown -R [user] /mnt/volume, as well as removing extended attributes with find /mnt/volume/ | setfacl -b .

Questions: IS IT SAFE in my usage scenario to avoid extended attributes and ACL lists by deleting VFS objects in smb4.conf (removing zfsacl and streams_xattr from vfs objects, as well as setting ea support = no)? Would there be performance improvements in doing so? I *don't* want to break anything, but am very curious as to what others would do in my usage scenario to keep things FAST and SIMPLE for home file sharing for single users with basic needs.

Appreciations.

Code:
[global]
    server min protocol = SMB2_02
    server max protocol = SMB3
    interfaces = 127.0.0.1 192.168.1.100
    bind interfaces only = yes
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 1409267
    logging = file
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = yes
    ntlm auth = no
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    server string = FreeNAS Server
    ea support = yes
    store dos attributes = yes
    lm announce = yes
    hostname lookups = yes
    time server = yes
    acl allow execute always = true
    dos filemode = yes
    multicast dns register = yes
    domain logons = no
    local master = yes
    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    server role = standalone
    netbios name = FREENAS
    workgroup = WORKGROUP
    security = user
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1
    

[Server]
    path = "/mnt/volume"
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    access based share enum = no
    vfs objects = zfs_space zfsacl streams_xattr
    hide dot files = no
    guest ok = yes
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
I have a FreeNAS 11.2 whose sole purpose is to serve media and store archival data for home use by one person. No jails are running. All file and directory permissions are and should be set for a single user. It shares with Linux, Kodi/Android, and occasionally Windows systems using SMB shares. File sizes are frequently large, >10GB. I run a 10GoE system with Intel X540-T2s. Performance is important.

I've run into permissions issues with files/directories being created with non-default ownership that then cause rsync to fail to backup servers. I have been able to fix permissions using chgrp/chown -R [user] /mnt/volume, as well as removing extended attributes with find /mnt/volume/ | setfacl -b .

Questions: IS IT SAFE in my usage scenario to avoid extended attributes and ACL lists by deleting VFS objects in smb4.conf (removing zfsacl and streams_xattr from vfs objects, as well as setting ea support = no)? Would there be performance improvements in doing so? I *don't* want to break anything, but am very curious as to what others would do in my usage scenario to keep things FAST and SIMPLE for home file sharing for single users with basic needs.

Appreciations.

Code:
[global]
    server min protocol = SMB2_02
    server max protocol = SMB3
    interfaces = 127.0.0.1 192.168.1.100
    bind interfaces only = yes
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 1409267
    logging = file
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = yes
    ntlm auth = no
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    server string = FreeNAS Server
    ea support = yes
    store dos attributes = yes
    lm announce = yes
    hostname lookups = yes
    time server = yes
    acl allow execute always = true
    dos filemode = yes
    multicast dns register = yes
    domain logons = no
    local master = yes
    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    server role = standalone
    netbios name = FREENAS
    workgroup = WORKGROUP
    security = user
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1
   

[Server]
    path = "/mnt/volume"
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    access based share enum = no
    vfs objects = zfs_space zfsacl streams_xattr
    hide dot files = no
    guest ok = yes
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
The VFS objects have minimal performance impact. You can configure your rsync script to not attempt to sync permissions. The problem with removing zfsacl entirely is that samba may attempt to manipulate posix1e ACLs on the filesystem which will result in "invalid parameter" errors.
 
Top