Created attachment 16186 [details] Interesting stuff begins at 176 MacOS clients may in some situations compound an SMB2 CREATE and READ for AFP Info stream before one exists on the file. In the initial open() when fruit is configured to store metadata as stream, O_CREAT flag is removed before passing to streams_xattr. This results in streams_xattr not generating an FSP extension and the subsequent pread() to fall through streams_xattr and get picked up eventually by the default pread(), which in this case returns 0. vfs_fruit flags this as a short read, generates log message at DBG_ERR, then tries to remove the non-existent xattr generating a second log message at DBG_ERR. WIP fix here: https://gitlab.com/samba-team/devel/samba/-/commits/anodos325-fix-excessive-logging-in-fruit
Comment on attachment 16186 [details] Interesting stuff begins at 176 This is a pcap of MacOS client writing to samba 4.10.17.
Created attachment 16187 [details] test file with icon This is the file I was using for testing issue. Procedure is to copy / paste into SMB share.
Sample log message: [2020/08/27 14:26:56.776316, 0] ../../source3/modules/vfs_fruit.c:4240(fruit_pread_meta_stream) fruit_pread_meta_stream: Removing [Finder Refresh.app:AFP_AfpInfo] after short read [0] [2020/08/27 14:26:56.776462, 0] ../../source3/modules/vfs_fruit.c:4244(fruit_pread_meta_stream) fruit_pread_meta_stream: Removing [Finder Refresh.app:AFP_AfpInfo] failed
Created attachment 16188 [details] pcap from macos server Compounded CREATE | READ on AFPInfo is in 2118 and 2223
Sorry 2113 and 2118. It appears like in this case MacOS server is returning basic AFPInfo xattr.