nextcloud AIO Mail App cannot Delete created provisioning accounts

[ryomahostingph]

Steps to reproduce

1.delete a previously created Account provisioning 2.opening the mail app 3.no way to delete the mail account

Expected behavior

Actual behavior

Mail app version

1.13.8

Mailserver or service

CUSTOM IMAP

Operating system

Docker

PHP engine version

No response

Web server

Other

Database

PostgreSQL

Additional info

once i create settings for account provisioning, i cannot delete other mail accounts that auto created by mail app, the error makes the server lag because of the invalid configs or wrong password for other accounts

i deleted the provision settings, but when i refresh the browser it will go back again, what to do?

[tatrapikao]

Same thing here. I tried Provisioning without success but now i'm stuck with a broken account in the account which makes Mailapp unusable slow. occ mail:account:delete <ID> gives me: This is a provisioned account which can not be deleted from CLI. Use the Provisioning UI instead.

[ChristophWurst]

IIRC the logic was that Provision all accounts would clear the abandoned accounts. Could you give that a try? Otherwise this smells like a bug.

[ryomahostingph]

i uninstall the Mail app and install it again here is the settings, no settings configured as of now, so when i add new configure when i refresh no settings, even though i saved the settings, "maybe because i tried to do the former settings as the email address template title i unprovisioned and deleted the config but when i refresh i did not delete the config then i check in logging

[tatrapikao]

sorry for long reply time - neither provisioning, unprovisioning or re-installation of Mail where able to fix the Problem.

[so-rose]

I also encountered this issue, and managed to workaround.

How it Happened

It happened after I tried to turn on mailsieve in the provisioned configuration. After this, deprovisioning accounts would delete the provisioning, but not the provisioned accounts - thus, the CLI would refuse to remove the accounts, since it thought they were attached to a now-nonexistant provisioning. I fixed it by running the fix below, then never touching provisioning again.

I'm on the official docker image v25 running MariaDB 1.5 and the latest mail.

The situation was a bit untenable.

• The accounts exist, and think they're provisioned (thus, even occ mail:account:delete refuses to delete them, as it thinks they're provisioned).
• The accounts do not work, because of lacking credentials (users couldn't enter their own passwords into provisioned accounts).

The Workaround

The fix is a bit harsh, but it does the job.

First, login as root to your database. Then the usual:

use nextcloud;
select * from oc_mail_account

Make sure they all have provisioning_id non-null, and that

select * from oc_mail_provisionings

returns nothing.

Next, deassociate the accounts with (non-existant) provisionings:

update oc_mail_accounts set provisioning_id=NULL;

For good measure, uninstall the mail app, then hard-reset the entire construction:

DELETE FROM `oc_migrations` WHERE app='mail';
DELETE FROM `oc_preferences` WHERE appid='mail';

drop table oc_mail_classifiers;
drop table oc_mail_message_tags;
drop table oc_mail_messages;
drop table oc_mail_provisionings;
drop table oc_mail_recipients;
drop table oc_mail_tags;
drop table oc_mail_trusted_senders;
drop table oc_mail_local_messages;

Now you can reinstall the mail app and live your life!

Conclusion

A few things stood out to me:

• Credentials: I could find no good way of letting users input their own credentials to provisioned accounts. I'm unsure of what the vision is.
• Database: The tables created by the mail app do not drop after the app is removed. A clean uninstall would have prevented the entire issue.
• Sieve: This seemed to make things very strange. This is where I would triage.

In the end, the easiest way was just letting the users add their own email account. Their email already auto-fills, so they only have to enter their password.

[wisiagency]

I also encountered this issue, and managed to workaround.

How it Happened

It happened after I tried to turn on mailsieve in the provisioned configuration. After this, deprovisioning accounts would delete the provisioning, but not the provisioned accounts - thus, the CLI would refuse to remove the accounts, since it thought they were attached to a now-nonexistant provisioning. I fixed it by running the fix below, then never touching provisioning again.

I'm on the official docker image v25 running MariaDB 1.5 and the latest mail.

The situation was a bit untenable.

• The accounts exist, and think they're provisioned (thus, even occ mail:account:delete refuses to delete them, as it thinks they're provisioned).
• The accounts do not work, because of lacking credentials (users couldn't enter their own passwords into provisioned accounts).

The Workaround

The fix is a bit harsh, but it does the job.

First, login as root to your database. Then the usual:

use nextcloud;
select * from oc_mail_account

Make sure they all have provisioning_id non-null, and that

select * from oc_mail_provisionings

returns nothing.

Next, deassociate the accounts with (non-existant) provisionings:

update oc_mail_accounts set provisioning_id=NULL;

For good measure, uninstall the mail app, then hard-reset the entire construction:

DELETE FROM `oc_migrations` WHERE app='mail';
DELETE FROM `oc_preferences` WHERE appid='mail';

drop table oc_mail_classifiers;
drop table oc_mail_message_tags;
drop table oc_mail_messages;
drop table oc_mail_provisionings;
drop table oc_mail_recipients;
drop table oc_mail_tags;
drop table oc_mail_trusted_senders;
drop table oc_mail_local_messages;

Now you can reinstall the mail app and live your life!

Conclusion

A few things stood out to me:

• Credentials: I could find no good way of letting users input their own credentials to provisioned accounts. I'm unsure of what the vision is.
• Database: The tables created by the mail app do not drop after the app is removed. A clean uninstall would have prevented the entire issue.
• Sieve: This seemed to make things very strange. This is where I would triage.

In the end, the easiest way was just letting the users add their own email account. Their email already auto-fills, so they only have to enter their password.

thanks to this detailed solution, i will try this to nextcloud AIO

[riczorn]

I spent a bit of time on this, as I have large mail and mail_recipients folders (200k & 900k lines) and didn't want the users to go through re-downloading. All my users had a duplicate mail account created by provisioning, as reported by occ mail:account:export I created a full backup, then gave the following a try:

I removed provisioning from the configuration, then I checked the database and set the provisioning_id field to NULL as @so-rose suggested, and I was able to delete the first unwanted account with occ mail:account:delete

Despite having disabled provisioning, the account was swiftly re-created by Nextcloud, with provisioning_id=1.

So I hastily deleted the last line in mail_accounts from the database (without even bothering to check dependent records in other tables). I then moved on to the next account, used occ mail:account:delete to delete the fake account which provisioning had created, and lo and behold: also all other unwanted accounts were gone at once.

So now I have a mail_accounts table with only odd ids, the even ones being the spurious accounts created by provisioning.

I have no idea how it happened, but it definitely made my day.

Nextcloud v. 25.0.3 on Apache+php8.0-fpm / CentOS Stream 8

[ChristophWurst]

Despite having disabled provisioning, the account was swiftly re-created by Nextcloud, with provisioning_id=1.

This should be fixed by https://github.com/nextcloud/mail/pull/7992 should help if caching creates some unexpected accounts.