Jean-Baptiste Denis
2025-Aug-01 08:04 UTC
[Samba] Sequence of actions resulting in data loss
>> 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 >> >
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 >>> >> >