[Samba] Weird folders / files after upgrading to Samba 4.20

Fri Jul 26 06:51:48 UTC 2024

Hello,

the problem seemingly does not happen again. Ive got a theory and I'll 
need your expertise to verify or deny it:

In another thread Rowland (or slow?) said, that restarting smbd DOES NOT 
restart all the little process that smbd has spawned. E. g. the RPC 
processes, the individual smb-connection-processes ??

So after an Upgrade (4.19 to 4.20) how does the debian package restart 
samba? Just via systemctl restart smbd? Does that mean that the main 
process (smbd) is running in a new version (4.20), but the helper 
process are still running the code (4.19.x)?

Now if the helper process talks with the main process, its usually 
binary via an socket - and a version mismatch MAY lead to such weird 
problems.

Is this scenario possible or did I misunderstand something? Safe from 
restarting the whole machine - what can I do to make sure that ALL samba 
processes are restarted?

Weve got one fileserver where this problems happened a lot - which I had 
to downgrade to make it work again. Ill try upgrading this server 
tonight incl. restarting the whole machine and we'll see if the problem 
re-emerges.

Any input on this theory of mine is appreciated - thanks!

Regards, Matthias.

Am 19.07.24 um 07:10 schrieb Matthias Kühne | Ellerhold 
Aktiengesellschaft via samba:
> Hello,
>
> my smb.conf is in the first post. Im not setting unix extensions
> explictly, so the default is used (which is yes)? But they are only
> active for smb1 right? I did not activate the smb3 unix extensions.
>
> This also happens for shares that are not mounted by cifs ... e. g. we
> have a share that is used as a hotfolder for a RIP. The workflow is,
> that people mount them in MacOS and put files there. A windows machine
> has these shares mounted and regularly looks for new files ("hotfolder")
> and process them and puts them back. In this workflow no cifs is ever
> used - just MacOS 14 + Win 10. This was the most egregious share we
> had... 170 new weird directories in 24 hours!! Ive deleted them and
> rolled back to 4.19 ... no problems since.
>
> This 2nd share is hard to debug, because the clients are known to create
> problems, thats why I mentioned the first share (where only cifs+samba
> is used) as the main debug target.
>
> So Im guessing the problem is in Samba and not cifs, win10 AND MacOs.
>
> Regards, Matthias.
>
> Am 18.07.24 um 23:23 schrieb Michael Tokarev via samba:
>> 18.07.2024 13:03, Matthias Kühne | Ellerhold Aktiengesellschaft via
>> samba wrote:
>>> Hallo,
>>>
>>> yes this is an "ls -lAh" on the samba fileserver side in the
>>> corresponding directory.
>>>
>>> Downgrading to 4.19 does not remove the weird directories and files. But
>>> it prevents new weird ones being created...
>>>
>>> Looking at the timestamps these seem to be created when (heavy?)
>>> filesystem operations are being done. There is a cronjob that imports
>>> images at 1oo and it runs for around 30 mins. Most of the weird
>>> directory are created between 1:00 and 1:30. This cronjob runs on
>>> another server which has this share mounted via fstab.
>> Aha.  This is much more understandable.
>>
>> Do you have unix extensions enabled on the samba server?
>> 4.20 has some work in this area.  It might be interesting to
>> test 4.20 without unix extensions - if you can afford the
>> same havoc as you already had (which isn't easy for sure).
>>
>> Provided this problem is reproducible, ofc.
>>
>> Maybe you can run your job on another - test - share with 4.20
>> and switch back to 4.19 before real night job is run.
>>
>> This is just a wild guess, anyway.
>>
>>> Nobody else has these problems with Samba 4.20 and debian 12? Any help
>>> is greatly appreciated.
>> cifs mount isn't seen/used often already.  From your description it
>> looks like linux cifs client with samba 4.20 is the bad combination,
>> and it might require some high filesystem load.
>>
>> Thanks,
>>
>> /mjt
>>
-- 
Senior Webentwickler
Datenschutzbeauftragter

Ellerhold Aktiengesellschaft
Friedrich-List-Str. 4
01445 Radebeul

Telefon: +49 (0) 351 83933-61
Web: www.ellerhold.de
Facebook: www.facebook.com/ellerhold.gruppe
Instagram: www.instagram.com/ellerhold.gruppe
LinkedIn: www.linkedin.com/company/ellerhold-gruppe

Amtsgericht Dresden / HRB 23769
Vorstand: Stephan Ellerhold, Maximilian Ellerhold
Vorsitzender des Aufsichtsrates: Frank Ellerhold

---Diese E-Mail und Ihre Anlagen enthalten vertrauliche Mitteilungen. Sollten Sie nicht der beabsichtigte Adressat sein, so bitten wir Sie um Mitteilung und um sofortiges löschen dieser E-Mail und der Anlagen.

Unsere Hinweise zum Datenschutz finden Sie hier: http://www.ellerhold.de/datenschutz/

This e-mail and its attachments are privileged and confidential. If you are not the intended recipient, please notify us and immediately delete this e-mail and its attachments.

You can find our privacy policy here: http://www.ellerhold.de/datenschutz/