Bug 13108 - streams_xattr does not work on shares that use Windows ACLs
streams_xattr does not work on shares that use Windows ACLs
Status: RESOLVED INVALID
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules
4.7.0
All All
: P5 normal
: ---
Assigned To: Ralph Böhme
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-29 08:40 UTC by Marc Muehlfeld
Modified: 2017-10-29 16:59 UTC (History)
0 users

See Also:


Attachments
Level 10 debug log (406.62 KB, application/x-bzip)
2017-10-29 08:40 UTC, Marc Muehlfeld
no flags Details
New level 10 debug log (302.58 KB, application/gzip)
2017-10-29 13:29 UTC, Marc Muehlfeld
no flags Details
network capture (39.00 KB, application/vnd.tcpdump.pcap)
2017-10-29 13:30 UTC, Marc Muehlfeld
no flags Details
smb.conf (828 bytes, text/plain)
2017-10-29 13:30 UTC, Marc Muehlfeld
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2017-10-29 08:40:48 UTC
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.
Comment 1 Ralph Böhme 2017-10-29 10:00:19 UTC
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?
Comment 2 Ralph Böhme 2017-10-29 10:14:00 UTC
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?
Comment 3 Marc Muehlfeld 2017-10-29 13:29:43 UTC
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)
Comment 4 Marc Muehlfeld 2017-10-29 13:30:04 UTC
Created attachment 13738 [details]
network capture
Comment 5 Marc Muehlfeld 2017-10-29 13:30:22 UTC
Created attachment 13739 [details]
smb.conf
Comment 6 Ralph Böhme 2017-10-29 15:24:52 UTC
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!
Comment 7 Marc Muehlfeld 2017-10-29 16:59:32 UTC
(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.