I have 2 installations. One works, one stopped hours ago. I compared the 2 systems re those permissions before changing things and the working and broken systems have the same permissions for all the files and dirs there.
That might be a v69 problem. Mine is v68.
Yes, I have 1 v68 running fine, that was how I figured out the bad permissions.
I did also try to install v68 on this new host and it came up with the same bad permissions, that led me to conclude it was something about my host, but i now think this was a wrong conclusion.
Perhaps this is happening due to changes in one of MIABâs dependencies.
So your v68 permissions are /usr/local/lib/mailinabox/vendor 0664 for files, 0775 for folders /home/user-data 0664 for files, 0775 for folders?
My working v27 and broken v68 are both 755 for dirs and 644 for filesâŚ
It worked for days, having started by rsyncâing the whole old system user-data to the new box except the ssl dir and installing. The perms still match on everything.
I tried running setup/start.sh again. Now Iâm getting
Installing Munin (system monitoring)âŚ
500 Internal Server Error
no such table: auto_aliases<!doctype html>Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.
Your Mail-in-a-Box is running.
I donât think Iâve seen that before either. Iâd like to find out the cause. The expedient solution could jsut be âdelete everythingâ, copy the old user-data again and start over, but that could be a disaster or at best works and I have no idea whyâŚ
If I can get to the âwhyâ and fix it, I might learn enough to help someone else one day 
When I installed v68, I did not know to check the folder perms yet, so to answer your question, I donât know. I do know that on v69a, perms are wrong every time, in particular the vendor folder was 0700.
Finding the why requires someone who knows the gist of the entire code base, I do know parts of the code base, but not the entirety. If we can find out where /usr/local/lib/mailinabox/vendor was created, that is where I would start.
I did also try to make the setup more verbose (to see errors), but I donât think there is such an option.
Iâve pushed a new release that hopefully fixes the (original) issue in this topic for new installations.
The problem was that on new installations (or if /home/user-data/backup/secret_key.txt is missing), the âumaskâ is changed while creating secret_key.txt so that it is created with proper non-world-readable permissions (this refers to local Unix file permissions). In previous versions, this umask change was temporary. But it was incorrectly made non-temporary in this release, which affected the permissions of the files created after this step.
If you had the problem in this topic:
mailinabox will re-run the setup, and I think this ought to fix the admin asset permissions because it re-downloads the admin assets on every run of the setup, I am not sure if there are other broken permissions that wonât get fixed this way.Did it. Thanks.
It just smelled like the same issue at first, but with digging and dialogue, it is a different thing.
Thanks @JoshData !
I reran the install script to grab the latest version (v69b) and install it. After a reboot, the error persists.
upgrade zu 69b did not help.
the chmods from @luc brought back the admin interface but deploying a letsencrypt certificate fails with a 403 when the ca is trying to get the .well-known things.
(server was a fresh install to 69a)