Jean-Baptiste Denis
2025-Aug-01 08:16 UTC
[Samba] Sequence of actions resulting in data loss
FWIW, this is the smbd debug output while running the reproducer script: https://gist.github.com/jbd/7ca2f17628029f2e6e6e4b9089bb1bf7 I can spot the client opening X.sh with delete-on-close flag. Jean-Baptiste On 8/1/25 10:04 AM, Jean-Baptiste Denis wrote:> >> But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part > >> of a larger? changeset that went into 4.22. > >> > >> https://bugzilla.samba.org/show_bug.cgi?id=15608 > > > > This looks very similar indeed, I'll have a further look. > > I just checked with a debian running 4.22: > > $ sudo smbd --version > Version 4.22.3-Debian-4.22.3+dfsg-4 > > The problem still occurs (ie the file is deleted in the end, I'm not talking about the expected STATUS_ACCESS_DENIED > from the specs). > > Is this reasonable to think that the problem could be in the cifs client code ? The fact that is occurs across a range > of NAS (I think Isilon is using Likewise) and a windows server makes me think of that. > > I don't know what should be the correct behavior from an implementation point of view, but having a file deleted at the > end seems quite brutal to me. I think this should not happen. > > Do you have any suggestions ? > > RedHat support is still focusing on the initial application that triggered this problem although I gave them the same > behavior reproducer. > > Thank you for your help. > > Jean-Baptiste > > On 7/30/25 6:11 PM, Jean-Baptiste Denis wrote: >> ?> what it your expectation? Running this on a local filesystem gives: >> ?> >> ?> $ bash reproducer.sh >> ?> new content >> >> That's a good question. I would say that I expect the X.sh file not being deleted after the script is finished. >> >> ?> In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate >> ?> that this must fail with STATUS_ACCESS_DENIED. >> >> Thank you for the clarification. >> >> ?> But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger >> changeset >> ?> that went into 4.22. >> ?> >> ?> https://bugzilla.samba.org/show_bug.cgi?id=15608 >> >> This looks very similar indeed, I'll have a further look. >> >> Thank you. >> >> Jean-Baptiste >> >> >> On 7/30/25 2:46 PM, Ralph Boehme wrote: >>> On 7/30/25 1:29 PM, Jean-Baptiste Denis via samba wrote: >>>> I've got a cifs mount and some operations result in data loss. I'd like to know if this is expected or not. >>> >>> what it your expectation? Running this on a local filesystem gives: >>> >>> $ bash reproducer.sh >>> new content >>> >>> In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs >>> mandate that this must fail with STATUS_ACCESS_DENIED. >>> >>> But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger >>> changeset that went into 4.22. >>> >>> https://bugzilla.samba.org/show_bug.cgi?id=15608 >>> >>> Cheers! >>> -slow >>> >> >
On 8/1/25 10:16 AM, Jean-Baptiste Denis wrote:> FWIW, this is the smbd debug output while running the reproducer script: > > https://gist.github.com/jbd/7ca2f17628029f2e6e6e4b9089bb1bf7can you also share a network trace, that is quicker to analyze to understand what's going on at a higher level. Cheers! -slow -- SerNet Samba Team Lead https://sernet.de/ Samba Team Member https://samba.org/ Samba Support and Dev https://samba.plus/services/ SAMBA+ packages https://samba.plus/products/samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20250801/8ca5accb/OpenPGP_signature.sig>