Always experiencing server-side crashes (client-side hangs) with kernel-cifs mounted /home on the client (for example when running firefox) with the latest samba versions (server). # Client: # uname -a Linux diskless 4.15.0-30-generic #32~16.04.1-Ubuntu SMP Thu Jul 26 20:25:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # grep /home /proc/mounts //srv/home/test /home/test cifs rw,relatime,vers=1.0,sec=krb5,cache=strict,username=test,uid=11047,forceuid,gid=1513,forcegid,addr=172.16.0.1,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1 0 0 # Server: # uname -a Linux fsrv 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux smbd versions affected: 4.5.16 4.6.16 4.7.10 4.8.5 4.9.2 latest working version: 4.4.16 # Here is the log of smbd crash. I can't tell what version it belongs (since I tried many in short time), but I could replay this with 4.9.2 or master and provide dump privately if you need. [2018/10/03 09:57:23.101841, 1] ../source3/smbd/process.c:554(receive_smb_talloc) receive_smb_raw_talloc failed for client ipv4:172.23.0.221:35702 read error = NT_STATUS_CONNECTION_RESET. [2018/10/03 09:57:43.237459, 0] ../source3/locking/posix.c:455(decrement_lock_ref_count) PANIC: assert failed at ../source3/locking/posix.c(455): lock_ref_count >= 0 [2018/10/03 09:57:43.237532, 0] ../source3/lib/util.c:791(smb_panic_s3) PANIC (pid 27984): assert failed: lock_ref_count >= 0 [2018/10/03 09:57:43.238055, 0] ../source3/lib/util.c:902(log_stack_trace) BACKTRACE: 39 stack frames: #0 /usr/local/samba/lib/libsmbconf.so.0(log_stack_trace+0x1f) [0x7f8cd43f5769] #1 /usr/local/samba/lib/libsmbconf.so.0(smb_panic_s3+0x6d) [0x7f8cd43f55c6] #2 /usr/local/samba/lib/libsamba-util.so.0(smb_panic+0x28) [0x7f8cd6ea71dc] #3 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x209300) [0x7f8cd6ab2300] #4 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x20b204) [0x7f8cd6ab4204] #5 /usr/local/samba/lib/private/libsmbd-base-samba4.so(release_posix_lock_posix_flavour+0x3af) [0x7f8cd6ab48a1] #6 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x205984) [0x7f8cd6aae984] #7 /usr/local/samba/lib/private/libsmbd-base-samba4.so(brl_unlock+0xbf) [0x7f8cd6aaed26] #8 /usr/local/samba/lib/private/libsmbd-base-samba4.so(do_unlock+0x18b) [0x7f8cd6aa95c6] #9 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x12643a) [0x7f8cd69cf43a] #10 /usr/local/samba/lib/private/libsmbd-base-samba4.so(smbd_do_setfilepathinfo+0x56e) [0x7f8cd69d2500] #11 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x129ecd) [0x7f8cd69d2ecd] #12 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x12b5c4) [0x7f8cd69d45c4] #13 /usr/local/samba/lib/private/libsmbd-base-samba4.so(reply_trans2+0xce0) [0x7f8cd69d54d8] #14 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x163c8d) [0x7f8cd6a0cc8d] #15 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x163e51) [0x7f8cd6a0ce51] #16 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x164f0d) [0x7f8cd6a0df0d] #17 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x166261) [0x7f8cd6a0f261] #18 /usr/local/samba/lib/private/libsmbd-base-samba4.so(+0x166349) [0x7f8cd6a0f349] #19 /usr/local/samba/lib/private/libtevent.so.0(+0xdb95) [0x7f8cd5e8fb95] #20 /usr/local/samba/lib/private/libtevent.so.0(+0xe1b4) [0x7f8cd5e901b4] #21 /usr/local/samba/lib/private/libtevent.so.0(+0xb08e) [0x7f8cd5e8d08e] #22 /usr/local/samba/lib/private/libtevent.so.0(_tevent_loop_once+0xf4) [0x7f8cd5e867e1] #23 /usr/local/samba/lib/private/libtevent.so.0(tevent_common_loop_wait+0x25) [0x7f8cd5e86a36] #24 /usr/local/samba/lib/private/libtevent.so.0(+0xb130) [0x7f8cd5e8d130] #25 /usr/local/samba/lib/private/libtevent.so.0(_tevent_loop_wait+0x2b) [0x7f8cd5e86b01] #26 /usr/local/samba/lib/private/libsmbd-base-samba4.so(smbd_process+0xbe2) [0x7f8cd6a13a8e] #27 /usr/local/samba/sbin/smbd(+0xce20) [0x56301f62de20] #28 /usr/local/samba/lib/private/libtevent.so.0(+0xdb95) [0x7f8cd5e8fb95] #29 /usr/local/samba/lib/private/libtevent.so.0(+0xe1b4) [0x7f8cd5e901b4] #30 /usr/local/samba/lib/private/libtevent.so.0(+0xb08e) [0x7f8cd5e8d08e] #31 /usr/local/samba/lib/private/libtevent.so.0(_tevent_loop_once+0xf4) [0x7f8cd5e867e1] #32 /usr/local/samba/lib/private/libtevent.so.0(tevent_common_loop_wait+0x25) [0x7f8cd5e86a36] #33 /usr/local/samba/lib/private/libtevent.so.0(+0xb130) [0x7f8cd5e8d130] #34 /usr/local/samba/lib/private/libtevent.so.0(_tevent_loop_wait+0x2b) [0x7f8cd5e86b01] #35 /usr/local/samba/sbin/smbd(+0xdb9a) [0x56301f62eb9a] #36 /usr/local/samba/sbin/smbd(main+0x17ed) [0x56301f63053c] #37 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f8cd2c96b97] #38 /usr/local/samba/sbin/smbd(_start+0x2a) [0x56301f62751a] [2018/10/03 09:57:43.238224, 0] ../source3/lib/util.c:803(smb_panic_s3) smb_panic(): calling panic action [/usr/share/samba/panic-action 27984] [2018/10/03 09:57:43.240513, 0] ../source3/lib/util.c:811(smb_panic_s3) smb_panic(): action returned status 0 [2018/10/03 09:57:43.240578, 0] ../source3/lib/dumpcore.c:303(dump_core) dumping core in /usr/local/samba/var/cores/smbd
Can you upload a network trace of the client->smbd traffic together with a debug level 10 log of smbd? You can find information how to get those under https://wiki.samba.org/index.php/Capture_Packets and https://wiki.samba.org/index.php/Client_specific_Log Thanks
I forgot: Please also upload your smb.conf
Just FYI, this looks like it might be similar to: https://bugzilla.samba.org/show_bug.cgi?id=13633 which I just fixed. Can you also get a full gdb stack backtrace using 'panic action = /bin/sleep 999999' ?
Just sent you all requested info by mail (smbd 4.9.1) . Please, tell if you didn't receive it. Also, patch from 13633 didn't help.
I want to submit new information about this bug, as it happened to me in two instances, being the first one with a combination on mount.cifs version 6.7 as client, and samba server 4.8.3, when connecting with NT1 protocol (option vers=1.0). It was cincurvented by switching to SMB3 protocol. But older versions of mount.cifs (or older versions of samba) where working correctly with NT1, so it is the combination of newer versions of both client and samba server, and only when going with an older version of the protocol. Today happened to me again with mount.cifs 6.9, and samba 4.10.2. I hope is avoided again with the same trick (fingers crossed...). journal of the error: ic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.073552, 0] ../../source3/locking/posix.c:453(decrement_lock_ref_count) dic 14 16:55:48 servidor kernel: audit: type=1701 audit(1576338948.085:456): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25803 comm="smbd" exe="/usr/bin/smbd" sig=6 res=1 dic 14 16:55:48 servidor audit[25803]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25803 comm="smbd" exe="/usr/bin/smbd" sig=6 res=1 dic 14 16:55:48 servidor smbd[25803]: PANIC: assert failed at ../../source3/locking/posix.c(453): lock_ref_count > 0 dic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.073708, 0] ../../source3/lib/util.c:824(smb_panic_s3) dic 14 16:55:48 servidor smbd[25803]: PANIC (pid 25803): assert failed: lock_ref_count > 0 dic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.076465, 0] ../../lib/util/fault.c:261(log_stack_trace) dic 14 16:55:48 servidor smbd[25803]: BACKTRACE: 31 stack frames: dic 14 16:55:48 servidor smbd[25803]: #0 /usr/lib/libsamba-util.so.0(log_stack_trace+0x31) [0x7f7d33d8e661] dic 14 16:55:48 servidor smbd[25803]: #1 /usr/lib/libsmbconf.so.0(smb_panic_s3+0x1a) [0x7f7d33736b8a] dic 14 16:55:48 servidor smbd[25803]: #2 /usr/lib/libsamba-util.so.0(smb_panic+0x2d) [0x7f7d33d8e75d] dic 14 16:55:48 servidor smbd[25803]: #3 /usr/lib/samba/libsmbd-base-samba4.so(+0x19531e) [0x7f7d33ba231e] dic 14 16:55:48 servidor smbd[25803]: #4 /usr/lib/samba/libsmbd-base-samba4.so(+0x195520) [0x7f7d33ba2520] dic 14 16:55:48 servidor smbd[25803]: #5 /usr/lib/samba/libsmbd-base-samba4.so(release_posix_lock_posix_flavour+0x24c) [0x7f7d33ba496c] dic 14 16:55:48 servidor smbd[25803]: #6 /usr/lib/samba/libsmbd-base-samba4.so(brl_unlock+0x5ce) [0x7f7d33ba055e] dic 14 16:55:48 servidor smbd[25803]: #7 /usr/lib/samba/libsmbd-base-samba4.so(do_unlock+0x10c) [0x7f7d33b9c50c] dic 14 16:55:48 servidor smbd[25803]: #8 /usr/lib/samba/libsmbd-base-samba4.so(smbd_do_setfilepathinfo+0x1dc9) [0x7f7d33b08249] dic 14 16:55:48 servidor smbd[25803]: #9 /usr/lib/samba/libsmbd-base-samba4.so(+0xfd03f) [0x7f7d33b0a03f] dic 14 16:55:48 servidor smbd[25803]: #10 /usr/lib/samba/libsmbd-base-samba4.so(reply_trans2+0x4f8) [0x7f7d33b0c078] dic 14 16:55:48 servidor smbd[25803]: #11 /usr/lib/samba/libsmbd-base-samba4.so(+0x129323) [0x7f7d33b36323] dic 14 16:55:48 servidor smbd[25803]: #12 /usr/lib/samba/libsmbd-base-samba4.so(+0x12b73e) [0x7f7d33b3873e] dic 14 16:55:48 servidor smbd[25803]: #13 /usr/lib/samba/libsmbd-base-samba4.so(+0x12c83f) [0x7f7d33b3983f] dic 14 16:55:48 servidor smbd[25803]: #14 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x80) [0x7f7d3162bf60] dic 14 16:55:48 servidor smbd[25803]: #15 /usr/lib/libtevent.so.0(+0xd448) [0x7f7d31632448] dic 14 16:55:48 servidor smbd[25803]: #16 /usr/lib/libtevent.so.0(+0xb409) [0x7f7d31630409] dic 14 16:55:48 servidor smbd[25803]: #17 /usr/lib/libtevent.so.0(_tevent_loop_once+0x92) [0x7f7d3162b682] dic 14 16:55:48 servidor smbd[25803]: #18 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x1c) [0x7f7d3162b90c] dic 14 16:55:48 servidor smbd[25803]: #19 /usr/lib/libtevent.so.0(+0xb3a9) [0x7f7d316303a9] dic 14 16:55:48 servidor smbd[25803]: #20 /usr/lib/samba/libsmbd-base-samba4.so(smbd_process+0x7b8) [0x7f7d33b3aca8] dic 14 16:55:48 servidor smbd[25803]: #21 /usr/bin/smbd(+0xcc14) [0x564718903c14] dic 14 16:55:48 servidor smbd[25803]: #22 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x80) [0x7f7d3162bf60] dic 14 16:55:48 servidor smbd[25803]: #23 /usr/lib/libtevent.so.0(+0xd448) [0x7f7d31632448] dic 14 16:55:48 servidor smbd[25803]: #24 /usr/lib/libtevent.so.0(+0xb409) [0x7f7d31630409] dic 14 16:55:48 servidor smbd[25803]: #25 /usr/lib/libtevent.so.0(_tevent_loop_once+0x92) [0x7f7d3162b682] dic 14 16:55:48 servidor smbd[25803]: #26 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x1c) [0x7f7d3162b90c] dic 14 16:55:48 servidor smbd[25803]: #27 /usr/lib/libtevent.so.0(+0xb3a9) [0x7f7d316303a9] dic 14 16:55:48 servidor smbd[25803]: #28 /usr/bin/smbd(main+0x1ea6) [0x5647188feec6] dic 14 16:55:48 servidor smbd[25803]: #29 /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f7d31464223] dic 14 16:55:48 servidor smbd[25803]: #30 /usr/bin/smbd(_start+0x2e) [0x5647188fefae] dic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.077528, 0] ../../source3/lib/util.c:836(smb_panic_s3) dic 14 16:55:48 servidor smbd[25803]: smb_panic(): calling panic action [/usr/share/samba/panic-action 25803] dic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.089848, 0] ../../source3/lib/util.c:844(smb_panic_s3) dic 14 16:55:48 servidor smbd[25803]: smb_panic(): action returned status 127 dic 14 16:55:48 servidor smbd[25803]: [2019/12/14 16:55:48.090051, 0] ../../source3/lib/dumpcore.c:318(dump_core) dic 14 16:55:48 servidor smbd[25803]: coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern dic 14 16:55:49 servidor systemd-coredump[32402]: Process 25803 (smbd) of user 0 dumped core. Stack trace of thread 25803: #0 0x00007f7d31477d7f raise (libc.so.6) #1 0x00007f7d31462672 abort (libc.so.6) #2 0x00007f7d3375f2b7 dump_core (libsmbconf.so.0) #3 0x00007f7d33736bcf smb_panic_s3 (libsmbconf.so.0) #4 0x00007f7d33d8e75d smb_panic (libsamba-util.so.0) #5 0x00007f7d33ba231e n/a (libsmbd-base-samba4.so) #6 0x00007f7d33ba2520 n/a (libsmbd-base-samba4.so) #7 0x00007f7d33ba496c release_posix_lock_posix_flavour (libsmbd-base-samba4.so) #8 0x00007f7d33ba055e brl_unlock (libsmbd-base-samba4.so) #9 0x00007f7d33b9c50c do_unlock (libsmbd-base-samba4.so) #10 0x00007f7d33b08249 smbd_do_setfilepathinfo (libsmbd-base-samba4.so) #11 0x00007f7d33b0a03f n/a (libsmbd-base-samba4.so) #12 0x00007f7d33b0c078 reply_trans2 (libsmbd-base-samba4.so) #13 0x00007f7d33b36323 n/a (libsmbd-base-samba4.so) #14 0x00007f7d33b3873e n/a (libsmbd-base-samba4.so) #15 0x00007f7d33b3983f n/a (libsmbd-base-samba4.so) #16 0x00007f7d3162bf60 tevent_common_invoke_fd_handler (libtevent.so.0) #17 0x00007f7d31632448 n/a (libtevent.so.0) #18 0x00007f7d31630409 n/a (libtevent.so.0) #19 0x00007f7d3162b682 _tevent_loop_once (libtevent.so.0) #20 0x00007f7d3162b90c tevent_common_loop_wait (libtevent.so.0) #21 0x00007f7d316303a9 n/a (libtevent.so.0) #22 0x00007f7d33b3aca8 smbd_process (libsmbd-base-samba4.so) #23 0x0000564718903c14 n/a (smbd) #24 0x00007f7d3162bf60 tevent_common_invoke_fd_handler (libtevent.so.0) #25 0x00007f7d31632448 n/a (libtevent.so.0) #26 0x00007f7d31630409 n/a (libtevent.so.0) #27 0x00007f7d3162b682 _tevent_loop_once (libtevent.so.0) #28 0x00007f7d3162b90c tevent_common_loop_wait (libtevent.so.0) #29 0x00007f7d316303a9 n/a (libtevent.so.0) #30 0x00005647188feec6 main (smbd) #31 0x00007f7d31464223 __libc_start_main (libc.so.6) #32 0x00005647188fefae _start (smbd) Stack trace of thread 32398: #0 0x00007f7d31611e5b pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007f7d337bf80d n/a (libmessages-dgm-samba4.so) #2 0x00007f7d3160ba9d start_thread (libpthread.so.0) #3 0x00007f7d3153baf3 __clone (libc.so.6) Backtrace (in /var/log/samba/log.): 2019/12/14 16:55:48.076465, 0] ../../lib/util/fault.c:261(log_stack_trace) BACKTRACE: 31 stack frames: #0 /usr/lib/libsamba-util.so.0(log_stack_trace+0x31) [0x7f7d33d8e661] #1 /usr/lib/libsmbconf.so.0(smb_panic_s3+0x1a) [0x7f7d33736b8a] #2 /usr/lib/libsamba-util.so.0(smb_panic+0x2d) [0x7f7d33d8e75d] #3 /usr/lib/samba/libsmbd-base-samba4.so(+0x19531e) [0x7f7d33ba231e] #4 /usr/lib/samba/libsmbd-base-samba4.so(+0x195520) [0x7f7d33ba2520] #5 /usr/lib/samba/libsmbd-base-samba4.so(release_posix_lock_posix_flavour+0x24c) [0x7f7d33ba496c] #6 /usr/lib/samba/libsmbd-base-samba4.so(brl_unlock+0x5ce) [0x7f7d33ba055e] #7 /usr/lib/samba/libsmbd-base-samba4.so(do_unlock+0x10c) [0x7f7d33b9c50c] #8 /usr/lib/samba/libsmbd-base-samba4.so(smbd_do_setfilepathinfo+0x1dc9) [0x7f7d33b08249] #9 /usr/lib/samba/libsmbd-base-samba4.so(+0xfd03f) [0x7f7d33b0a03f] #10 /usr/lib/samba/libsmbd-base-samba4.so(reply_trans2+0x4f8) [0x7f7d33b0c078] #11 /usr/lib/samba/libsmbd-base-samba4.so(+0x129323) [0x7f7d33b36323] #12 /usr/lib/samba/libsmbd-base-samba4.so(+0x12b73e) [0x7f7d33b3873e] #13 /usr/lib/samba/libsmbd-base-samba4.so(+0x12c83f) [0x7f7d33b3983f] #14 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x80) [0x7f7d3162bf60] #15 /usr/lib/libtevent.so.0(+0xd448) [0x7f7d31632448] #16 /usr/lib/libtevent.so.0(+0xb409) [0x7f7d31630409] #17 /usr/lib/libtevent.so.0(_tevent_loop_once+0x92) [0x7f7d3162b682] #18 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x1c) [0x7f7d3162b90c] #19 /usr/lib/libtevent.so.0(+0xb3a9) [0x7f7d316303a9] #20 /usr/lib/samba/libsmbd-base-samba4.so(smbd_process+0x7b8) [0x7f7d33b3aca8] #21 /usr/bin/smbd(+0xcc14) [0x564718903c14] #22 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x80) [0x7f7d3162bf60] #23 /usr/lib/libtevent.so.0(+0xd448) [0x7f7d31632448] #24 /usr/lib/libtevent.so.0(+0xb409) [0x7f7d31630409] #25 /usr/lib/libtevent.so.0(_tevent_loop_once+0x92) [0x7f7d3162b682] #26 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x1c) [0x7f7d3162b90c] #27 /usr/lib/libtevent.so.0(+0xb3a9) [0x7f7d316303a9] #28 /usr/bin/smbd(main+0x1ea6) [0x5647188feec6] #29 /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f7d31464223] #30 /usr/bin/smbd(_start+0x2e) [0x5647188fefae] [2019/12/14 16:55:48.077528, 0] ../../source3/lib/util.c:836(smb_panic_s3) smb_panic(): calling panic action [/usr/share/samba/panic-action 25803] sh: /usr/share/samba/panic-action: No existe el fichero o el directorio [2019/12/14 16:55:48.089848, 0] ../../source3/lib/util.c:844(smb_panic_s3) smb_panic(): action returned status 127 [2019/12/14 16:55:48.090051, 0] ../../source3/lib/dumpcore.c:318(dump_core) coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern
More on this... Even when switching to SMB3 seems to avoid the message, I have been testing the setup from the client (kernel 5.3.11, mount.cifs 6.9) and using with a process that opens a file on a server, and locks it, then waits for user input before unlocking and closing it: If the process terminates normally, even without releasing the lock or closing the file, the lock get released. But, if the process terminates abnormally (for example, using a SIGINT (Ctrl-C)), the lock remains, and the samba server reports the file still open, even with the process terminated. Pid User(ID) DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 3665 99 DENY_NONE 0x12019f RDWR NONE /home/appl caja/test.dbf Mon Dec 16 00:39:16 2019 3665 99 DENY_NONE 0x12019f RDWR NONE /home/appl caja/test.dbf Mon Dec 16 00:41:10 2019 3665 99 DENY_NONE 0x12019f RDWR NONE /home/appl caja/test.dbf Mon Dec 16 00:41:13 2019 3665 99 DENY_NONE 0x12019f RDWR NONE /home/appl caja/test.dbf Mon Dec 16 00:41:14 2019 3665 99 DENY_NONE 0x12019f RDWR NONE /home/appl caja/test.dbf Mon Dec 16 00:41:17 2019 The file gets liberated only when the share is unmounted and remounted again. Al subsequent attempts to lock the file fail until the share is dropped and mounted again. The kernel throws messages if tried: [293567.265501] CIFS VFS: cifs_setlk failed rc=-13 [294456.753677] CIFS VFS: cifs_setlk failed rc=-13 [294466.120033] CIFS VFS: cifs_setlk failed rc=-13 And when the locking process is terminated, the kernel also complains: [294651.296736] CIFS VFS: cifs_setlk failed rc=-4 So the problem seems to reside in the kernel of the client machine (not liberating the lock). Possibly not related, but the client machine throws messages when the share is remounted: [291274.164982] CIFS: Attempting to mount //server/data [291274.165629] FS-Cache: Duplicate cookie detected [291274.165634] FS-Cache: O-cookie c=00000000a2b9f7ca [p=000000005ad09d76 fl=222 nc=1 na=1] [291274.165636] FS-Cache: O-cookie d=00000000fafb94b6 n=0000000041124cc6 [291274.165637] FS-Cache: O-key=[8] '020001bdc0a80002' [291274.165644] FS-Cache: N-cookie c=0000000087d8e734 [p=000000005ad09d76 fl=2 nc=0 na=1] [291274.165646] FS-Cache: N-cookie d=00000000fafb94b6 n=000000000d42ff0e [291274.165647] FS-Cache: N-key=[8] '020001bdc0a80002'
Further tests: This behavior does not happen in kernel 4.4.11, mount.cifs 6.4. It releases the locks correctly against the same samba server (protocol NT1).