This evening I applied the most recent Slackware samba upgrade from 4.15.3 to 4.15.4. All seemed to go well, but upon checking syslog I discovered an entry which indicated the /etc/samba/private/smbpasswd file could not be found. On checking /etc/samba/ it became apparent that the /etc/samba/private/ directory had been completely removed by the upgrade.

Fortunately I was able to restore the missing directory from a nightly mirror. However, I'm fairly sure a package upgrade should not have removed this directory. It certainly hasn't done so in the past.

It may be worth looking into this before the next samba upgrade is pushed out. It's a bit odd, especially since the slackware samba packages don't appear to contain this directory (at least not in versions 4.15.2, 4.15.3 and 4.15.4 which are the only packages I have handy locally right now).

In case it's important, /etc/samba/private/ contained two files at the time of the upgrade: smbpasswd and smbpasswd-backup.

Are the lost files in /var/lib/samba/private? The install script moves files from /etc/samba/private to there and then does rmdir.

A good question... [checks]... yes they are. The timestamp on /var/lib/samba/private/ corresponds to the time of the package upgrade, so it would seem that this is indeed what the install script is doing. Thanks for the tip.

I don't think this unannounced moving of files is a good idea. The problem is that it risks breaking historical setups whose /etc/samba/smb.conf file contains references to files in /etc/samba/private/. By silently moving these, access to samba for clients will be broken without there being any obvious clue as to why. This was the situation in my case. Certainly nothing was flagged as amiss by "/etc/rc.d/rc.samba start".

If these files now must live in /var/lib/samba/private then I can obviously adjust the path in /etc/samba/smb.conf. However, I still think the behaviour of the install script is risky. It will definitely catch users out who have configurations which date from when /etc/samba/private/ was the place to put these things in. At the very least the install script should print an obvious warning to the console when it does this move so users are aware that they may have to change their smb.conf file as a result of the action. It's very rare that an upgradepkg operation would break an existing configuration, so any breakage will come as a surprise (violating the principle of least surprise). I think *something* should be done to at least make the actions of the install script a little more obvious.

The password backend is defined by the passdb backend option; the smb.conf-sample shipped in the package has this config option commented out, so it defaults to the "tdbsam" backend.
Samba looks for the database files (both for tdbsam and for smbpasswd) in the folder defined in private dir.
This option changed its default value from /etc/samba/private/ to /var/lib/samba/private/ before Slackware 14.2, so Pat added (in 14.2) a check in the post-install script that moves these files from the old to the new location.
I guess this is good since it will fix the issue for everyone using the default values provided in the config file shipped in the package, but it can be problematic if you hardcoded the old paths in the config.
I don't see a solution that can be good for both cases.

Here is the samba.Slackbuild from Sept. 18 2018
https://git.slackware.nl/current/tre...7ca0b8f2a38b98
and doinst.sh
So, it's been a long time since Pat preserve user's private conf

I'm certainly not denying that the default might have been changed a while ago, even though I only discovering that this was the case as a result of this discussion.

The installation we're referring to was initially set up years ago (probably close to two decades) and has been progressively updated. That's why the original location was still in active use. I'm not opposed to the changing of the default. What seems suboptimal is the moving of these files by an upgrade without there being any indication that it's happening. Therefore the upgrade breaks a previously running configuration.

If the installation script is going to move files which could be referred to in the working smb.conf, logic dictates that the same installation script should check if there's an existing smb.conf file and fix the path therein to any files that it moves. Slackware doesn't ship a smb.conf file, so the presence of one is a pretty good indication that it's part of a running samba setup which might be expecting the /etc/samba/private/ content to remain in place.

It is good that the contents of /etc/samba/private/ are preserved, even if the location they're moved to is relatively obscure for those of us who had no clue that the default location had changed. However, from my perspective they files had simply disappeared and there was no obvious course of action available. As I said, if this is the way it has to be then I'll cope, but it seems that the behaviour is likely to trip up others in a similar way. Nevertheless, it would be good to warn people that the install script is doing this move so those whose configurations date from years ago have some idea to expect breakage.

It's probably worth mentioning that I've been applying samba updates throughout the life of 14.2 and only shifted to Slackware current at the end of 2021 in preparation for the release of 15.0. This is the first samba upgrade that I've done which has resulted in a move of /etc/samba/private/ content. That is, I've not encountered this behaviour until now.

Maybe this would be a good candidate for inclusion in the CHANGES_AND_HINTS.TXT document.

Just my opinion:
I don't think that using system folders (e.g. /etc or /var/lib ) for custom files, is a good practice
because everything can be overwritten one day.
( Fortunately, Pat has preserved the files if necessary)

Basically, all custom files or conf should land in a "local something" ( /usr/local, rc.local, etc ...)
According to the Samba doc
https://www.samba.org/samba/docs/using_samba/ch09.html
They provide an example with : /usr/local/samba/private ( very Unix BTW )
It seems to me that this is a better way to keep files safe.

edit : there may be parameters I don't know about, which imply certain requirements

Yes, quite possibly. I would support that.

I'm still not sold on the unilateral moving of files though. I'm not aware of any other Slackware package that does it (but of course that isn't to say it doesn't happen - clearly it's easy to miss).