I just created a brand new fileserver appliance on the HUB to compare differences between 13 and 14. But Webmin is not starting correctly. I will leave the instance running at testnewtklfs.tklapp.com 

ssh is coming up. I can give you a password to login and check what is going on.


Also launced new FS appliance v13, and surprise: Webmin not working either.

Must be something in the HUB. My wild guess is that is has something to do with elastic storage. I needed that for the big restore I was testing. Now I have a feeling it is expecting big storage for every new instance. I got this in the console messages.

Mounting local filesystems...mount: special device /dev/xvda2 does not exist

I dont have enought knowledge of Linux or the workings of the HUB/AWS to solve this :(

v13 appliciance is located at: testfs13.tklapp.com 

Jeremy Davis's picture

Are you sure that you were using the right url?

It works fine for me: https://testnewtklfs.tklapp.com:12321/

Also your old appliance seems to be working too: https://testfs13.tklapp.com:12321/

My guess is that you forgot to add the "https://" at the start (http connection will fail even if you have the port right). I also checked Webshell while I was at it (just in case that was what you meant) but that works too...

I had been trying for an hour or so, before posting here. I am sure I used https, not http.

Now I can login to Webmin just fine. Yesterday it would not even give me the login screen, just a server timeout.

Will try again today with a fresh new instance, and let you know.

[edit] Just installed fresh instance from scratch, and it is working perfectly. Only difference is I am working at a different location now. My next guess is a firewall / NAT issue. To test that hypothese I will go back to yesterdays location and see what happens... [to be continued]

[edit2] At my office now... Not working v14. The firewal is not logging anything strange. Can it have anything to do with routing and stunnel mapping 12321 to 10000 and webmin miniserv listening on either 12321 or 10000? Argh, my head is spinning. Could it be something with NAT / masquerading? The restore I did was from a v13 appliance to a v14 appliance. Maybe the webmin configs are overwritten by the restore??

This is gonna look like an involuntary crash course in Linux fundamentals III

[edit3] back home. Firing up my laptop, going to the hub. URL to appliance doesnt work (slow DNS propagation?) but the ip does. https://[ip address]:12321, et voila webmin!

Jeremy Davis's picture

I have found HubDNS slow to update sometimes. The culprit was my ISPs DNS caching overriding the Hub's TTL settings. I switched to google ( and that made things heaps better (generally updates within ~5 mins).


When testing at the office, I have 2 Webmin servers active at the same subnet. Different ip's, but same port 12321. Could that cause problems?

That would explain why I cannot access the new appliance I am testing, but not the appliance deployed on the HUB.

Digging in my router / firewall documentation. It is a Mikrotik router, firewall is very much iptables.

looked at my firewall with a microscope, might have found something. Will have to test to make sure

[to be continued]

[edit] Seems I forgot to add the [in-interface] in my firewall rule. So every connection to a port 12321 would be validated and forwarded by this rule... Now I can access 2nd webmin server on my subnet and no more problems connecting to webmin servers on the HUB.

add action=dst-nat chain=dstnat comment="port forward Webmin on Bridge" \
    dst-port=12321 in-interface=ether1-gateway protocol=tcp to-addresses=\ to-ports=12321

[edit2] After restoring v13 backup to my new v14 Fileserver appliance, I cannot access webmin on the new one anymore. Syslog gives me this:

Oct  3 15:19:27 fileserver stunnel: LOG5[1716]: Service [webmin] accepted connection from
Oct  3 15:19:27 fileserver stunnel: LOG3[1716]: s_connect: connect Connection refused (111)
Oct  3 15:19:27 fileserver stunnel: LOG5[1716]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Oct  3 15:19:27 fileserver stunnel: LOG5[1717]: Service [webmin] accepted connection from
Oct  3 15:19:27 fileserver stunnel: LOG3[1717]: s_connect: connect Connection refused (111)
Oct  3 15:19:27 fileserver stunnel: LOG5[1717]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

[edit3] /etc/webmin/miniserv.conf files are absolutely different between v13 and v14. Main differences I already spotted are:

  • port=12321 and listen=12321 ==> both 10000
  • v14 has extra line bind=
  • keyfile=/etc/ssl/certs/cert.pem ==> keyfile=/etc/webmin/miniserv.pem
  • some other differences in blockhost and blockuser (probably my specific changes)
  • ...

Can I just change the file or copy the v14 config file back?

[edit4] adapting /etc/webmin/miniserv.conf solved the problem, and now I can login to webmin again. Next problem: my Samba users do not exist anymore on the v14 appliance...

The users exist as Linux users, so I can convert them to Samba users again. This does not set the Samba password to be the same as the Linux password. Is the libpam-smbpass package removed from the appliance?

Jeremy Davis's picture

In v14.0 Webmin is proxied via stunnel. So Webmin listens on it's default port (10000) but only for local connections (hence bind= - = localhost). stunnel listens publicly on 12321 and proxies connections to localhost:10000 (where Webmin is listening).

v14.0 shouldn't need a keyfile as it isn't doing an TLS connections (it only connects locally and stunnel handles the TLS).

In v13.0 Webmin served itself directly on 12321 (instead of default 10000).

As for your Samba users not being included, that doesn't sound how it should be. Is all the data there in the right places? Also perhaps it is meant to do that as the fileserver appliance it should auto convert Linux users to Samba users (and sync passwords). Perhaps the job that does that just hasn't run yet? You could manually do that from within Webmin but TBH I'd be interested in digging a bit deeper. I'm not sure why it doesn't include them? If you wanted you could do some detective work on your backup to try to make it better/smoother...

After I restored the v13 backup to the brand new v14 appliance the webmin config was broken by the /etc/webmin/miniserv.conf being overwritten from the backup. Copying back the default from a fresh v14 appliance solved my problem.

I noticed only 2 Samba users were created: 0-root, and 1000-[username]. No idea why user 1000 was created and others were not. Using a script, generously provided to my by a Linux guru, I checked with rsync for missing data files after the restore. Seems pretty complete ;)

I used the Samba 'convert users' function to re-create the other samba users. Then I tried to logon to the Samba server with one of those users, no luck. Checking the samba logs, it showed authorization failure.

check_ntlm_password:  Authentication for user [username] -> [username] FAILED with error NT_STATUS_WRONG_PASSWORD
[2015/10/04 21:13:22.995426,  2] ../auth/gensec/spnego.c:743(gensec_spnego_server_negTokenTarg)

Fiddling around a bit with smbclients, manualy updated the Samba password for this user, and could login to samba again. At Linux level the passwords were the still okay after the restore, but not for Samba. I looked a little bit into password synchronization. It appears a package with the name libpam-smbpass is responsible tor the syn. In Webmin I searched for this in the installed packages and got this: Package is no longer installed.

Trying to install the package gives: libpam-smbpass is already the newest version.

Should I try to remove and re-install the package?

I guess I should wait a bit before I replace my live v13 fileserver with v14...

Jeremy Davis's picture

Have a look what (if any) version of libpam-smbpass is installed (Webmin should theoretically work for this but it sounds like you're getting mixed messages so go commandline...)
apt-get update
apt-cache policy libpam-smbpass
The second command will give you an output like this: (I don't have it installed - if ).
  Installed: (none)
  Candidate: 2:4.1.17+dfsg-2
  Version table:
     2:4.1.17+dfsg-2 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
If it's not installed (or the "Installed" version doesn't match the "Candidate" version) then install update:
apt-get install libpam-smbpass
If it reports that it is installed (and at the latest version) then we may need to dig into the logs a bit more. I should probably fire up a fileserver locally too so I don't lead you astray...

This is the output:

jacob@bridge2 ~$ sudo apt-cache policy libpam-smbpass
  Installed: 2:4.1.17+dfsg-2
  Candidate: 2:4.1.17+dfsg-2
  Version table:
 *** 2:4.1.17+dfsg-2 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

So Webmin is clearly not reporting correctly. Where to dig now?

Jeremy Davis's picture

Perhaps the file layout has changed so Webmin can't see it anymore?

So to recap you have all your user accounts still; just they are only Linux users not Samba users? Is that right? If so I know it's not ideal but p[erhaps you could try manually clicking the "sync Linux users to Samba users" button in Samba settings in Webmin. TBH I have no idea what the command is to run that from the commandline... What (if anything) happens?

Correct. I still have all my Linux users, even old ones that were already disabled. Only 2 users were visible (converted to) in Samba:root (0) and [username] (1000). The last one is also the only user allowed to ssh. Another 15-20 samba users were not converted to samba on the new v14 appliance.

I already manually converted (a subselection) of Linux users to Samba users, using the Webmin environment. Now they exist as Samba users. But the Linux password is not sync'ed as Samba password. For one user I knew the password and manually updated the Samba password in Webmin. This user now can access the Samba shares and files again.

The problem is two steps:

  1. Existing Samba users on the old server(v13) were not RE-created after restore on the new server(v14)
  2. After manually converting Linux users to Samba users again, the Linux password is not sync'ed to the Samba password. Webmin reports libpam-smbpass is no longer installed, but cli shows it is. 

Any suggestions for next steps? Does this affect the adviced approach and/or scripts for upgrading the TKL Fileserver appliance to Jessie? 

Hi Jeremy, still having problems with Webmin. Webmin is reporting packages are no longer installed, while I am sure the are indeed installed. Should I open a new thread?

I am thinking about testing the Linux / Samba users, using 4 scenarios creating new users.

  Linux first Samba first
Webmin user1 user2
Cli user3 user4

So for user1, I will first create it in Linux and then convert to Samba, using Webmin

I hope this will show if Webmin and its mgt scripts are the issue.

[edit] the results are in:

user1, Webmin, Linux 1st
Create user in other modules:true
user1 is created in Samba
smbclient login with -U user1 works

user2, Webmin, Samba 1st
not a Webmin function

user3, cls, Linux 1st
useradd user3 
not yet created in Samba
smbpasswd –a user3
Now created in Samba
smbclient login with -U user3 works

user4, cli, Samba 1st 
smbpasswd -a user4
New SMB password:
Retype new SMB password:
Added user user4.
Linux user4 is created, no home directory or shell, inactive, primary group=users
Also created in Samba
smbclient login with -U user4 works

Everything seems to work as it should. Even with webmin telling libpam-smbpass is no longer installed.

The errors and unexpected behaviour are somehow related to the proces of restoring a v13 backup to new v14 appliance, but where to look?


That libpam-smbpass thing kept nagging me. So I decided to try and re-install the package. That gave an error. Apparently there is two password files with the name passdb.tdb on my system now.

jacob@bridge2 ~$ sudo apt-get install --reinstall libpam-smbpass
[sudo] password for jacob: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 112 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://http.debian.net/debian/ jessie/main libpam-smbpass amd64 2:4.1.17+dfsg-2 [112 kB]
Fetched 112 kB in 1s (95.3 kB/s)         
[master f6239d9] saving uncommitted changes in /etc prior to apt run
 9 files changed, 59 insertions(+), 23 deletions(-)
 rewrite webmin/system-status/info (100%)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 40369 files and directories currently installed.)
Preparing to unpack .../libpam-smbpass_2%3a4.1.17+dfsg-2_amd64.deb ...
passdb.tdb exists in /var/lib/samba and /var/lib/samba/private, aborting libpam-smbpass preinst
rename one of them to allow the install/upgrade to continue
total 4404
drwxr-xr-x  6 root root          4096 Oct  3 15:04 .
drwxr-xr-x 43 root root          4096 Oct  3 14:37 ..
-rw-------  1 root root        421888 Sep  3 07:03 account_policy.tdb
-rw-------  1 root root        110592 Jan  8  2014 group_mapping.ldb.replaced
-rw-------  1 root root        430080 Sep 15 09:58 group_mapping.tdb
-rw-------  1 root root          8192 Jan 29  2013 ntdrivers.tdb.bak
-rw-------  1 root root           696 Jan 29  2013 ntforms.tdb.bak
-rw-------  1 root root          8192 Jan 29  2013 ntprinters.tdb.bak
-rw-------  1 root root         36864 Oct  2 18:06 passdb.tdb
drwxr-xr-x  2 root root          4096 Oct  3 14:53 perfmon
drwxr-xr-x 10 root root          4096 Sep  3 06:57 printers
drwxr-xr-x  2 root root          4096 Sep  3 07:03 private
-rw-------  1 root root       3334144 Oct  3 15:05 registry.tdb
-rw-------  1 root root         45056 Jan 29  2013 secrets.tdb
-rw-------  1 root root         36864 Jun 30  2014 share_info.tdb
-rw-------  1 root root         36864 Jan  6  2014 share_info.tdb.bak
drwxrwx--T  2 root sambashare    4096 Sep  3 07:00 usershares
-rw-r--r--  1 root root           220 Oct  3 15:04 wins.dat
-rw-------  1 root root          8192 Mar 27  2013 wins.tdb

total 840
drwxr-xr-x 2 root root   4096 Sep  3 07:03 .
drwxr-xr-x 6 root root   4096 Oct  3 15:04 ..
-rw------- 1 root root 421888 Oct  8 10:51 passdb.tdb
-rw------- 1 root root 430080 Oct  4 12:28 secrets.tdb
dpkg: error processing archive /var/cache/apt/archives/libpam-smbpass_2%3a4.1.17+dfsg-2_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
Counting objects: 8969, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2845/2845), done.
Writing objects: 100% (8969/8969), done.
Total 8969 (delta 5420), reused 8935 (delta 5398)
E: Sub-process /usr/bin/dpkg returned an error code (1)
jacob@bridge2 ~$ 

Can this be caused by the upgrade to v14 and restore v13 data process? How should I proceed now? (Im digging deeper in Linux than I've ever done before, so feeling a bit unsure)

[edit] I just verified. My 'old' v13 appliance has the file in /var/lib/samba/passdb.tdb

a fresh v14 appliance uses /var/lib/samba/private/passdb.tdl

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726472 indicates this may cause the kinds of problems we are running into. But to be honest, I do not understand all the expert talk they are using... Wich one of the passwd files should I use? Delete the other one?? Or do I need to start from fresh, and make some changes to the appliance, before I restore my v13 data??

Jeremy Davis's picture

Awesome work on this one Jacob. Apologies that I haven't helped much over the last few days...

I have been battling with the VM builds of the v14.0 appliances. I expected it to be fairly straight forward but by midweek I realised that it was going to be much trickier than I imagined. So I locked myself away to try to resolve that. I had a major breakthrough late last week so very close now. But I digress; back top your issue...

I must say, great detective work! It sounds like you have essentially resolved the issue! Yay! :)

So I suggest that you copy the 'old' secrets.tdb & passdb.tdb from /var/lib/samba/ to the new location of /var/lib/samba/private/
I.e. on your v14.0 appliance try this:

cd /var/lib/samba/private
mv secrets.tdb secrets.tdb.orig
mv passdb.tdb passdb.tdb.orig
mv ../secrets.tdb .
mv ../passdb.tdb .

Then restart samba and see what happens then... From my reading of the bug report you link to; that should fix it! Fingers crossed...

If that all works then you could just take a new backup of your v14.0 appliance. Although it may pay to keep your v13.0 appliance backup for a little while until you are sure that you no longer need it...

Does not seem to solve everything. Perhaps I already tested and changed too much.

I will restart with a fresh v14 appliance, do the restore again, and then process the changes needed to get Webmin and Samba working again. (is that something that can be automated for all other fileserver apl. users who still have to upgrade??)

Jeremy Davis's picture

Once we have confirmed a fix we can look at developing a tklbam hook. Just having a fix documented will be a fantastic start though! :)

For your purposes once you have it sorted and do a backup of your new server then you won't need to worry about it.

These are the steps I performed to test the fileserver upgrade, and the additional steps needed to get Webmin and Samba behaving.

  • I created a fresh v14 fs appliance on AWS and made sure all packages were up to date. Webmin is accessable and there is only 1 Samba user, root
  • Made a copy of /etc/webin/miniserv.conf
  • Then I restored my v13 data on the new appliance, using tklbam (and went for coffee).
  • Reboot. Webmin does not respond, but ssh does
  • Changed /etc/webmin/minserv.conf with only these 3 changes: port=10000, listen=10000, bind=
  • Reboot. Webmin still not working, giving the message "running in ssl, try https://localhost:10000"
  • Copied the default v14 /etc/webmin/miniserv.conf back (instead of the v13 that got restore in its place)
  • Reboot. Webmin working as expected.
  • Now getting Samba to work with my old users again: simply copy paste the commands you wrote 3 posts up.
  • cd /var/lib/samba/private
    mv secrets.tdb secrets.tdb.orig
    mv passdb.tdb passdb.tdb.orig
    mv ../secrets.tdb .
    mv ../passdb.tdb .​
  • Reboot. And Samba knows all my users again. Tested different users with smbclient.

I know I don't need to reboot so often, restarting services should do. But I wanted to be sure I was not missing one or two. 

I also have compared the v13 and v14 miniserv.conf files. There are more diffences than just the 3 lines I changed. Replacing works for me, but you may want to dig deeper. Sorting both files and comparing with diff:

< bind=
< blockhost_failures=5
< blockhost_time=60
< cipher_list_def=1
> blockhost_failures=3
> blockhost_time=600
> blocklock=
> blockuser_failures=
> blockuser_time=
< inetd_ssl=1
< ipv6=0
< keyfile=/etc/webmin/miniserv.pem
< listen=10000
> keyfile=/etc/ssl/certs/cert.pem
> listen=12321
> logclear=0
> logclf=0
> loghost=0
> login_script=/etc/webmin/login.pl
> logout_script=/etc/webmin/logout.pl
> logouttime=
< no_resolv_myname=0
< no_ssl2=1
< no_ssl3=1
> no_pam=0
> pam_conv=
> pam_end=
< port=10000
> port=12321
< preroot=theme-stressfree
< server=MiniServ/1.760
> server=MiniServ/1.630
< sockets=
< ssl=
> ssl=1
> utmp=

The new use of stunnel in v14 will break more appliances. I hope this detective work does help a tiny bit in creating an automated fix for all the upgraders out there :D

Jeremy Davis's picture

Great work and fantastic documentation.

I guarantee it will be helpful for other users so thanks heaps for taking the time to write it all up! :)

I took a leap of faith (with enough backups and a fallback scenario) and converted our production fileserver to v14 and the restored the v13 data back to it. Using all the steps I described I got it up and running during the weekend. On monday our users didn't even notice any difference. Smooth migration I would say.

But... Webmin is seriously messed up (and of course the usual nagging log messages I have to get rid of one-by-one).

$sudo apt-cache policy libpam-smbpass 
  Installed: 2:4.1.17+dfsg-2
  Candidate: 2:4.1.17+dfsg-2
  Version table:
 *** 2:4.1.17+dfsg-2 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

I would say it is installed. But in Webmin => System => Software Packages, Installed Packages, search for package "libpam-smbpass" gives:


This is not just with libpam-smbpass, also with postfix. Postfix doesnt even show up in the Webmin menu under servers...

When in Webmin I look at the package tree of installed packages, I tried the first 20 or so packages, they all give the message: package is no longer installed.

I have the feeling Webmin is keeping its own list of packages, and it somehow got out of sync with reality. Is there any way to 'rebuild' it?


I found a discussion about Webmin not seeing installed packages here: http://ehc.ac/p/webadmin/discussion/600155/thread/ddaa8ed6/ 

It recommends to execute this command:

dpkg --get-selections \* | awk '{print $1}' | xargs -l1 aptitude reinstall​

But I don't understand 100% what it does. And I prefer not to test on my production server. What would you do?

Jeremy Davis's picture

So I'm not really sure why Webmin can't find that software. Perhaps it's worth having a look in the logs? Although I don't recall where the webmin logs go to? Maybe /var/log? Perhaps it has more info that might hint at the actual cause?

FWIW that command won't work OOTB on TurnKey. you'll need to install aptitude first. Although IMO that's fairly heavy handed and I probably wouldn't do it - certainly not on a production server unless it was a last resort!

FYI it is basically 3 commands rolled into one (the '|' - called a pipe; forwards the output of the prior command to the next command). So "dpkg --get-selections \*" basically lists all the packages installed. "awk '{print $1}'" removes everything but the first part of the output (so you just have a long list of packages). Then the "xargs -l1 aptitude reinstall​" interates through the list of installed packages and reinstalls them all...! So essentially it reinstalls everything!

Something to check re Webmin postfix is make sure that the webmin-postfix module is installed. IIRC correctly that's exactly what it's called so you can check with "apt-cache policy webmin-postfix" and if it's not installed then you can install it with "apt-gt install webmin-postfix".

Regarding the issues with the Samba webmin module you could try removing it and reinstalling it:

apt-get purge webmin-samba
apt-get update
apt-get install webmin-samba

I will not test on my prod server. So today I decided to create a fresh instance on AWS. My idea was creating a clean instance, and then instead of restoring from TKLBAM, migrating all users and then the data and configs for Samba.

Directly after getting it up, before making any modification or configuration, I checked the installed packages in Webmin. And guess what: Error, Package is no longer installed. 

For every package I checked, including Samba, Postfix and Webmin it self. I expected a clean image to run flawless, but that is not the case.

Perhaps I should downgrade back to TKL v13?

Jeremy Davis's picture

Prompted by your most recent post I thought I better have a deeper look into this... As it turns out it appears to be pretty simple...

When you search for or install software from the commandline you use the "apt-get update" command to update the local database of available packages prior to searching or installing. It seems that Webmin leverages the commandline tools for it's built in package management. So it can't work out what packages are installed until this update is run.

From the commandline "apt-get update" should fix it; or from within Webmin click the (IMO poorly named) "Upgrade Now" button right at the bottom of the Software Packages page (Webmin => System => Software Packages).

Let me know how it goes...

FYI I didn't actually test the Fileserver appliance; but I did confirm that postfix is visible as installed in Webmin on Core (and Fileserver inherits both Webmin and Postfix from Core so if it works in Core then it should work everywhere).

Also assuming that I'm right; then this should not be an issue if you install security updates when you first launch (it will run apt-get update as part of the process) or if you wait 24 hours (the auto security updates also run apt-get update as part of the process). That may also explain to me why nop one else has mentioned this issue.

Just restarted the stopped instance. First tried the "upgrade now" from webmin. That did not work.

Then logged in as root and did the "apt-get update" from cli. Webmin still shows basic packages as "no longer installed"

Postfix is installed and visible from the Webmin-Servers menu. (But not as installed package).

I will keep the instance running for 24 hrs now. See if that makes any difference.

Jeremy Davis's picture

That is super weird. TBH I didn't actually check the fileserver appliance specifically (my bad) but did check a number of others and that seemed to resolve it. I figured that as postfix is in all servers that behaviour should be consistent.

However it's clear that I need to properly test it on the Fileserver appliance; and perhaps even do a migration so as to make sure that I can reproduce the issue first.

Perhaps there is a bug in Webmin related to the switch from Samba3 (TurnKey v13.0/Debian Wheezy) to Samba4 (TurnKey v14.0/Debian Jessie)? A quic google didn't bring any info though so perhaps not... Perhaps there is something being included in the TKLBAM backup (related to Webmin config) that shouldn't be (something overwriting the newer version of Webmin config included in v14.0)?

Jeremy, my last test is a clean fileserver v14 instance via the Hub. Completely standard T1.micro, but Root filesystem size changed to 100 GB. No configuration or modifications. No extra installs. Only applied security updates. I did not restore anything with TKLBAM, so this should be a lot easier to reproduce for anyone else. It has Postfix, also in the server menu item (that got messed up in earlier tests, because of my restore, old srv had no postfix so it got removed with the restore).

But when I go to system - software packages, top right button 'package tree', expand first line A-E, the first 10 or so packages I click on, all give the 'no longer installed' message.

It may be nothing, but I am not well versed in the cli, and use webmin for more than 50% of my sys.adm. tasks. (Gone are the ms-dos 3.20 days, when I knew a lot of hex codes for INT 21h from the top of my head...  It seems I moved from kernel to user space, lol)

One more lead: after a reboot this is in the auth logfile. Notice the webmin auth failure

Nov  6 16:11:20 fileserver sshd[471]: Received signal 15; terminating.
Nov  8 16:08:47 fileserver sshd[470]: Server listening on port 22.
Nov  8 16:08:47 fileserver sshd[470]: Server listening on :: port 22.
Nov  8 16:08:48 fileserver perl: pam_unix(webmin:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=root
Nov  8 16:08:50 fileserver webmin[489]: Webmin starting​
Jeremy Davis's picture

Following your instructions I can easily reproduce this, thanks for the clear steps. TBH I've never used that feature so I'm not really sure what info it should be giving but it certainly isn't giving anything of value ATM... Also it appears to affect all TurnKey appliances; not just fileserver.

I did a quick google and found this thread. Which makes me think that something has changed for Debian Jessie. Perhaps there is a dependency missing? Or maybe there is an undocumented Webmin bug?

To investigate the missing dependency angle, I double checked the Webmin Debian install docs and it appears that there is indeed a dependency missing: apt-show-versions

I thought that seemed really promising so I installed it and restarted Webmin but it appeared to make no difference... :(

Jeremy Davis's picture

I will add building the updated packages to my todo list and maybe that might fix it? TBH I doubt it though...

Also I've posted a bug with Webmin (see here to see if upstream have any ideas.

Jeremy Davis's picture

And the issue remains...

So it's either a Webmin bug or a missing (but undocumented) dependency...

Jeremy Davis's picture

Webmin requires dselect for the info to display in the UI. So install it and update it's list of packages.
apt-get install dselect && dselect update

That works!

So we already solved 3 issues in one forum thread ;)

  1. webmin conf using stunnel (when restoring from v13)
  2. samba users / pw file location
  3. dselect for package mgt in webmin

I hope these solutions all can be automated for future upgraders.


Jeremy Davis's picture

We will apply the workaround for 3 for sure. I will include it in our updated Webmin packages. Webmin have a new release anyway so we will need to build the new packages for that regardless.

However I will discuss this more with upstream. IMO ideally it should gather this information using apt instead (i.e. in a way that doesn't rely on dselect). AFAIK using dselect's package info is that there is a risk that the info will get out of sync (with apt) over time. However I don't know enough about hos dselect and apt interact to be sure...

As for 1 and 2 - I would love to automate those fixes too and it can be done; with TKLBAM hooks. However I haven't used them before so will need to have a play with TKLBAM to work out how that should be done... Until then; just having it documented is a great start.

Thank you so much for your great work on these issues!

Jeremy Davis's picture

I have created 2 "issues" related to your experience on our Issue Tracker:
  • A documentation request/suggestion (#492) to clearly document what needs to be done; and
  • A bug report (#493)
  • Add new comment