Just got a core dump from Samba 4.17.2 smbd, GDB backtrace: Also, I when bug reporting it in bugzilla, can’t select 4.17.2 in Version (latest there seems to be 4.17.1 :-) FreeBSD 12.3. - Peter Sent by thr_kill() from pid 33958 and user 0. #0 0x00000008043a769a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x00000008043a769a in thr_kill () from /lib/libc.so.7 #1 0x00000008043a5af4 in raise () from /lib/libc.so.7 #2 0x000000080431b719 in abort () from /lib/libc.so.7 #3 0x0000000801f0af37 in dump_core () at ../../source3/lib/dumpcore.c:338 #4 0x0000000801f17f76 in smb_panic_s3 (why=<optimized out>) at ../../source3/lib/util.c:713 #5 0x0000000803d8b7f8 in smb_panic (why=why@entry=0x8017d6b8c "assert failed: slash == NULL") at ../../lib/util/fault.c:198 #6 0x00000008017061ba in non_widelink_open (dirfsp=dirfsp@entry=0x811dc9120, fsp=fsp@entry=0x811dcab60, smb_fname=smb_fname@entry=0x80f32fa00, _how=_how@entry=0x7fffffffdf00, link_depth=link_depth@entry=0) at ../../source3/smbd/open.c:773 #7 0x0000000801708eca in fd_openat (dirfsp=dirfsp@entry=0x811dc9120, smb_fname=smb_fname@entry=0x80f32fa00, fsp=0x811dcab60, _how=_how@entry=0x7fffffffe000) at ../../source3/smbd/open.c:952 #8 0x00000008016e2c9f in openat_pathref_fullname (conn=conn@entry=0x80eb98c60, dirfsp=dirfsp@entry=0x811dc9120, basefsp=basefsp@entry=0x0, full_fname=full_fname@entry=0x7fffffffdff8, smb_fname=smb_fname@entry=0x80f32fa00, how=how@entry=0x7fffffffe000) at ../../source3/smbd/files.c:481 #9 0x00000008016e342b in openat_pathref_fsp (dirfsp=dirfsp@entry=0x811dc9120, smb_fname=smb_fname@entry=0x80f32fa00) at ../../source3/smbd/files.c:590 #10 0x0000000801704601 in openat_pathref_fsp_case_insensitive (ucf_flags=0, smb_fname_rel=0x80f32fa00, dirfsp=0x811dc9120) at ../../source3/smbd/filename.c:912 #11 filename_convert_dirfsp_nosymlink (_unparsed=<synthetic pointer>, _substitute=<synthetic pointer>, _smb_fname=0x7fffffffe208, _dirfsp=0x7fffffffe200, twrp=0, ucf_flags=0, name_in=<optimized out>, conn=0x80eb98c60, mem_ctx=0x80ebeb0e0) at ../../source3/smbd/filename.c:1259 #12 filename_convert_dirfsp (mem_ctx=mem_ctx@entry=0x80ebeb0e0, conn=<optimized out>, name_in=0x80ebeb530 "sopas205/Downloads/teamviewerqs/profile/dosdevices/CQFO6Q~M", ucf_flags=0, twrp=0, _dirfsp=_dirfsp@entry=0x7fffffffe200, _smb_fname=0x7fffffffe208) at ../../source3/smbd/filename.c:1457 #13 0x0000000801746f20 in smbd_smb2_create_send (in_context_blobs=..., in_name=0x80ebead30 "sopas205\\Downloads\\teamviewerqs\\profile\\dosdevices\\CQFO6Q~M", in_create_options=<optimized out>, in_create_disposition=<optimized out>, in_share_access=3, in_file_attributes=0, in_desired_access=1048705, in_impersonation_level=2, in_oplock_level=<optimized out>, smb2req=0x80ebea8e0, ev=<optimized out>, mem_ctx=0x80ebea8e0) at ../../source3/smbd/smb2_create.c:976 #14 smbd_smb2_request_process_create (smb2req=smb2req@entry=0x80ebea8e0) at ../../source3/smbd/smb2_create.c:270 #15 0x000000080173c7c7 in smbd_smb2_request_dispatch (req=req@entry=0x80ebea8e0) at ../../source3/smbd/smb2_server.c:3399 #16 0x000000080173d4b3 in smbd_smb2_io_handler (fde_flags=<optimized out>, xconn=0x80eb9e560) (gdb) frame 6 #6 0x00000008017061ba in non_widelink_open (dirfsp=dirfsp@entry=0x811dc9120, fsp=fsp@entry=0x811dcab60, smb_fname=smb_fname@entry=0x80f32fa00, _how=_how@entry=0x7fffffffdf00, link_depth=link_depth@entry=0) at ../../source3/smbd/open.c:773 773 SMB_ASSERT(slash == NULL); (gdb) print *dirfsp $1 = {next = 0x811dc9d60, prev = 0x811dcab60, fnum = 0, op = 0x0, conn = 0x80eb98c60, fh = 0x812efcb00, num_smb_operations = 0, file_id = { devid = 5952628266332556909, inode = 4654, extid = 0}, initial_allocation_size = 0, file_pid = 0, vuid = 0, open_time = {tv_sec = 0, tv_usec = 0}, access_mask = 0, fsp_flags = {is_pathref = true, is_fsa = false, have_proc_fds = false, kernel_share_modes_taken = false, update_write_time_triggered = false, update_write_time_on_close = false, write_time_forced = false, can_lock = false, can_read = false, can_write = false, modified = false, is_directory = true, is_dirfsp = false, aio_write_behind = false, initial_delete_on_close = false, delete_on_close = false, is_sparse = false, backup_intent = false, use_ofd_locks = false, closing = false, lock_failure_seen = false, encryption_required = false, fstat_before_close = false}, update_write_time_event = 0x0, close_write_time = {tv_sec = 0, tv_nsec = -2}, oplock_type = 0, leases_db_seqnum = 0, lease_type = 0, lease = 0x0, sent_oplock_break = 0, oplock_timeout = 0x0, current_lock_count = 0, posix_flags = 0, fsp_name = 0x80f333e80, name_hash = 1414196691, mid = 0, vfs_extension = 0x0, fake_file_handle = 0x0, notify = 0x0, base_fsp = 0x0, stream_fsp = 0x0, share_mode_flags_seqnum = 0, share_mode_flags = 0, brlock_seqnum = 0, brlock_rec = 0x0, dptr = 0x0, print_file = 0x0, num_aio_requests = 0, aio_requests = 0x0, blocked_smb1_lock_reqs = 0x0, lock_failure_offset = 0} (gdb) print *fsp $2 = {next = 0x811dc9120, prev = 0x80eb65ae0, fnum = 0, op = 0x0, conn = 0x80eb98c60, fh = 0x812efd1e0, num_smb_operations = 0, file_id = {devid = 0, inode = 0, extid = 0}, initial_allocation_size = 0, file_pid = 0, vuid = 0, open_time = {tv_sec = 1667232016, tv_usec = 588582}, access_mask = 0, fsp_flags = {is_pathref = true, is_fsa = false, have_proc_fds = false, kernel_share_modes_taken = false, update_write_time_triggered = false, update_write_time_on_close = false, write_time_forced = false, can_lock = false, can_read = false, can_write = false, modified = false, is_directory = false, is_dirfsp = false, aio_write_behind = false, initial_delete_on_close = false, delete_on_close = false, is_sparse = false, backup_intent = false, use_ofd_locks = false, closing = false, lock_failure_seen = false, encryption_required = false, fstat_before_close = false}, update_write_time_event = 0x0, close_write_time = {tv_sec = 0, tv_nsec = -2}, oplock_type = 0, leases_db_seqnum = 0, lease_type = 0, lease = 0x0, sent_oplock_break = 0, oplock_timeout = 0x0, current_lock_count = 0, posix_flags = 0, fsp_name = 0x811dc4780, name_hash = 2156576274, mid = 0, vfs_extension = 0x0, fake_file_handle = 0x0, notify = 0x0, base_fsp = 0x0, stream_fsp = 0x0, share_mode_flags_seqnum = 0, share_mode_flags = 0, brlock_seqnum = 0, brlock_rec = 0x0, dptr = 0x0, print_file = 0x0, num_aio_requests = 0, aio_requests = 0x0, blocked_smb1_lock_reqs = 0x0, lock_failure_offset = 0} (gdb) print *smb_fname $3 = {base_name = 0x80f32fb20 "sopas205/Downloads/teamviewerqs/profile/drive_c", stream_name = 0x0, flags = 0, st = {st_ex_dev = 0, st_ex_ino = 0, st_ex_mode = 0, st_ex_nlink = 0, st_ex_uid = 0, st_ex_gid = 0, st_ex_rdev = 0, st_ex_size = 0, st_ex_atime = {tv_sec = 0, tv_nsec = 0}, st_ex_mtime = {tv_sec = 0, tv_nsec = 0}, st_ex_ctime = {tv_sec = 0, tv_nsec = 0}, st_ex_btime = {tv_sec = 0, tv_nsec = 0}, st_ex_blksize = 0, st_ex_blocks = 0, st_ex_flags = 0, st_ex_iflags = 0}, twrp = 0, fsp = 0x0, fsp_link = 0x0} - Peter
Can you also print *smb_fname_rel?
Sure. (gdb) print *smb_fname_rel $6 = {base_name = 0x80f32fb20 "sopas205/Downloads/teamviewerqs/profile/drive_c", stream_name = 0x0, flags = 0, st = {st_ex_dev = 0, st_ex_ino = 0, st_ex_mode = 0, st_ex_nlink = 0, st_ex_uid = 0, st_ex_gid = 0, st_ex_rdev = 0, st_ex_size = 0, st_ex_atime = {tv_sec = 0, tv_nsec = 0}, st_ex_mtime = {tv_sec = 0, tv_nsec = 0}, st_ex_ctime = {tv_sec = 0, tv_nsec = 0}, st_ex_btime = {tv_sec = 0, tv_nsec = 0}, st_ex_blksize = 0, st_ex_blocks = 0, st_ex_flags = 0, st_ex_iflags = 0}, twrp = 0, fsp = 0x0, fsp_link = 0x0} (gdb) print smb_fname_rel $8 = (struct smb_filename *) 0x80f32fa00 (gdb) print smb_fname $9 = (struct smb_filename *) 0x80f32fa00 Seems to point at the same struct as smb_fname. (gdb) print link_depth $10 = 0 (gdb) print *_how $11 = {flags = 4, mode = 0, resolve = 0} (gdb) print have_opath $15 = false The directory where this bug happened looks like this btw: root@filur02:/export/students/sopas205/Downloads/teamviewerqs/profile # ls -lr dosdevices drive_c drive_c: total 35 drwxr-xr-x 3 sopas205 student-liu.se 3 Oct 12 2020 windows drwxr-xr-x 3 sopas205 student-liu.se 3 Oct 12 2020 users drwxr-xr-x 2 sopas205 student-liu.se 33 Oct 12 2020 TeamViewer dosdevices: total 2 lrwxrwxrwx 1 sopas205 student-liu.se 1 Oct 12 2020 z: -> / lrwxrwxrwx 1 sopas205 student-liu.se 54 Oct 12 2020 c: -> /home/sopas205/Downloads/teamviewerqs/profile/drive_c/
OK, the directory dosdevices contains names "c:" and "z:", which will be represented as mangled names to the clients: CQFO6Q~M Looks like we're not handling the mapping from a mangled name back to the name on the filesystem in this codepath somehow.
Hmmm. I've tried on a recent 4.17 build and can't reproduce. $ mkdir dosdev $ cd dosdev $ ln -s / c: From smbclient: get dosdev\CQFO6Q~M NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \dosdev\CQFO6Q~M
Mangled names are working fine. $ mkdir dosdev $ cd dosdev $ touch testfile $ ln -s testfile c: From smbclient: get dosdev\CQFO6Q~M getting file \dosdev\CQFO6Q~M of size 0 as dosdev\CQFO6Q~M (In the local target directory) $ ls 'dosdev\CQFO6Q~M'
If I create this directory structure: peter86@espresso:/home/peter86$ ls -lR samba-15221 samba-15221: total 1 drwx------ 2 peter86 employee-liu.se 3 Nov 2 11:29 dosdevices drwx------ 2 peter86 employee-liu.se 2 Nov 2 11:21 drive_c samba-15221/dosdevices: total 1 lrwxrwxrwx 1 peter86 employee-liu.se 10 Nov 2 11:28 c: -> ../drive_c samba-15221/drive_c: total 0 "CQ And then try to access the CQFO6Q~M directory in a Windows 10 file browser window the I get a spat of coredumps. Same with smbclient: smbclient -k //filur04.it.liu.se/staff Try "help" to get a list of possible commands. smb: \> cd peter86 smb: \peter86\> cd samba-15221 smb: \peter86\samba-15221\> dir . D 0 Wed Nov 2 11:21:06 2022 .. D 0 Wed Nov 2 11:23:20 2022 drive_c D 0 Wed Nov 2 11:21:06 2022 dosdevices D 0 Wed Nov 2 11:29:26 2022 292968750 blocks of size 1024. 251388048 blocks available smb: \peter86\samba-15221\> cd dosdevices\ smb: \peter86\samba-15221\dosdevices\> dir . D 0 Wed Nov 2 11:29:26 2022 .. D 0 Wed Nov 2 11:21:06 2022 CQFO6Q~M D 0 Wed Nov 2 11:21:06 2022 292968750 blocks of size 1024. 251388048 blocks available smb: \peter86\samba-15221\dosdevices\> cd CQFO6Q~M smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> dir NT_STATUS_CONNECTION_DISCONNECTED listing \peter86\samba-15221\dosdevices\CQFO6Q~M\* smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> pwd Current directory is \\filur04.it.liu.se\staff\peter86\samba-15221\dosdevices\CQFO6Q~M\ smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection is disconnected now In our smb.conf we have: follow symlinks = true wide links = false Testing some more with smbclient: With "follow symlinks = false" the c: / CQFO6Q~M doesn't show up. With "wide links = true" it shows up but gives "NT_STATUS_OBJECT_NAME_INVALID" (follow symlinks setting doesn't matter in that case)
> With "wide links = true" it shows up but gives "NT_STATUS_OBJECT_NAME_INVALID" > (follow symlinks setting doesn't matter in that case) ... but it seems to sort-of work via Windows 10 file browser with the relative path. Sort of... Clicking on the "C:" I end up on the local machine C:\ :-)
Just tried this with your dirs and symlinks on Linux, but I can't reproduce the crash. Do you have any patches on top of plain 4.17.2? Can you share your smb.conf? I'll try on FreeBSD next.
FreeBSD 12.3p5 amd64 does not crash either. Would it be possible to set up a test system and let me in via ssh as root?
Created attachment 17611 [details] smb.conf Our smb.conf file.
We have some local patches but nothing that should affect this part of Samba. Anyway I rebuilt Samba now without any local patches - but still the same core dumps... Gcc 11.3.0 Umm... Some more background details about our systems: FreeBSD 12.3-RELEASE-p8 Dell PowerEdge R730xd & R740xd servers with 512-768GB RAM ZFS filesystems Joined to AD (Windows servers) with 171683 (unix) users, 2974 (unix) groups. Windows, MacOS & Linux users. SMB, NFS & SFTP access to the files.
Created attachment 17626 [details] Patch This fixes the problem for me. Can you try? Thanks for giving me access to a reproducer, this made it a lot simpler.
I can confirm that the patch seems to solve this core-dumping issue. Thanks!
Jule, can you merge this for 4.17.next? This is 4.17 only. Thanks, Volker
Pushed to autobuild-v4-17-test. Reviewed-By tag with Ralph added.
This bug was referenced in samba v4-17-test: 2803e76fba0ee0eb6bb7e0b7acaca5c397249941
Closing out bug report. Thanks!
This bug was referenced in samba v4-17-stable (Release samba-4.17.4): 2803e76fba0ee0eb6bb7e0b7acaca5c397249941