Created attachment 13736 [details] Level 10 debug log Problem description: Certain applications, such as Edge on Windows 10 1709, require alternative data streams to store additional information. If you enable the streams_xattr on a share that uses POSIX ACLs, ADS work as expected. However, if you enable the VFS module on a share with used Windows ACLs, which is hard-coded enabled on Samba DCs, the share does not work at all. Reproduceable: Always Affected Versions: 4.7.0 (Haven't tested older versions) Steps to reproduce: * Set up a share that uses Windows ACL (or use a share on a Samba DC, where this is enabled by default) * Add the following line to the share's section: vfs objects = streams_xattr * Restart Samba * Connect to the share Actual results: Windows fails to connect to the share after a short time out. Error: \\server\share_name is not accessible. You might not have permissions to use this network resource. Contact the administrator of this server to find out if you have access permissions. The specified network name is no longer available. Expected results: The share should work and have ADS support enabled. Additional information: Regarding the example I used in the problem description (Edge on Win10): If the share does not support alternative data streams, Edge fails to download files to a Samba share. Error: file_name might have been moved or deleted. Retry|Cancel|View downloads.
I just tested this with 4.7.0 and it works without problems. Share: [stream] path = /shares/test vfs objects = streams_xattr smbclient: [slow@kazak v47]$ ./bin/smbclient -U slow%x -m smb3 //localhost/stream -c exit [slow@kazak v47]$ echo $? 0 Windows 10: PS C:\Users\Administrator> net use \\10.10.11.100\stream Der Befehl wurde erfolgreich ausgeführt. Can you grab a network trace of a failing connection attempt and attach it to this PR please?
Ah, I missed the debug log, sorry. According to that, the client is trying to connect to a whole bunch of shares: $ grep "smbd_smb2_tree_connect: path" client.log | uniq smbd_smb2_tree_connect: path[\\dc1\IPC$] share[IPC$] smbd_smb2_tree_connect: path[\\dc1\netlogon] share[netlogon] smbd_smb2_tree_connect: path[\\dc1\sysvol] share[sysvol] smbd_smb2_tree_connect: path[\\dc1\p] share[p] smbd_smb2_tree_connect: path[\\dc1\Profiles] share[Profiles] smbd_smb2_tree_connect: path[\\dc1\pr] share[pr] smbd_smb2_tree_connect: path[\\dc1\pro] share[pro] smbd_smb2_tree_connect: path[\\dc1\prof] share[prof] smbd_smb2_tree_connect: path[\\dc1\p] share[p] smbd_smb2_tree_connect: path[\\dc1\pr] share[pr] smbd_smb2_tree_connect: path[\\dc1\pro] share[pro] smbd_smb2_tree_connect: path[\\dc1\Profiles] share[Profiles] smbd_smb2_tree_connect: path[\\dc1\IPC$] share[IPC$] smbd_smb2_tree_connect: path[\\dc1\Profiles] share[Profiles] Which one uses streams_xattr? Can you attach your full smb.conf pleaes?
Created attachment 13737 [details] New level 10 debug log (In reply to Ralph Böhme from comment #2) > Ah, I missed the debug log, sorry. According to that, the client is > trying to connect to a whole bunch of shares: I guess this happend, because I typed the path to the \\dc1\profiles share into the start menu search field. In this case, Windows tries to connect each time I type one more letter. Sorry. (In reply to Ralph Böhme from comment #1) > PS C:\Users\Administrator> net use \\10.10.11.100\stream > Der Befehl wurde erfolgreich ausgeführt. I can confirm that this command doesn't fail. However, after you assign a drive letter to the share, you cannot access it. Opening the share in Windows Explorer fails, and Samba calls the panic script to create a backtrace. I attached new a new debug log (which contains the backtrace), a network capture, and the smb.conf. The log contains: 1.) Connect the share on Win10 (net use x: \\dc1\profiles) 2.) Opening the share on Windows 10 (Double-click X: in Windows Explorer)
Created attachment 13738 [details] network capture
Created attachment 13739 [details] smb.conf
Are you sure you're running 4.7.0? This looks very much like bug 13032. The crash is in line 235 in source3/modules/vfs_streams_xattr.c in a DEBUG statement. Problem is, in 4.7.0 that line doesn't have a DEBUG statement, it's moved down a few lines. Can you reproduce with git master? Either way, please recompile with debug symbols so we have a stack-backtrace with symbols. Thanks!
(In reply to Ralph Böhme from comment #6) You are right. I accidentally reverted my test environment to a snapshot with 4.7.0rc5 instead of 4.7.0 final. It works with 4.7.0 final. Sorry for the noise. Closing this BZ as INVALID.