On a customer system where the profile share root was a subdirectory of the home share, the following errors showed up in the log: [2026/04/20 10:34:13.384346, 0] ../../source3/locking/share_mode_lock.c:826(get_static_share_mode_data_fn) get_static_share_mode_data_fn: locking_tdb_data_get failed [2026/04/20 10:34:13.384384, 0] ../../source3/locking/share_mode_lock.c:885(get_static_share_mode_data) get_static_share_mode_data: get_static_share_mode_data_fn failed: NT_STATUS_INTERNAL_DB_CORRUPTION [2026/04/20 10:34:13.384393, 0] ../../source3/locking/share_mode_lock.c:3293(share_mode_entry_prepare_lock_fn) share_mode_entry_prepare_lock_fn: get_share_mode_lock_internal failed: NT_STATUS_INTERNAL_DB_CORRUPTION [2026/04/20 10:34:13.384400, 0] ../../source3/smbd/open.c:4118(open_file_ntcreate) open_file_ntcreate: share_mode_entry_prepare_lock_add() failed for XXXXXXXXX - NT_STATUS_INTERNAL_DB_CORRUPTION After disabling Directory Leases the issue went away. A possible cause would be the client requesting directory leases for the same directory via different paths on both shares, although this should be caught by lease_match() the same file we detect it for files. *scratches head*
for completeness, here is the profile and home definition of that system, where this issue was observed. Yes, this is not a recommended setup at all - but it should not break things completely :-) [win_profile.v6] browseable = No comment = Windows Profil create mask = 0600 csc policy = disable directory mask = 0700 dos filemode = Yes path = %H/.profiles/user_profiles.v6 read only = No vfs objects = fruit acl_xattr streams_xattr [homes] browseable = No comment = Home Directories create mask = 0640 delete readonly = Yes directory mask = 0750 force unknown acl user = Yes include = /etc/samba/0.0.0.0.conf read only = No veto oplock files = /*.xls/