Debian "in place" upgrade did not go well.

I'm pretty sure I know what the Webmin issue is. Unfortunately I'm not sure about the samba share issue, but I'll share what I can think of below.

FWIW technically we don't officially support "Debian in-place upgrades". But I always try to give "best effort" TurnKey support regardless. Plus even though others haven't reported them, there may also be (likely different) issues doing a TKLBAM data migration too.

First to webmin. Sorry I didn't think of it previously, but we made some significant changes to webmin and webshell in v18.x. I'm certain that the Webmin issue is related to those changes. As noted in the changelog, we removed the stunnel reverse proxy, as well as removing webshell altogether. By default v18.x, Webmin now listens directly on port 12321 and Webmin includes a shell - so no need for a separate web based shell.

Unfortunately I forget exactly what is needed to get it going again when doing an "in place" upgrade. I thought that I had documented it somewhere but I can't find it ATM :( Anyway, here's a rundown of (what I think) should update it to match our current config and get Webmin going again - or at least close...:

• Remove shellinabox (the old webshell) and stunnel (the reverse proxy previously used by webshell and webmin for SSL/TLS termination):

  apt remove shellinabox stunnel4

• Install webmin-xterm (webmin terminal - webshell replacement)

  apt install webmin-xterm

• Adjust Webmin config (/etc/webmin/miniserv.conf) - see a full config file below, but OTTOMH these are the particularly import bits:
  • enable TLS - update/add all lines from config below that include "tls" or "ssl" - including the cipher_list.
  • ensure that it's hosted and listening on port 12321 - "listen" and "port"
  • ensure that it's not bound to localhost (127.0.0.1) - IIRC the old conf was "bind=127.0.0.1" but that line is no longer required.
• once webmin conf is updated; restart webmin

  systemctl restart webmin

Hopefully that should get webmin going again... Please post back if it doesn't, and include some info. The contents of /etc/webmin/miniserv.conf and some status & log info. This should probably be enough:

cat /etc/webmin/miniserv.conf
systemctl restart webmin
systemctl status webmin
journalctl -u webmin --since "5 minutes ago"

Here's the content of a v18.x webmin mini server config I have handy. The file is /etc/webmin/miniserv.conf - FWIW I'm a CLI guy and don't use Webmin myself, but hopefully that should be enough for your purposes:

port=12321
root=/usr/share/webmin
mimetypes=/usr/share/webmin/mime.types
addtype_cgi=internal/cgi
realm=Webmin Server
logfile=/var/webmin/miniserv.log
errorlog=/var/webmin/miniserv.error
pidfile=/var/webmin/miniserv.pid
logtime=168
ssl=1
no_ssl2=1
no_ssl3=1
ssl_honorcipherorder=1
no_sslcompression=1
env_WEBMIN_CONFIG=/etc/webmin
env_WEBMIN_VAR=/var/webmin
atboot=0
logout=/etc/webmin/logout-flag
listen=12321
denyfile=\.pl$
log=1
blockhost_failures=5
blockhost_time=60
syslog=1
ipv6=1
session=1
premodules=WebminCore
server=MiniServ/2.105
userfile=/etc/webmin/miniserv.users
keyfile=/etc/ssl/private/cert.pem
passwd_file=/etc/shadow
passwd_uindex=0
passwd_pindex=1
passwd_cindex=2
passwd_mindex=4
passwd_mode=0
passdelay=1
cipher_list_def=0
login_script=/etc/webmin/login.pl
logout_script=/etc/webmin/logout.pl
failed_script=/etc/webmin/failed.pl
sudo=1
certfile=
error_handler_401=401.cgi
error_handler_404=404.cgi
error_handler_403=403.cgi
nolog=\/stats\.cgi\?xhr\-stats\=general
no_tls1=1
no_tls1_1=1
no_tls1_2=
extracas=
ssl_hsts=0
preroot=authentic-theme
ssl_cipher_list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

I notice that the certfile isn't noted there, but if that causes issues, the default TurnKey one (/etc/ssl/private/cert.pem) should work fine.

Re the samba share stuff, TBH I'm not really sure.

It sounds like you kept your default config when doing the initial upgrade so I'm assuming that you did that too when you did the full upgrade.

I don't recall what - if any - config changes we did for v18.x, but you can check by cross referencing the default v18.x samba conf.

Beyond that, double check that the samba service/s are running - main service is 'smb' and if anything accesses shares via NETBIOS name (only old Windows or other samba servers) also check the 'nmb' service. Perhaps try restarting them too? Definitely if/when you change config.

If it's still not working after that, then check the journal and samba logs for errors or anything else that looks relevant..

Please post back with any/all progress you have. If you can get either/both going again, please share with what you did. If you continue to have issues with either/both then share some more info as noted above.

Good luck.

Firstly, you are most welcome for the assistance. That's what these forums are for. :)

We want TurnKey to work as well as possible for all users, so knowing where there are pain and friction points is useful. Having this discussion here, will also hopefully be useful for others that hit this (or similar) issues in the future. As I said, technically we don't support "in place" upgrade, but we also don't want it to be impossible and/or too painful for those that do want to do that.

If you'd like to continue trying to get the upgrade working, it's worth double checking your smb.conf against the v18.x default smb.conf. Seeing as smb.service runs ok when manually started, it seems highly unlikely that there is anything problematic in there, but worth a look IMO.

Regarding the smb service not autostarting at boot, it might be worth double checking that smb.service is enabled and that samba.service isn't enabled. FYI the samba service is the one that is used when hosting/connecting to an AD (active directory) domain, the smb service is for "simple" filesharing. The samba and smb services conflict so if samba.service is enabled, when it starts it will stop smb even if that is enabled too. To make sure that's how it is, you could try this:

systemctl disable samba
systemctl enable smb

Re webmin, your extra info (still complaining about dependency on stunnel) reminded me that the way we had stunnel set up was webmin depending on the stunnel service. We did that with a service config override. So removing that should hopefully be the (last) config update needed to get that working. Apologies I didn't think of that previously. To remove the override and just use only the new default webmin.service:

rm -r /etc/systemd/system/webmin.service.d
systemctl start webmin

If webmin and/or smb services still continue to not work as expected; please share the output of the following. If one is now working but not the other, you can excluded the relevant service(s) from these 2 commands:

systemctl status webmin smb samba
systemctl cat webmin smb

One more thing I've remembered. IIRC v17.x didn't have the "wsdd" (Web Service Discovery Daemon) package preinstalled. It's not a requirement, but if you want your fileserver to show up in the "Network" section of Windows Explorer on Win PCs on your LAN then you'll want that installed.

If you'd prefer to start again with v18.x Fileserver, the primary things that you'll want to migrate are the share config from your current server - and obviously the shared files.

Either way, good luck and let us know how it goes.

Ok so after another try.
I did what you mentinoned, removed shellinabox stunnel4 and installed webmin-xterm.
but restarting webmin complains that it is missing a dependency, from what I understand on journtalctl -xe it is stunnel.
redarding samba, after the upgrade the LXC was starting without smb service started even though it is enabled to start on boot. after a systemctl start smb and wait around 1 minute for it to finally start I could access the share on windows.
Second reboot, the same behaviour. Samba not starting.
So I'm almost giving up doing this upgrade.
I wonder if starting from scratch on V18 would be easier.
Thank you for all your help though. You have been very helpfull.