Thanks for posting the procedure. It seems to have worked fine for me.
Hi @cinergi just want to call out that this summary was super helpful for me and immediately fixed Z-Push on my end. Thank you!
I’m glad it helped! However, please also see my post here. After using it for a while, I found that it’s unstable. I’ve since stopped using it and am using regular IMAP instead. Z-Push does not officially support PHP 8.0; if it were a simple matter of changing a few lines of code as I optimistically did, the maintainers of the Z-Push project would surely have done it already… I think we’ll have to wait for official PHP 8.0 support from upstream.
1 Like
I also had this same issue.
Thank you for posting the steps to correct!
Looks like Exchange/Activesync support is broken in V60 
Thanks @Mandrake this was really helpful! One thing I noticed is that MIAB will restore the local.conf to the original every night when it does maintenance.
So my extension to this suggestion, that I’m contemplating submitting as a PR, is to change the base templates that the maintenance scripts use to create the local.conf, such that when maintenance regenerates local.conf, it does so with the required changes.
I changed:
-
~/mailinabox/conf/nginx-top.conf - here add the php7.4-fpm upstream as suggested by Mandrake.
-
~/mailinabox/conf/nginx-alldomains.conf - here change the /Microsoft-Server-ActiveSync location and the autodiscover.xml location to use the php7.4-fpm.
And that’s it 
then next time maintenance runs, it uses these files and everyone’s happy.
This has been working well for me so far. I guess the one thing to watch out for is that when I take a new version of Mailinabox, all my changes are probably going to get overwritten…
Tried to upgrade last week but ran into a number of issues and ran out of time to troubleshoot. Tried again today after finding a few fixes.
60.1 is now up and running on Ubuntu 22.04, but I did see a couple of minor errors at the end when reconfiguring MIAB:
doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:91: ssl_dh_parameters_length is no longer needed
I’m not sure if there’s anything I actually need to do on these.
More or an irritation is, and as someone else has mentioned above, neither my contacts nor calendar are populated with any entries. There’s mention of using the occ command, but I can’t seem to find the right syntax to try and disable/re-enable both apps to see if that fixes the issue.
[Edit]Found the relevant commands:
sudo -u www-data php /usr/local/lib/owncloud/occ app:disable calendar
Sadly though, running disable and enable haven’t fixed the issue and I still don’t have my calendar or contacts list back.
I’m having “Temporary failure in name resolution” issues. As a result, trying to resolve and restore my backups is failing. I’ve started from bare metal on my Virtual instance, installed Ubuntu 22.04 LTS X64, followed the normal MIAB installation process, and get those name resolution failures. I destroyed the server and tried again via the built in console with my service provider, thinking maybe there is an issue with my SSH connection and my firewall, but I end up with the same issue. I went ahead and tried the migration/restore effort, and any secondary domain and DNS info is not restored. I then reverted back to my “snapshot” instance and ran “mailinabox” on the old instance to see if I would get the same name resolution issues, and I do not.
The first error happens at the Roundcube installation, twice when installing Nextcloud, then again after Nextcloud states it is already at the latest version, and finally at the Munin installation.
Suggestions?
I saw something similar, and got around it by editing /etc/resolv.conf so it pointed to a good (local) name server, then rerunning sudo mailinabox. (resolv.conf might be left pointing to 127.0.0.1, but if your box doesn’t have a functioning name server at that point, things are going to go pear-shaped!)
A symptom for me was that many unrelated commands that produced error/log messages got very slow (I guess they were waiting for a timeout) and I’d get a “cannot resolve” for my local box.
I thought that, but when I restore to my previous system image, /etc/resolve.conf also only has 127.0.0.1, and no other IP. And if I run “sudo mailinabox” it successfully runs through the process without errors or those nameserver issues.
For a completed MIAB install, /etc/resolv.conf does have only 127.0.0.1, because it’s using a local instance of named as the name server.
I have seen my box with that named service not working, then you can’t resolve names, and so the install etc can’t run. If your install process breaks and you get an error doing something like nslookup www.google.com, then editing resolve.conf might help. But if nslookup is working fine, you have some other problem.
It’s not clear to me, from your description, exactly what the problem is. Does the install run completely? Was MIAB working, at least partly, after the install? It’s not clear what you mean by “those name resolution failures”.
MIAB install completes. It then gives me errors when trying to go to the web console, but if I refresh a couple of times, I’ll get in. However, MIAB isn’t truly functional, in that it won’t restore completely. I reverted back to a snapshot, and I’ll do a fresh backup, and try again next week. I’ll capture screenshots along the way too.
Besides the normal ones above - one thing that i found missing was a local postgrey file - not sure it’s in the scope tho - but just if anyone notice that postgray was enabled after migrating.
/etc/postgrey/whitelist_clients.local was not grabbed - naturally just manually recreated it, so local files with custom changes might not be grabbed.
Thanks for this! It worked great for me, too! 
Very excited about this release. I have installed Ubuntu Server 22.04. However, every time I try to install Mail-in-a-Box by following the instructions I get to the point where it asks for the hostname, I provide it and then after a couple of minutes the installation fails. The error says:
FAILED: add-apt-repository -y ppa:duplicity-team/duplicity-release-git, followed by a lot of references to recent calls made in the code.
So–in an effort to avoid being lazy I added this to the repository myself, did an apt update and an apt upgrade. Then I did an apt install duplicity and installed it manually.
Still–even after all this the installation fails at the same location every time with the same message.
Any ideas on what else I could try? Is there an installation log file somewhere I could peruse or upload?
Looking forward to the new version. I’m currently on Ubuntu 18.04 and MIAB v55.
Mike
Just to be thorough I blitzed everything and did a fresh install of Ubuntu Server 22.04.
On a clean install I am having the same exact error as I was before I re-installed.
Just updating the issue. No idea where to go from here. I admit–I don’t know where/if there is an installation log file that might give me the answer I need to resolve…
Monitoring. Have the same issue
Recommended change to the upgrade instructions: add a final step saying “grab and store securely your NEW backups-key as this will be different from your old server.” I almost missed that step but, thankfully, it occurred to me to confirm that the key was the same and, of course, it wasn’t.
1 Like
Hi All,
I am getting ready to do this upgrade, having carefully (I hope) read and digested the travails reported here.
My /home directory is on a separate data volume, so I can attach it to any server in the data center. My question is what do the experts say regarding just attaching and mounting the volume on the new Ubuntu 22.04 server, after doing the MIAB install on the new server (instead of doing the duplicity restore step)? My proposal is to:
- set up the new Ubuntu server and install MIAB (this step is already done)
- on the old server, do all the backup, cleaning of ssl directory, etc prep work that precedes the duplicity restore step as documented in Moving to a New Box / Testing Backups
- shut down the old server and attach the volume to the new server
- edit
/etc/fstabto mount the volume on/home - reboot
- rerun
sudo mailinaboxas per instructions
Does anyone have any suggestions, gotchas, insights with this plan? I think my question boils down to whether there are things that get put on the new server in /home/user-data that need to stay there for the new MIAB to work? Or will the sudo mailinabox put them there if they are missing?