[Samba] silent data loss with samba and lack of rename() locking

[Michael Tokarev]

19.03.2024 14:24, Michael Tokarev via samba wrote:
> Just want to emphasize this particular bug, since it is serious enough,
> even if apparently this mode isn't used often.
> 
> Having a samba server S, a windows client W and a linux client L,
> and two files on S, file1 and file2.
> 
> 1. On W, mount the share and lock file1
>     (eg. if it is executable, start it).
> 
> 2. On L, mount the share and try to remove (rm) file1.
>     This will hang because the file is locked by W.
>     Interrupt rm.
> 
> 3. On L, rename file2 on top of (busy, locked) file1.
>     This will works just fine.
>     At this point, we have file2 under name file1.
> 
> 4. On W, unlock the file
> 
> 5. Watch the file (which is file2 now) got removed.
> 
> 
> So, we tried to remove file1, but in the end we got
> BOTH files deleted, losing file2 unexpectedly.

This is https://bugzilla.samba.org/show_bug.cgi?id=15608 fwiw.

I've now set up something which ALMOST allows me to update files
served by samba from a linux system.

I created a windows virtual machine on the samba server,
mounted the share from this samba server inside, and run
rsync in the VM.  And access this rsync daemon from the
linux machine in order to update files.

So, while samba claims it is an "interoperability suite", so
far it provides no interoperability, it *requires* a windows
machine even to update files on the server itself.

It's a bit idiotic, but at least it seems to be working without
losing data.

/mjt

-- 
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt