Bug 14137 - Stale file handle error when using mkstemp on a share
Summary: Stale file handle error when using mkstemp on a share
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.11.0
Hardware: All Linux
: P5 major (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2019-09-22 13:06 UTC by Kacper
Modified: 2019-10-30 16:48 UTC (History)
2 users (show)

See Also:

network trace (7.21 KB, application/vnd.tcpdump.pcap)
2019-09-22 19:24 UTC, Kacper
no flags Details
smb.conf (525 bytes, text/plain)
2019-09-22 19:24 UTC, Kacper
no flags Details
WIP patch for master (5.25 KB, patch)
2019-09-23 23:43 UTC, Ralph Böhme
no flags Details
Patch for 4.11 cherry-picked from master (43.07 KB, patch)
2019-10-02 09:49 UTC, Ralph Böhme
jra: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper 2019-09-22 13:06:05 UTC

After upgrading to Samba 4.11 (from 4.10) I noticed that python
scripts using tempfile.mkstemp fail when run against samba cifs
mounts. Before I submit a bug report, could someone else try this out
so it's not just my setup?

How to reproduce:
1. Mount a Samba 4.11 share using the mount command: mount
//server1/share /tmp/share1
2. Run python script that is using mkstemp:
    import shutil
    import tempfile

    tmp_dest_fd, tmp_dest_name = tempfile.mkstemp(prefix=b'.file_tmp',
dir='/tmp/share1', suffix='test.pdf')
    shutil.move('testfile', tmp_dest_name)

Traceback (most recent call last):
  File "./test.py", line 9, in <module>
    shutil.move('testfile', tmp_dest_name)
  File "/usr/lib64/python2.7/shutil.py", line 301, in move
    copy2(src, real_dst)
  File "/usr/lib64/python2.7/shutil.py", line 130, in copy2
    copyfile(src, dst)
  File "/usr/lib64/python2.7/shutil.py", line 83, in copyfile
    with open(dst, 'wb') as fdst:
IOError: [Errno 116] Stale file handle: '/tmp/share1/.file_tmplB0NqLtest.pdf'

Expected results:
The operation should succeed without a stale file handle error.

Centos 7.6 / 3.10.0-1062.el7.x86_64
Python 3.6 / 2
Samba 4.11

Comment 1 Kacper 2019-09-22 18:20:25 UTC
After a git bisect I've identified the faulty commit. Reverting this commit solved this regression.

a3caf4140c01136a412c129cae28b433e33ab014 is the first bad commit
commit a3caf4140c01136a412c129cae28b433e33ab014
Author: Ralph Boehme <slow@samba.org>
Date:   Thu Jun 27 14:46:37 2019 +0200

    s3:smbd: use stored file_id in SMB_VFS_FS_FILE_ID()

    Signed-off-by: Ralph Boehme <slow@samba.org>
    Reviewed-by: Jeremy Allison <jra@samba.org>

:040000 040000 aa947e4522bd0fb98feb6fda73f40ddfe81fcfee 5e27358a9576f582c47d84b69274c78a6cd77b7a M      source3
Comment 2 Ralph Böhme 2019-09-22 18:24:19 UTC
Thanks, that nails it!

You seems to be hitting bug 14121. Can you redo the test ensuring you have the patch for the bug in-tree?

Comment 3 Kacper 2019-09-22 18:56:41 UTC
I've tried to apply the patch from #14121 however it failed on compile. According to #14121 the fix was included in 4.11-rc4, however I'm on latest 4.11-stable and the regression is still there.

../../source4/torture/smb2/create.c:2106:13: error: redefinition of ‘test_fileid’
 static bool test_fileid(struct torture_context *tctx,
../../source4/torture/smb2/create.c:1908:13: note: previous definition of ‘test_fileid’ was here
 static bool test_fileid(struct torture_context *tctx,
../../source4/torture/smb2/create.c:2359:23: error: redefinition of ‘torture_smb2_fileid_init’
 struct torture_suite *torture_smb2_fileid_init(TALLOC_CTX *ctx)
../../source4/torture/smb2/create.c:2345:23: note: previous definition of ‘torture_smb2_fileid_init’ was here
 struct torture_suite *torture_smb2_fileid_init(TALLOC_CTX *ctx)
Comment 4 Ralph Böhme 2019-09-22 19:07:06 UTC
Can you please share the following:
- smb.conf
- mount command
- network trace
Comment 5 Kacper 2019-09-22 19:24:36 UTC
Created attachment 15481 [details]
network trace
Comment 6 Kacper 2019-09-22 19:24:54 UTC
Created attachment 15482 [details]
Comment 7 Kacper 2019-09-22 19:27:32 UTC
(In reply to Ralph Böhme from comment #4)

The mount command is: mount //localhost/share /tmp/share -o username=Administrator
Comment 8 Ralph Böhme 2019-09-22 21:53:32 UTC
Thanks, that helps to understand the problem! I should have a fix ready within a few days. Stay tuned...
Comment 9 Ralph Böhme 2019-09-23 23:43:52 UTC
Created attachment 15486 [details]
WIP patch for master

Can you test the attached patch?
Comment 10 Kacper 2019-09-24 08:14:31 UTC
(In reply to Ralph Böhme from comment #9)
I've tested the patch and it seemed have fixed the bug :)
Comment 12 Ralph Böhme 2019-10-02 09:49:02 UTC
Created attachment 15505 [details]
Patch for 4.11 cherry-picked from master
Comment 13 Jeremy Allison 2019-10-02 23:55:18 UTC
Comment on attachment 15505 [details]
Patch for 4.11 cherry-picked from master

Comment 14 Jeremy Allison 2019-10-02 23:56:01 UTC
Re-assigning to Karolin for inclusion in 4.11.next.
Comment 15 Karolin Seeger 2019-10-16 11:07:48 UTC
(In reply to Jeremy Allison from comment #14)
Pushed to autobuild-v4-11-test.
Comment 16 Karolin Seeger 2019-10-17 07:27:58 UTC
(In reply to Karolin Seeger from comment #15)
Pushed to v4-11-test.
Closing out bug report.