samba - Jan 2023 - Is "vfs objects = acl_tdb" allowed?

Hi,

I had issues using"vfs objects = acl_xattr" (possibly too old version
[Version 4.13.13-Debian] for the needed "acl_xattr:security_acl_name
user.samba" option needed if running in a non-priv container). So I
tried "vfs objects = acl_tdb" and found it working.

In https://wiki.samba.org/index.php/File_System_Support I found:

  File systems without xattr support
  Note: This is not recommended!!!

  If you don't have a filesystem with xattr support, you can simulate it
  by adding the following line to your smb.conf:
    posix:eadb = /usr/local/samba/private/eadb.tdb
  This will place all extra file attributes (NT ACLs, DOS EAs,
streams, etc), in that tdb.
  Note: This way it is not efficient and doesn't scale well.
  That's why it shouldn't be used in production!

This seems to be very similar to "vfs objects = acl_xattr" (which uses
/var/lib/samba/file_ntacls.tdb, so probably the same technology).

Is it a problem to use "vfs objects = acl_tdb" in production? Or would
it just cost a few percent performance? I have 4TB (8,168,443 files,
took ~2hr to count) spinning storage, dimensioned for 20TB. I could
assing a few more cores or a bit more RAM if it helps.

Steffen

Hi,

I now see panic mails, is this what happens or is it unrelated?
The backtrace includes "acl_tdb." so I'm afraid I cannot use vfs
objects = acl_tdb?

-----

The Samba 'panic action' script, /usr/share/samba/panic-action,
was called for PID 9910 (/usr/sbin/smbd).

This means there was a problem with the program, such as a segfault.
Below is a backtrace for this process generated with gdb, which shows
the state of the program at the time the error occurred.  The Samba log
files may contain additional information about the problem.

If the problem persists, you are encouraged to first install the
samba-dbgsym package, which contains the debugging symbols for the Samba
binaries.  Then submit the provided information as a bug report to
Debian.  For information about the procedure for submitting bug reports,
please see http://www.debian.org/Bugs/Reporting or the reportbug(1)
manual page.

[New LWP 10213]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f7714ac4b07 in __GI___wait4 (pid=10222,
stat_loc=stat_loc at entry=0x7fffb4afd2b8, options=options at entry=0,
usage=usage at entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
#0  0x00007f7714ac4b07 in __GI___wait4 (pid=10222,
stat_loc=stat_loc at entry=0x7fffb4afd2b8, options=options at entry=0,
usage=usage at entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
#1  0x00007f7714ac4a87 in __GI___waitpid (pid=<optimized out>,
stat_loc=stat_loc at entry=0x7fffb4afd2b8, options=options at entry=0) at
waitpid.c:38
#2  0x00007f7714a41aa7 in do_system (line=<optimized out>) at
../sysdeps/posix/system.c:172
#3  0x00007f7714f3257f in smb_panic_s3 () from
/lib/x86_64-linux-gnu/libsmbconf.so.0
#4  0x00007f77152f9497 in smb_panic () from
/lib/x86_64-linux-gnu/libsamba-util.so.0
#5  0x00007f7714395b50 in dbwrap_lock_order_lock () from
/usr/lib/x86_64-linux-gnu/samba/libdbwrap.so.0
#6  0x00007f77143963b4 in dbwrap_do_locked () from
/usr/lib/x86_64-linux-gnu/samba/libdbwrap.so.0
#7  0x00007f771439649d in dbwrap_delete () from
/usr/lib/x86_64-linux-gnu/samba/libdbwrap.so.0
#8  0x00007f7710152e52 in ?? () from
/usr/lib/x86_64-linux-gnu/samba/vfs/acl_tdb.so
#9  0x00007f7710152f13 in ?? () from
/usr/lib/x86_64-linux-gnu/samba/vfs/acl_tdb.so
#10 0x00007f7715158418 in close_file () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#11 0x00007f771518f69b in ?? () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#12 0x00007f771518fe6a in smbd_smb2_request_process_close () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#13 0x00007f7715184cbc in smbd_smb2_request_dispatch () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#14 0x00007f7715185847 in ?? () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#15 0x00007f7714bfc70d in tevent_common_invoke_fd_handler () from
/lib/x86_64-linux-gnu/libtevent.so.0
#16 0x00007f7714c02a77 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#17 0x00007f7714c00c07 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#18 0x00007f7714bfbdf4 in _tevent_loop_once () from
/lib/x86_64-linux-gnu/libtevent.so.0
#19 0x00007f7714bfc09b in tevent_common_loop_wait () from
/lib/x86_64-linux-gnu/libtevent.so.0
#20 0x00007f7714c00ba7 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#21 0x00007f77151738f8 in smbd_process () from
/usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0
#22 0x000056381f0ca715 in ?? ()
#23 0x00007f7714bfc70d in tevent_common_invoke_fd_handler () from
/lib/x86_64-linux-gnu/libtevent.so.0
#24 0x00007f7714c02a77 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#25 0x00007f7714c00c07 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#26 0x00007f7714bfbdf4 in _tevent_loop_once () from
/lib/x86_64-linux-gnu/libtevent.so.0
#27 0x00007f7714bfc09b in tevent_common_loop_wait () from
/lib/x86_64-linux-gnu/libtevent.so.0
#28 0x00007f7714c00ba7 in ?? () from /lib/x86_64-linux-gnu/libtevent.so.0
#29 0x000056381f0c4d1f in main ()
A debugging session is active.

Inferior 1 [process 9910] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 9910) detached]

On Sat, Jan 14, 2023 at 11:31 PM Steffen Dettmer
<steffen.dettmer+samba at gmail.com> wrote:
>
> Hi,
>
> I had issues using"vfs objects = acl_xattr" (possibly too old
version
> [Version 4.13.13-Debian] for the needed "acl_xattr:security_acl_name
> user.samba" option needed if running in a non-priv container). So I
> tried "vfs objects = acl_tdb" and found it working.
>
> In https://wiki.samba.org/index.php/File_System_Support I found:
>
>   File systems without xattr support
>   Note: This is not recommended!!!
>
>   If you don't have a filesystem with xattr support, you can simulate
it
>   by adding the following line to your smb.conf:
>     posix:eadb = /usr/local/samba/private/eadb.tdb
>   This will place all extra file attributes (NT ACLs, DOS EAs,
> streams, etc), in that tdb.
>   Note: This way it is not efficient and doesn't scale well.
>   That's why it shouldn't be used in production!
>
> This seems to be very similar to "vfs objects = acl_xattr" (which
uses
> /var/lib/samba/file_ntacls.tdb, so probably the same technology).
>
> Is it a problem to use "vfs objects = acl_tdb" in production? Or
would
> it just cost a few percent performance? I have 4TB (8,168,443 files,
> took ~2hr to count) spinning storage, dimensioned for 20TB. I could
> assing a few more cores or a bit more RAM if it helps.
>
> Steffen

15.01.2023 01:31, Steffen Dettmer via samba wrote:
> Hi,
> 
> I had issues using"vfs objects = acl_xattr" (possibly too old
version
> [Version 4.13.13-Debian] for the needed "acl_xattr:security_acl_name
> user.samba" option needed if running in a non-priv container). So I
> tried "vfs objects = acl_tdb" and found it working.
Samba in debian bullseye is quite old indeed, and have numerous other
issues.
> In https://wiki.samba.org/index.php/File_System_Support I found:
> 
>    File systems without xattr support
>    Note: This is not recommended!!!
> 
>    If you don't have a filesystem with xattr support, you can simulate
it
>    by adding the following line to your smb.conf:
>      posix:eadb = /usr/local/samba/private/eadb.tdb
>    This will place all extra file attributes (NT ACLs, DOS EAs,
> streams, etc), in that tdb.
>    Note: This way it is not efficient and doesn't scale well.
>    That's why it shouldn't be used in production!
> 
> This seems to be very similar to "vfs objects = acl_xattr" (which
uses
> /var/lib/samba/file_ntacls.tdb, so probably the same technology).
acl_xattr does not use a tdb file (read the manpage for it, vfs_acl_xattr).
This wiki page talks about posix_eadb vfs module (there seems to be no
manual page for it though).
> Is it a problem to use "vfs objects = acl_tdb" in production? Or
would
vfs_acl_tdb is used in samba testsuite quite heavily and "should"
work.

Given the results in your other email, it does not work for you with
the debian bullseye build of samba 4.13. It might be due to your
attempt to stack posix_eadb with it, or something else entirely.

Please try with current samba version (bullseye-backports has 4.17.4).

For the backtrace in gdb to be useful, you need to have the dbgsym
packages for samba. gdb should be able to download the debug symbols
automatically from the debian archive, but it is not doing this in
your case (maybe due to local firewall maybe due to something else).
Please enable dbgsym packages and install samba-libs-dbgsym,
samba-dbgsym and samba-vfs-modules-dbgsym packages at least, - this
will help gdb to get useful backtrace (see, for example,
  https://wiki.debian.org/HowToGetABacktrace for detail)

/mjt