# Auf Kriegsfuß mit net-fs/samba

## schmidicom

Erst gestern hat mir net-fs/samba wieder einmal so ein richtig tolles Erlebnis beschert wo ich über 5 Stunden lang herumdoktern musste und auch entsprechend Nerven gelassen habe. Im nachhinein betrachtet ist der Fehler zwar recht simpel aber dank den eher nichts aussagenden Fehlermeldungen von smbd muss man da erst mal drauf kommen.

Zum Fehler:

Wie es aussieht hat das Samba-VFS-Modul "acl_tdb" einen richtig üblen Bug welcher bei wenigen Clients nur sporadisch zum Absturz des jeweiligen smbd Kindprozess führt, so das es meistens gar nicht auffällt. Aber in meinem Fall, wo den ganzen Tag locker um die 50 Verbindungen offen sind, spammt einem dieser Bug dann mit der folgenden Fehlermeldung nicht nur das Log zu sondern vermüllt dabei auch noch die Platte mit etlichen Coredumps.

```
Jun 20 19:58:56 LAMBDA10 smbd[406]: [2017/06/20 19:58:56.803726,  0] ../lib/dbwrap/dbwrap.c:165(dbwrap_check_lock_order)

Jun 20 19:58:56 LAMBDA10 smbd[406]:   Lock order violation: Trying /var/lib/samba/file_ntacls.tdb at 1 while /var/lock/samba/locking.tdb at 1 is locked

Jun 20 19:58:56 LAMBDA10 smbd[406]: [2017/06/20 19:58:56.805101,  0] ../lib/dbwrap/dbwrap.c:114(debug_lock_order)

Jun 20 19:58:56 LAMBDA10 smbd[406]:   lock order:  1:/var/lock/samba/locking.tdb 2:<none> 3:<none>

Jun 20 19:58:56 LAMBDA10 smbd[406]: [2017/06/20 19:58:56.805164,  0] ../source3/lib/util.c:791(smb_panic_s3)

Jun 20 19:58:56 LAMBDA10 smbd[406]:   PANIC (pid 406): invalid lock_order

Jun 20 19:58:56 LAMBDA10 smbd[406]: [2017/06/20 19:58:56.819808,  0] ../source3/lib/util.c:902(log_stack_trace)

Jun 20 19:58:56 LAMBDA10 smbd[406]:   BACKTRACE: 26 stack frames:

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1c) [0x7f4608da2f7c]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f4608da3050]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7f460aea0b5f]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #3 /usr/lib64/samba/libdbwrap-samba4.so(+0x2d16) [0x7f46047fcd16]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #4 /usr/lib64/samba/vfs/acl_tdb.so(+0x2705) [0x7f45f5ce9705]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #5 /usr/lib64/samba/vfs/acl_tdb.so(+0x2d5c) [0x7f45f5ce9d5c]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #6 /usr/lib64/samba/libsmbd-base-samba4.so(close_file+0x1ba9) [0x7f460aa9b5d9]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #7 /usr/lib64/samba/libsmbd-base-samba4.so(+0x195e53) [0x7f460aacee53]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #8 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_smb2_request_process_close+0xe5) [0x7f460aacf615]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #9 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_smb2_request_dispatch+0xbfd) [0x7f460aac505d]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #10 /usr/lib64/samba/libsmbd-base-samba4.so(+0x18ccb0) [0x7f460aac5cb0]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #11 /usr/lib64/libtevent.so.0(+0xace3) [0x7f46077c5ce3]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #12 /usr/lib64/libtevent.so.0(+0x90c7) [0x7f46077c40c7]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #13 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f46077bfead]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #14 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f46077c00cb]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #15 /usr/lib64/libtevent.so.0(+0x9067) [0x7f46077c4067]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #16 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_process+0x6d9) [0x7f460aab5089]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #17 /usr/sbin/smbd(+0xc584) [0x555e4eb62584]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #18 /usr/lib64/libtevent.so.0(+0xace3) [0x7f46077c5ce3]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #19 /usr/lib64/libtevent.so.0(+0x90c7) [0x7f46077c40c7]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #20 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f46077bfead]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #21 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f46077c00cb]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #22 /usr/lib64/libtevent.so.0(+0x9067) [0x7f46077c4067]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #23 /usr/sbin/smbd(main+0x1882) [0x555e4eb5d5b2]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #24 /lib64/libc.so.6(__libc_start_main+0xf1) [0x7f4607442681]

Jun 20 19:58:56 LAMBDA10 smbd[406]:    #25 /usr/sbin/smbd(_start+0x29) [0x555e4eb5d769]

Jun 20 19:58:56 LAMBDA10 smbd[406]: [2017/06/20 19:58:56.826833,  0] ../source3/lib/dumpcore.c:318(dump_core)

Jun 20 19:58:56 LAMBDA10 smbd[406]:   coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern
```

Die einzige Lösung die in meinem Fall Abhilfe geschaffen hat war der Wechsel von vfs_acl_tdb zu vfs_acl_xattr, denn alles herumschrauben an den zahlreichen locking-Optionen in der Samba-Konfiguration haben schlicht nichts gebracht. Und auf diese Lösung bin ich auch nur gekommen weil ich nach stundenlanger Suche im Internet über die folgenden beiden Seiten gestolpert bin.

https://lists.samba.org/archive/samba-technical/2017-March/119640.html

https://lists.samba.org/archive/samba-technical/2017-March/119648.html

https://bugzilla.samba.org/show_bug.cgi?id=11761

Der Bug ist also seit rund einem Jahr bekannt, interessiert beim Samba-Team aber wohl keine Sau...

Und das ist nicht das erste Modul welches sich quer stellt! Als ich mal den Mac-Usern zu liebe auf dem Testrechner mit vfs_fruit herumexperimentierte schmierte mir der smbd schon beim starten ab.

Bin ich (gefühlt) wirklich fast der einzige der mit net-fs/samba immer mal wieder derart auf Kriegsfuß steht? Was sind eure Erlebnisse mit dieser Software?

----------

## ChrisJumper

Hi schmidicom,

ich würde Samba am liebsten von all meinen Systemen werfen. Bin aber auch nicht drauf angewiesen da ich keine Windows Systeme nutze und alle Daten die ich benötige per SCP verschiebe, oder als Nutzer per Jabber. Wenn überhaupt sonst einfach über einen zentralen Webserver.

Von daher hab ich auch nicht so viel ärger damit. Schön wäre es aber wenn ich Samba einfach so entfernen könnte, aber die Gnome-Abhängigkeiten waren mir noch zu Suspekt, denn ein einfaches -samba als Useflag brachte nicht den gewünschten Erfolg. Letztlich war der Sicherheitspatch schneller und dann hab ich samba einfach wieder aktualisiert.

Viele Grüße

Chris

----------

## schmidicom

 *ChrisJumper wrote:*   

> ich würde Samba am liebsten von all meinen Systemen werfen. Bin aber auch nicht drauf angewiesen da ich keine Windows Systeme nutze und alle Daten die ich benötige per SCP verschiebe, oder als Nutzer per Jabber. Wenn überhaupt sonst einfach über einen zentralen Webserver.

 

Tja, einen solchen Luxus kann ich mir nicht leisten...

Ich bin für mehrere Samba-Fileserver verantwortlich welche die zusammenarbeit von den unterschiedlichsten Clients (Windows 7 - 10, MacOS 10.x, Linux, Drucker, und anderes) ermöglichen müssen, etwas das trauriger weise nicht einmal ein Windows Server wirklich zuverlässig auf die Reihe bekommt. Und mindestens einer davon muss mit 50 - 100 Clients gleichzeitig klar kommen was bei einem normalen Windows Server ebenfalls schnell mal "interessant" werden kann.

Einerseits bin ich froh das Linux gerade an solchen Stellen so richtig punkten kann aber wenn man sich dann mit sowas wie weiter oben beschrieben herumschlagen muss bleibt von der Freude nicht mehr viel übrig. Und bei diesem Beispiel ging es nur um einen Samba-Fileserver, eine Samba-Workstation ist im Bezug auf die Konfiguration dann gleich noch ein ganz anderes Kaliber.

----------

