Created attachment 9657 [details]
log from smbd -d10 -i while reproducing problem

FWIW, I was able to reproduce this with the current tip of the samba tree, so it doesn't appear to be fixed already.

Hmmm. In the UNIX extensions codepath we have..

                if (INFO_LEVEL_IS_UNIX(info_level)) {
                        /*
                         * For CIFS UNIX extensions the target name may not exist.
                         */

                        /* Always do lstat for UNIX calls. */
                        SMB_VFS_LSTAT(conn, smb_fname);


which should do this correctly. I'll investigate.

Jeremy.

From your log we have the first instance of NT_STATUS_OBJECT_NAME_NOT_FOUND here:

>close_remove_share_mode: file rawhide.test/file.0. Delete on close was set - deleting file.
>find_delete_on_close_token: name_hash = 0xf2ac662e
>find__delete_on_close_token: dt->name_hash = 0xf2ac662e
>vfs_streaminfo failed: NT_STATUS_OBJECT_NAME_NOT_FOUND
>delete_all_streams failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

So it's inside vfs_streaminfo.

The code here in vfs_default.c looks like:

static NTSTATUS vfswrap_streaminfo(vfs_handle_struct *handle,
                                   struct files_struct *fsp,
                                   const char *fname,
                                   TALLOC_CTX *mem_ctx,
                                   unsigned int *pnum_streams,
                                   struct stream_struct **pstreams)
{
        SMB_STRUCT_STAT sbuf;
        struct stream_struct *tmp_streams = NULL;
        int ret;

        if ((fsp != NULL) && (fsp->is_directory)) {
                /*
                 * No default streams on directories
                 */
                goto done;
        }

        if ((fsp != NULL) && (fsp->fh->fd != -1)) {
                ret = SMB_VFS_FSTAT(fsp, &sbuf);
        }
        else {
                struct smb_filename smb_fname;

                ZERO_STRUCT(smb_fname);
                smb_fname.base_name = discard_const_p(char, fname);

                if (lp_posix_pathnames()) {
                        ret = SMB_VFS_LSTAT(handle->conn, &smb_fname);
                } else {
                        ret = SMB_VFS_STAT(handle->conn, &smb_fname);
                }
                sbuf = smb_fname.st;
        }

Which should handle this case correctly once CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated. I'm assuming you're doing this (although I'll check in the log :-).

Do you have any modules loaded on this share ? What is your smb.conf ?

Created attachment 9662 [details]
smb.conf

Here's my smb.conf -- it's nothing too exotic.

I'm pretty sure that cifs sets CIFS_UNIX_POSIX_PATHNAMES_CAP...

Hrm, no it doesn't seem to set that anywhere, but I don't think the client ever sends a call that would have that set. The only place we seem to consider it is in the response to a SMB_QUERY_CIFS_UNIX_INFO call (basically, the UNIX fsinfo call)...

Ok it does send it. What the client does is take the caps that the server sends, apply a mask and then send them back. Weird.

In any case, the caps sent back are 0x1db, which has CIFS_UNIX_POSIX_PATHNAMES_CAP set. It does not have CIFS_UNIX_POSIX_PATH_OPS_CAP set however. Could that be the problem?

Ah, but you have:

vfs objects = streams_xattr

in your [export] share. Bet that's it...

Yep, got it. The problem is the stream_xattr code calls get_ea_names_from_file() which has the code:

                if (fsp && fsp->fh->fd != -1) {
                        sizeret = SMB_VFS_FLISTXATTR(fsp, ea_namelist,
                                                     ea_namelist_size);
                } else {
                        sizeret = SMB_VFS_LISTXATTR(conn, fname, ea_namelist,
                                                    ea_namelist_size);
                }

because we don't have a SMB_VFS_LLISTXATTR call in our VFS. (I do have a patch for this but it's not finished yet).

The stream_xattr code doesn't cope with that. Fix to follow shortly.

Created attachment 9663 [details]
git-am fix for master.

Jeff, can you confirm it fixes it and add your 'Reviewed-by:' tag and I'll push to master and we'll get this into 4.0.next, 4.1.next.

Cheers,

Jeremy.

Comment on attachment 9663 [details]
git-am fix for master.

Yep, that fixed it! Thanks!

Erm...I'll leave you to add:

Reviewed-by: Jeff Layton <jlayton@samba.org>

...or maybe "Tested-by" would be better since I don't know this code well enough to do a proper review...

Created attachment 9667 [details]
git-am fix for 4.1.next and 4.0.next including cherry-pick info from master.

This is exactly the same fix Jeff +1'ed and went into master, just including the git cherry-pick info for 4.1.next and 4.0.next.

Jeremy.

Re-assigning to Karolin for inclusion in 4.1.next, 4.0.next.

Jeremy.

Comment on attachment 9667 [details]
git-am fix for 4.1.next and 4.0.next including cherry-pick info from master.

Looks like the same patch...

Pushed to autobuild-v4-1-test and autobuild-v4-0-test.

Pushed to v4-1-test and v4-0-test.
Closing out bug report.

Thanks!