Admin panel broken after restore/upgrade

I had to perform a restore to a new box today. Old box was running v67, new box is v69a I believe. Everything (send/receive, nextcloud, etc.) all works. Webmail interface works.

The admin panel is the only thing not working. One caveat may be that I had MFA set up on the previous server’s admin panel. Not sure how to restore this.

I came here because I have the exact same issue. But mine is on a brand new server. New domain and DNS.

Also new box with the same issue

Very interesting. Thanks for chiming in. Helps me realize that the restore process didn’t break this.

I have another system, recently upgraded to v69 → no problems.
No I wont update to v69a at the moment to verify :slight_smile:
But gut feeling says, theres something broken in v69a

1 Like

come on its for science! :slight_smile:

Been struggling with this issue since yesterday. I thought the same, that it was an issue with upgrade process so I built 3 more servers for testing and even registered a new domain to test fresh build. but it looks like I am not the only one so there is that light.

1 Like

No problem with either v69 or v69a. Also have MFA which is working. Running Ubuntu 22.04 on AWS instance. All updates and upgrades in place

Fresh build or upgraded from previous?

I have fresh install and I have the same problem. Does anyone have a solution for this? Is there a file missing or some css missing?

I’m on v68. All was working fine. Per my other setup topic, I have been setting up a new box and periodically rsync /home/user-data/mail from a currently active older box. This box is set up but not the active mail machine for the domain yet.

Everything has been going fine. Could log into roundcube and the admin panel. All of a sudden, I now get a popup on login that says:

Error
Something went wrong, sorry.

And I can’t get in.
I can get into email (roundcube), and all the latest is there.

What are the error conditions that would cause this? What would change without my changing anything? I didn’t upgrade.

I then reinstalled v68 (modified $TAG in setup) and no errors, but it’s still broken.

What could cause this? All was fine just hours ago!

Thanks.

When you get this, try looking at the output of sudo journalctl -u mailinabox

These are the relevant log lines from /var/log/nginx/access.log

[22/Jul/2024:15:55:25 -0400] "GET /admin/assets/bootstrap/css/bootstrap.min.css HTTP/2.0" 403 169 "https://<my mailserver>.com/admin" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
[22/Jul/2024:15:55:25 -0400] "GET /admin/assets/bootstrap/css/bootstrap-theme.min.css HTTP/2.0" 403 169 "https://<my mailserver>.com/admin" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
[22/Jul/2024:15:55:25 -0400] "GET /admin/assets/jquery.min.js HTTP/2.0" 403 169 "https://<my mailserver>.com/admin" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
[22/Jul/2024:15:55:25 -0400] "GET /admin/assets/bootstrap/js/bootstrap.min.js HTTP/2.0" 403 169 "https://<my mailserver>.com/admin" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"

Also, are these the correct file permissions for jquery.min.js? What’s up with the 1991 date on this?

ubuntu@mail01:~$ sudo ls -l /usr/local/lib/mailinabox/vendor/assets
total 88
drwxr-xr-x 5 root root  4096 Feb 13  2019 bootstrap
-rw-r--r-- 1 root root 85578 Oct 18  1991 jquery.min.js

hello I had the same problem and there are other bugs for this problem, test that

echo “test” | sudo tee /usr/local/lib/mailinabox/vendor/assets/test.txt
sudo chown www-data:www-data /usr/local/lib/mailinabox/vendor/assets/test.txt
sudo chmod 755 /usr/local/lib/mailinabox/vendor/assets/test.txt

sudo chmod 755 /usr/local/lib/mailinabox/vendor

1 Like

There are certainly some complaints in the journal… My Python ability is at a baby-talk level, so I didn’t get far tracing what might be happening. I’m assuming setup creates /usr/local/lib/mailinabox because I didn’t copy any of this over.

I also ran setup again (TAG=v68) thinking something got mangled…

The odd thing is I didn’t touch anything - only rsync’d user-data/mail as usual and restarted… And I can get into roundcube just fine. In fact, the first failure was when I reloaded the admin page and the browser filled the fields in from previous.

Here is the log. Any ideas? The only thing I can think of is that roundcube.sqlite is in ./mail but there have been no user changes on either machine in this time. On the old machine I can get into roundcube AND the admin panel fine.

Jul 22 18:30:00 start[79017]: {SHA512-CRYPT}$6$qYnhXXnerwlaSvpn$CRE//xxxxxxxxxxxx/yyyyyyyyyyyyyyyy/Lk5DIS1 (verified)
Jul 22 18:30:00 start[7970]: [2024-07-22 18:30:00,420] ERROR in app: Exception on /login [POST]
Jul 22 18:30:00 start[7970]: Traceback (most recent call last):
Jul 22 18:30:00 start[7970]: File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 1473, in wsgi_app
Jul 22 18:30:00 start[7970]: response = self.full_dispatch_request()
Jul 22 18:30:00 start[7970]: File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 882, in full_dispatch_request
Jul 22 18:30:00 start[7970]: rv = self.handle_user_exception(e)
Jul 22 18:30:00 start[7970]: File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 880, in full_dispatch_request
Jul 22 18:30:00 start[7970]: rv = self.dispatch_request()
Jul 22 18:30:00 start[7970]: File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 865, in dispatch_request
Jul 22 18:30:00 start[7970]: return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
Jul 22 18:30:00 start[7970]: File “/root/mailinabox/management/daemon.py”, line 143, in login
Jul 22 18:30:00 start[7970]: email, privs = auth_service.authenticate(request, env, login_only=True)
Jul 22 18:30:00 start[7970]: File “/root/mailinabox/management/auth.py”, line 83, in authenticate
Jul 22 18:30:00 start[7970]: self.check_user_auth(username, password, request, env)
Jul 22 18:30:00 start[7970]: File “/root/mailinabox/management/auth.py”, line 124, in check_user_auth
Jul 22 18:30:00 start[7970]: status, hints = validate_auth_mfa(email, request, env)
Jul 22 18:30:00 start[7970]: File “/root/mailinabox/management/mfa.py”, line 111, in validate_auth_mfa
Jul 22 18:30:00 start[7970]: mfa_state = get_mfa_state(email, env)
Jul 22 18:30:00 start[7970]: File “/root/mailinabox/management/mfa.py”, line 18, in get_mfa_state
Jul 22 18:30:00 start[7970]: c.execute(‘SELECT id, type, secret, mru_token, label FROM mfa WHERE user_id=?’, (get_user_id(email, c),))
Jul 22 18:30:00 start[7970]: sqlite3.OperationalError: no such table: mfa
Jul 22 18:30:00 gunicorn[7970]: Exception on /login [POST]
Traceback (most recent call last):
File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 1473, in wsgi_app
response = self.full_dispatch_request()
File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 882, in full_dispatch_request
rv = self.handle_user_exception(e)
File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 880, in full_dispatch_request
rv = self.dispatch_request()
File “/usr/local/lib/mailinabox/env/lib/python3.10/site-packages/flask/app.py”, line 865, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
File “/root/mailinabox/management/daemon.py”, line 143, in login
email, privs = auth_service.authenticate(request, env, login_only=True)
File “/root/mailinabox/management/auth.py”, line 83, in authenticate
self.check_user_auth(username, password, request, env)
File “/root/mailinabox/management/auth.py”, line 124, in check_user_auth
status, hints = validate_auth_mfa(email, request, env)
File “/root/mailinabox/management/mfa.py”, line 111, in validate_auth_mfa
mfa_state = get_mfa_state(email, env)
File “/root/mailinabox/management/mfa.py”, line 18, in get_mfa_state
c.execute(‘SELECT id, type, secret, mru_token, label FROM mfa WHERE user_id=?’, (get_user_id(email, c),))
sqlite3.OperationalError: no such table: mfa

does anyone have an actual fix to the admin panel of miab not working? step by step if possible as I don’t understand 90% of the code/ssh stuff

Luc’s fix worked for me but after I made the changes I had to run the MiaB installer again before it worked. Just log into console via ssh and copy/paste the lines one by one.

Good Luck. even after the fix I just decided to stick with my 18.04 Ubuntu and 57a MiaB install. Will come back to it in 2028 when the server reaches EOL

What does Luc’s fix do exactly? Is a restart needed after or re-install?

Seems it’s a simple permissions issue. Here’s the fix in another thread thanks to @miaber

Hopefully @JoshData can push an update to fix these permissions for a trouble-free install/update. Until then, ssh into your server and simply fix the file/folder permissions.

Edit: There may be more to this issue… Hopefully Josh can shine some light on this :slight_smile:

Wow, I did do a search prior to posting. Glad I’m not the only one, for a moment I thought I was hallucinating when /admin did not work.

1 Like