Hello!

Samba has provisions to clean up both directories regularly. Is it a major problem for you that we leave sfome files behind? Will they pile up indefinitely, or are they disappearing again when you restart Samba and what a while?

If it is a major showstopper for you, can you try to find out which daemons leave something behind?

With best regards,

Volker Lendecke

... who feels shitty having changed messaging at all. Sockets seemed to be a good idea, but they are just not reliable enough for production.

Thanks Volker.

It's not a blocker for us, I just feel the cleanup is not working properly. It seems the number of files piles up, and won't go away even after shutting down Samba.

I will try to figure out which daemon leaves those files behind when I get a chance.

(In reply to Volker Lendecke from comment #1)

> ... who feels shitty having changed messaging at all. Sockets seemed to be a 
> good idea, but they are just not reliable enough for production.

Nah, don't feel bad. We can't go back to tdb messaging. Making all the code signal-safe is a harder task than fixing socket issues, and I'm not sure we ever had it right.

Files left behind is a very minor issue compared with sig-safe code issues :-).

Hello,

i got this same issue only using smbclient on a proxmox PVE6.1 node (debian buster,  samba-common 2:4.9.5+dfsg-5+deb10u1 ).

Each time proxmox pvestatd service call smbclient, a file and a socket remain on both folder, after 1 month more than 300.000 files has been created and has never been cleaned, no samba service is running on the host to do that in background.

I dont really understand why smbclient is not cleaning file and socket in /var/run/samba/msg.lock/ and ./var/lib/samba/private/msg.sock.

Proxmox bug : https://bugzilla.proxmox.com/show_bug.cgi?id=2333

Here the command executed every 10 seconds by proxmox's pvestatd service :
/usr/bin/smbclient //remote.samba.server/samba-mountpoint -d 0 -m smb3 -U samba-username -A /etc/pve/priv/bpc.cred -c "echo 1 0"

Packages installed on proxmox node : 
dpkg -l |grep samba
ii  samba-common                         2:4.9.5+dfsg-5+deb10u1                          all          common files used by both the Samba server and client
ii  samba-libs:amd64                     2:4.9.5+dfsg-5+deb10u1                          amd64        Samba core libraries

I'm running 3x Samba AD DCs on Ubuntu 22.04, v4.15.13+dfsg-0ubuntu1, and all of them are exhibiting this problem of the files not being cleaned up.

The solution is I run a cron job on each of them, once a day, but stagger them so they each execute with 1hr gap between them. The cron runs this as root:

sudo service samba-ad-dc stop && sudo rm -fv /run/samba/msg.lock/* && sudo service samba-ad-dc start

This is my current temporary work-around, but honestly this really needs to get fixed. What's going on here?

Any chance we can get this tied to some sort of milestone? I still have to use a daily cron work-around to clean these up on all of my AD DCs and I'd rather this already clean itself up. I know it will take time before the fix hits my repos and all that but adding it to a milestone or something like that will move this forward, and to date I'm not really seeing this topic moving forward at all.

Please? :)

(In reply to bloodyiron from comment #6)

What is the samba version of these AD DC,
Bug 15284 & Bug 15282 address msg.sock/msg.lock left behind issue in some cases,
not sure whether address this AD DC case too,
perhaps pick one AD DC and upgrade to latest samba version to see if it works :)

(In reply to Jones Syue from comment #7)

Declared in comment #5, if you need me to clarify on a particular area please let me know. ;P

(In reply to bloodyiron from comment #8)

Sorry for my blunt :)
samba-4.15.13 looks like not including Bug 15284 & Bug 15282,
which address msg.sock/msg.lock left behind issue in some case,
not sure whether address this AD DC case too,
perhaps pick one AD DC and upgrade to latest samba version like:
samba-4.18.10, samba-4.19.6, or samba-4.20.1,
to see if it works: msg.lock/* files are cleaned up automatically.

So these leaking files are now breaking upgrades from Ubuntu 22.04 -> 24.04 for Samba AD Domain Controllers.

With so many files in the /var/lib/samba/private/msg.sock/ folder, this leads to an error in the dpkg config step (when upgrading samba in the OS Distribution upgrade process) whereby the script deletes the contents of "/var/lib/samba/private/msg.sock"

The script relevant is /var/lib/spkg/info/samba.postinst

The error refers to line #208 in this file, which refers to the "rm -f $dir/*" part in the below section of the script:

# remove msg.sock/ directory (moved to /run/samba/)
dir=/var/lib/samba/private/msg.sock
if [ -d $dir -a configure = "$1" ] &&
   dpkg --compare-versions "$2" lt-nl 2:4.16.0+dfsg-7~
then
    rm -f $dir/*
    rmdir $dir
fi

exit 0


====

The error that is produced is:

"/var/lib/dpkg/info/samba.postinst: 208: rm: Argument list too long"

Because there's so much stuff in that folder it overloads the input for "rm".

This bug REALLY should get cleaned up to prevent distribution version upgrades from breaking please!!!

=====

Relevant versions of Samba:
From: 2:4.15.13+dfsg-0ubuntu1.6
To: 2:4.19.5+dfsg-4ubuntu9

====

Can we please get this fixed then?

Hmm I just noticed the msg.sock files I just spoke to are in a completely different folder from what I was referring to previously.

Previously /run/samba/msg.lock/ (which I think is still problematic)

But now also, /var/lib./samba/private/msg.sock/

I'll have to add a cron job to clean up that new msg.sock folder too, argh.

Errors in a Debian postinst script should be reported as a new Debian bug, even if the root cause is here, as that much at least can be addressed with a different syntax (find/xargs).