Perhaps you have a limit set for number of domains to display in System Settings ⇾ Virtualmin Virtual Servers ⇾ Configuration: User interface settings?
A client phoned to say they can’t login to Virtualmin. We checked and double checked, and indeed, the clear text password and username didn’t work.
Please double check that Webmin Login feature is enabled on Edit Virtual Server page.
Also, can you provide a screenshot of how it looks?
This happens if you create a domain owned by root or assigned ownership of an existing domain to the root user, which basically changes the permissions to those of a domain owner. It doesn’t make sense to do this (because root “owns” all domains), and Virtualmin shouldn’t allow you to do it, so it’s a bug.
Confirm that’s what happened by looking in /etc/webmin/webmin.acl. If the root: line is very short and only has a few modules listed (like a half-dozen or so, probably), then this is the explanation.
If that is what happened, you’ll need to re-grant root all permissions by editing the /etc/webmin/webmin.acl file and changing the root: line to something like this:
Then restart the webmin service. You’re mostly done. I think some modules will still have some restrictions, which you may need to remove in the Webmin Users module, but since your root user is back to mostly being root, it should be possible from within Webmin.
I really would like to know how you convinced Virtualmin to do this, if that’s what happened. There used to be several ways to make it happen (some subtle, some required a user doing something that doesn’t make sense), but I thought they were fixed years ago.
I can’t do either of this, because the root user now has non-root permissions. No more Systems Settings nor Edit Virtual Server permissions. I can’t even see those menus anymore.
EDIT: That was the solution. It appears at some stage today when the user sitename1 was accessed, a file called “root.acl”, present in /etc/webmin and another 16 subdirectories, inherited the permissions of sitename1 rendering the panel into a non-administrative state where only sitename1 is visible and not much else.
I had to delete all 17 of those files called ‘root.acl’.
I only recall trying to reset the password for sitename1, and requesting an SSL certificate.
Thanks @Joe and @Ilia without something to try I would have been screwed. Back in business, yah!
Can you tell us what you were doing when this happened? I’m guessing that maybe your browser filled in root and the root password on the Edit Virtual Server page, maybe? (Though that shouldn’t work…so, maybe some other page? But, I still suspect browser auto-fill somewhere.)
Can you tell us what you were doing when this happened?
I’m looking at the logs now.
Client call to say they want to log in.
Normally I log in as a SUDO user, myname. Today I logged in as another little used SUDO user, aname.
I navigate to Edit Virtual Server, Configurable Settings, to retrieve username and clear text password.
I open Incognito Window to try and log in with said username and password. It doesn’t work.
Things go haywire after that. So perhaps your theory is correct, that somewhere a session cookie is stored and when I did incognito although it looked like I logged in as the user, I was actually in as root or something.
That’s about all I can say for now, but thanks so much, when you mentioned these ACL files I googled “root.acl” and almost immediately found that legacy post. So all good.
I’m guessing that maybe your browser filled in root and the root password on the Edit Virtual Server page, maybe?
This probably confirms the browser auto-fill hypothesis, since it would mean the domain owner user would have gotten set to the root password in the process, probably.
Still unsure what form or page could trigger this, though, since as far as I knew until this thread, we’d fixed it so you couldn’t do something like this, even if you tried (since it doesn’t make sense to do).
If the file that Joe mentioned earlier (i.e. /etc/webmin/webmin.acl) looks okay, then you’d be able to navigate to Webmin ⇾ Webmin Users: Edit Webmin User / Available Webmin modules / Virtualmin Virtual Servers and check on ACLs set there: