Thanks for using the TrueNAS Community Edition issue tracker! TrueNAS Enterprise users receive direct support for their reports from our support portal.

SMB core dump with large file set copy from Mac

Description

When copying large file sets (was using trees with ~2-4k smaller files) from my Macs (running latest Catalina) via SMB on the latest TrueNAS Scale, the transfer will eventually stop at some random point with the following message on the Mac:

"The operation can’t be completed because an item with the name “<some-file-name>” already exists."

The TrueNAS Scale console reports a core dump. I'm including a couple examples below, but what I "think" is happening is that Samba is core dumping (for whatever reason) and when it comes back up the Mac re-connects and tries to send the last file again which I'm guessing already exists because it happened to have been written before the dump. Just a guess though

The filesystem was created with "SMB" set, and I've tried a variety of SMB share settings including the default, smb+afp, and private with just Apple character encoding. Here are a couple examples:

Mac error:

The operation can’t be completed because an item with the name “index.js” already exists.

TrueNAS Scale console:

truenas# 2020 Dec 13 23:27:03 truenas Process 2695864 (smbd) of user 0 dumped core.

Stack trace of thread 2695864:
#0 0x00007f833324bdb1 __GI_raise (libc.so.6 + 0x3bdb1)
#1 0x00007f8333235537 __GI_abort (libc.so.6 + 0x25537)
#2 0x00007f83336f8e10 dump_core (libsmbconf.so.0 + 0x29e10)
#3 0x00007f8333718a51 smb_panic_s3 (libsmbconf.so.0 + 0x49a51)
#4 0x00007f83337a4d67 smb_panic (libsamba-util.so.0 + 0x19d67)
#5 0x00007f83339f19b2 n/a (libsmbd-base.so.0 + 0x1dd9b2)
#6 0x00007f83334db8e6 n/a (libtalloc.so.2 + 0x48e6)
#7 0x00007f83339ea231 set_delete_on_close (libsmbd-base.so.0 + 0x1d6231)
#8 0x00007f8330cdd84e n/a (fruit.so + 0xd84e)
#9 0x00007f833396431c vfs_pwrite_data (libsmbd-base.so.0 + 0x15031c)
#10 0x00007f83338fcaa8 write_file (libsmbd-base.so.0 + 0xe8aa8)
#11 0x00007f833399ab36 smbd_smb2_request_process_write (libsmbd-base.so.0 + 0x186b36)
#12 0x00007f833398c2d0 smbd_smb2_request_dispatch (libsmbd-base.so.0 + 0x1782d0)
#13 0x00007f833398de07 n/a (libsmbd-base.so.0 + 0x179e07)
#14 0x00007f833377d10d tevent_common_invoke_fd_handler (libtevent.so.0 + 0x710d)
#15 0x00007f8333783497 n/a (libtevent.so.0 + 0xd497)
#16 0x00007f8333781617 n/a (libtevent.so.0 + 0xb617)
#17 0x00007f833377c7b4 _tevent_loop_once (libtevent.so.0 + 0x67b4)
#18 0x00007f833377ca9b tevent_common_loop_wait (libtevent.so.0 + 0x6a9b)
#19 0x00007f83337815b7 n/a (libtevent.so.0 + 0xb5b7)
#20 0x00007f833397abe0 smbd_process (libsmbd-base.so.0 + 0x166be0)
#21 0x00005602c1e9a0f5 n/a (smbd + 0xb0f5)
#22 0x00007f833377d10d tevent_common_invoke_fd_handler (libtevent.so.0 + 0x710d)
#23 0x00007f8333783497 n/a (libtevent.so.0 + 0xd497)
#24 0x00007f8333781617 n/a (libtevent.so.0 + 0xb617)
#25 0x00007f833377c7b4 _tevent_loop_once (libtevent.so.0 + 0x67b4)
#26 0x00007f833377ca9b tevent_common_loop_wait (libtevent.so.0 + 0x6a9b)
#27 0x00007f83337815b7 n/a (libtevent.so.0 + 0xb5b7)
#28 0x00005602c1e97b61 main (smbd + 0x8b61)
#29 0x00007f8333236cca __libc_start_main (libc.so.6 + 0x26cca)
#30 0x00005602c1e97dba _start (smbd + 0x8dba)

Mac error:

The operation can’t be completed because an item with the name “HISTORY.md” already exists.

TrueNAS Scale console:

Stack trace of thread 2672248:
#0 0x00007ff2f0560db1 __GI_raise (libc.so.6 + 0x3bdb1)
#1 0x00007ff2f054a537 __GI_abort (libc.so.6 + 0x25537)
#2 0x00007ff2f0a0de10 dump_core (libsmbconf.so.0 + 0x29e10)
#3 0x00007ff2f0a2da51 smb_panic_s3 (libsmbconf.so.0 + 0x49a51)
#4 0x00007ff2f0ab9d67 smb_panic (libsamba-util.so.0 + 0x19d67)
#5 0x00007ff2f0d00150 n/a (libsmbd-base.so.0 + 0x1d7150)
#6 0x00007ff2f07f08e6 n/a (libtalloc.so.2 + 0x48e6)
#7 0x00007ff2f0d06d65 n/a (libsmbd-base.so.0 + 0x1ddd65)
#8 0x00007ff2f0a27c9e n/a (libsmbconf.so.0 + 0x43c9e)
#9 0x00007ff2f050341d n/a (libdbwrap.so.0 + 0x641d)
#10 0x00007ff2f01327f9 tdb_parse_record (libtdb.so.1 + 0x57f9)
#11 0x00007ff2f0503899 n/a (libdbwrap.so.0 + 0x6899)
#12 0x00007ff2f0a25054 n/a (libsmbconf.so.0 + 0x41054)
#13 0x00007ff2f0a29b78 g_lock_dump (libsmbconf.so.0 + 0x45b78)
#14 0x00007ff2f0d091b2 share_mode_do_locked (libsmbd-base.so.0 + 0x1e01b2)
#15 0x00007ff2f0cfe2c0 do_lock (libsmbd-base.so.0 + 0x1d52c0)
#16 0x00007ff2ee00a440 n/a (fruit.so + 0xa440)
#17 0x00007ff2f0cab555 smbd_smb2_request_process_create (libsmbd-base.so.0 + 0x182555)
#18 0x00007ff2f0ca14dd smbd_smb2_request_dispatch (libsmbd-base.so.0 + 0x1784dd)
#19 0x00007ff2f0ca2e07 n/a (libsmbd-base.so.0 + 0x179e07)
#20 0x00007ff2f0a9210d tevent_common_invoke_fd_handler (libtevent.so.0 + 0x710d)
#21 0x00007ff2f0a98497 n/a (libtevent.so.0 + 0xd497)
#22 0x00007ff2f0a96617 n/a (libtevent.so.0 + 0xb617)
#23 0x00007ff2f0a917b4 _tevent_loop_once (libtevent.so.0 + 0x67b4)
#24 0x00007ff2f0a91a9b tevent_common_loop_wait (libtevent.so.0 + 0x6a9b)
#25 0x00007ff2f0a965b7 n/a (libtevent.so.0 + 0xb5b7)
#26 0x00007ff2f0c8fbe0 smbd_process (libsmbd-base.so.0 + 0x166be0)
#27 0x000055eb7073b0f5 n/a (smbd + 0xb0f5)
#28 0x00007ff2f0a9210d tevent_common_invoke_fd_handler (libtevent.so.0 + 0x710d)
#29 0x00007ff2f0a98497 n/a (libtevent.so.0 + 0xd497)
#30 0x00007ff2f0a96617 n/a (libtevent.so.0 + 0xb617)
#31 0x00007ff2f0a917b4 _tevent_loop_once (libtevent.so.0 + 0x67b4)
#32 0x00007ff2f0a91a9b tevent_common_loop_wait (libtevent.so.0 + 0x6a9b)
#33 0x00007ff2f0a965b7 n/a (libtevent.so.0 + 0xb5b7)
#34 0x000055eb70738b61 main (smbd + 0x8b61)
#35 0x00007ff2f054bcca __libc_start_main (libc.so.6 + 0x26cca)
#36 0x000055eb70738dba _start (smbd + 0x8dba)

Problem/Justification

None

Impact

None

SmartDraw Connector

Katalon Manual Tests (BETA)

Activity

Show:

Andrew Walker 
December 31, 2020 at 1:00 AM

I'll close this ticket as a duplicate one. If you can reproduce the performance issue with a clean share, file a new ticket and I'll take it from there.

Moonshine 
December 30, 2020 at 5:30 PM

Did not see a panic in the last tests, just the Finder hangs requiring a Mac reboot to clear.  (Restart Finder won't do it).  I'll give it a try with a fresh "standard" Samba share and your locking addition tonight.  I definitely don't need AFP compatibility if SMB works.  I agree the issue has definitely changed, so we can certainly close this one out if you'd prefer.  Thanks!

Andrew Walker 
December 30, 2020 at 1:09 AM

Does samba still crash? Performance issues are a different matter and there can be a variety of reasons for this with MacOS (especially on these sorts of shares where you're mixing AFP / SMB). Keep lockdir setting, create new share, copy files from Mac to new share and test with fresh data (please avoid toggling any settings related to apple-specific compatibility).

Moonshine 
December 29, 2020 at 11:39 PM

Adding "lock directory = /var/run/samba" to Services->SMB and restarting SMB didn't seem to help in my case.  Finder still seems to get stuck quite quickly using my test folder.  Tested on MacBook Pro (wifi) and iMac (ethernet) with the same result.   FWIW I'm on TrueNAS Scale 20.12 currently with the following config (largely defaults outside the locking addition):

# Global parameters [global] bind interfaces only = Yes disable spoolss = Yes dns proxy = No enable web service discovery = Yes load printers = No lock directory = /var/run/samba logging = file max log size = 51200 printcap name = /dev/null registry shares = Yes restrict anonymous = 2 server role = standalone server server string = TrueNAS Server unix extensions = No workgroup = MOONSHINERIDGE idmap config *: range = 90000001-100000000 idmap config * : backend = tdb dos filemode = Yes [SambaTest] ea support = No level2 oplocks = No mangled names = no oplocks = No path = /mnt/Blackhole/SambaTest read only = No vfs objects = catia streams_xattr shadow_copy_zfs acl_xattr zfs_core io_uring streams_xattr:store_stream_type = no streams_xattr:prefix = user. fruit:resource = file fruit:metadata = netatalk fruit:locking = netatalk catia:mappings = 0x01:0xf001,0x02:0xf002,0x03:0xf003,0x04:0xf004,0x05:0xf005,0x06:0xf006,0x07:0xf007,0x08:0xf008,0x09:0xf009,0x0a:0xf00a,0x0b:0xf00b,0x0c:0xf00c,0x0d:0xf00d,0x0e:0xf00e,0x0f:0xf00f,0x10:0xf010,0x11:0xf011,0x12:0xf012,0x13:0xf013,0x14:0xf014,0x15:0xf015,0x16:0xf016,0x17:0xf017,0x18:0xf018,0x19:0xf019,0x1a:0xf01a,0x1b:0xf01b,0x1c:0xf01c,0x1d:0xf01d,0x1e:0xf01e,0x1f:0xf01f,0x22:0xf020,0x2a:0xf021,0x3a:0xf022,0x3c:0xf023,0x3e:0xf024,0x3f:0xf025,0x5c:0xf026,0x7c:0xf027 nfs4:chown = true

 

William Gryzbowski 
December 29, 2020 at 12:04 PM

Guy on related ticket says it workarounds the issue.

Duplicate

Details

Assignee

Reporter

Labels

Components

Fix versions

Affects versions

Priority

More fields

Katalon Platform

Created December 14, 2020 at 4:25 PM
Updated July 1, 2022 at 4:59 PM
Resolved December 31, 2020 at 1:01 AM