Solutions
-
MrChip's post in Dovecot docker container throwing user not found error - progress, and solved ... was marked as the answerI've solved my remaining problems. The error on setresgid was because te user data I had been using was now forcing the container to try to change its guid. I had specified a setting for a specific mail group id, but in the container environment, that setting doesn't work because the container process runs without sufficient privileges. I also had to change the user gid for my user account on dovecot, again to avoid forcing a gid change the process didn't have the permissions to do. After that, my thunderbird client was able to login.
I had some trouble getting the thunderbird client to list all the folders. I wound up going through a process to import my previous Maildir folder tree into the new container tree, and then resubscribe all the folders in thunderbird. Now I can see the full tree through the thunderbird client.
I hope this blurb may help someone else who might hit the same issues on upgrading their Dovecot docker container.
-
MrChip's post in Oh oh - 2128 parity errors was marked as the answerDisk1 has now failed (several days ago now). A file system check showed tons of errors, and the root of the file system was unreadable. I took disk1 out of the array so the array had just disk2 and parity. I rebuilt the parity and restored the data from backup. I've run several parity checks since then and all are zero errors.
I bought a new disk, zeroed it, and added it to the array today. A parity-sync is in progress. I'll run a parity check daily for a time to keep an eye on it.
I think disk1 was the source of the parity error that prompted my OP, but I'll wait a few parity check cycles before I conclude that. I want to thank JorgeB for his input and suggestions - much appreciated.
-
MrChip's post in [SOLVED] Disks no longer assigned after flash drive replacement was marked as the answerOkay !!WHEW!! -- Solved!
When I did the right search, I discovered super.dat. For those who may have this problem and discover this post in the future, super.dat is where the array configuration is stored. But it's not backed up under that name when I do a flash backup. Rather it's copied to super.dat.CA_BACKUP. When I recreated my flash drive and restored my config directory from my flash backup, I needed to copy super.dat.CA_BACKUP back to super.dat. When I didn't do that, a new, empty super.dat was created which had no array configuration in it. So this is why my disks were not showing in the array , but in the Unassigned Devices list.
I shutdown the server, put the flash drive into my PC and copied super.dat.CA_BACKUP back to super.dat, then rebooted the server (with the flash drive, of course). And it all came up with the disks in the right place. I started the array in maintenance mode, and the array came up and everything is fine. It's reporting the parity is valid, without a parity check. (I'm a bit paranoid, though, so I think I'll do a parity check anyway.)
So I now have my server back and a much better understanding of what to do to replace a faulty flash drive when one of my other Unraid servers has it's flash drive fail.