The mail app crashes. Apparently it can not retrieve login password to send to imap server.

[NL66278]

The users are retrieved from an ldap server. The imap server is dovecot. However the error occurs before even attempting to contact the imap server as can be seen in the log-entry,

I suppose the mail app would use the username and password entered to login to contact the imap server. Is this correct?

Is there any possibility to have separate imap settings for one user?

The problem started to occur after changing the primary email address in nextcloud to another email address, but that is pointing to the same ldap account, and is also equal to the email used to login to nextcloud.

{"reqId":"Bs1heRl1zxhAJwoKg2Bi","level":3,"time":"2020-02-12T11:23:18+00:00","remoteAddr":"87.211.99.127","user":"rportier","app":"index","method":"GET","url":"/apps/mail/","message":{"Exception":"Exception","Message":"Argument 1 passed to OC\Security\Crypto::decrypt() must be of the type string, null given, called in /srv/www/www-nextcloud/public_html/apps/mail/lib/IMAP/IMAPClientFactory.php on line 66","Code":0,"Trace":[{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/App.php","line":126,"function":"dispatch","class":"OC\AppFramework\Http\Dispatcher","type":"->","args":[{"class":"OCA\Mail\Controller\PageController"},"index"]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/Routing/RouteActionHandler.php","line":47,"function":"main","class":"OC\AppFramework\App","type":"::","args":["OCA\Mail\Controller\PageController","index",{"class":"OC\AppFramework\DependencyInjection\DIContainer"},{"_route":"mail.page.index"}]},{"function":"__invoke","class":"OC\AppFramework\Routing\RouteActionHandler","type":"->","args":[{"_route":"mail.page.index"}]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/Route/Router.php","line":297,"function":"call_user_func","args":[{"class":"OC\AppFramework\Routing\RouteActionHandler"},{"_route":"mail.page.index"}]},{"file":"/srv/www/www-nextcloud/public_html/lib/base.php","line":997,"function":"match","class":"OC\Route\Router","type":"->","args":["/apps/mail/"]},{"file":"/srv/www/www-nextcloud/public_html/index.php","line":42,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/Http/Dispatcher.php","Line":109,"Previous":{"Exception":"TypeError","Message":"Argument 1 passed to OC\Security\Crypto::decrypt() must be of the type string, null given, called in /srv/www/www-nextcloud/public_html/apps/mail/lib/IMAP/IMAPClientFactory.php on line 66","Code":0,"Trace":[{"file":"/srv/www/www-nextcloud/public_html/apps/mail/lib/IMAP/IMAPClientFactory.php","line":66,"function":"decrypt","class":"OC\Security\Crypto","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/www/www-nextcloud/public_html/apps/mail/lib/IMAP/MailboxSync.php","line":75,"function":"getClient","class":"OCA\Mail\IMAP\IMAPClientFactory","type":"->","args":[{"class":"OCA\Mail\Account"}]},{"file":"/srv/www/www-nextcloud/public_html/apps/mail/lib/Service/MailManager.php","line":93,"function":"sync","class":"OCA\Mail\IMAP\MailboxSync","type":"->","args":[{"class":"OCA\Mail\Account"}]},{"file":"/srv/www/www-nextcloud/public_html/apps/mail/lib/Controller/PageController.php","line":113,"function":"getFolders","class":"OCA\Mail\Service\MailManager","type":"->","args":[{"class":"OCA\Mail\Account"}]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/Http/Dispatcher.php","line":170,"function":"index","class":"OCA\Mail\Controller\PageController","type":"->","args":[]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/Http/Dispatcher.php","line":99,"function":"executeController","class":"OC\AppFramework\Http\Dispatcher","type":"->","args":[{"class":"OCA\Mail\Controller\PageController"},"index"]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/App.php","line":126,"function":"dispatch","class":"OC\AppFramework\Http\Dispatcher","type":"->","args":[{"class":"OCA\Mail\Controller\PageController"},"index"]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/AppFramework/Routing/RouteActionHandler.php","line":47,"function":"main","class":"OC\AppFramework\App","type":"::","args":["OCA\Mail\Controller\PageController","index",{"class":"OC\AppFramework\DependencyInjection\DIContainer"},{"_route":"mail.page.index"}]},{"function":"__invoke","class":"OC\AppFramework\Routing\RouteActionHandler","type":"->","args":[{"_route":"mail.page.index"}]},{"file":"/srv/www/www-nextcloud/public_html/lib/private/Route/Router.php","line":297,"function":"call_user_func","args":[{"class":"OC\AppFramework\Routing\RouteActionHandler"},{"_route":"mail.page.index"}]},{"file":"/srv/www/www-nextcloud/public_html/lib/base.php","line":997,"function":"match","class":"OC\Route\Router","type":"->","args":["/apps/mail/"]},{"file":"/srv/www/www-nextcloud/public_html/index.php","line":42,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"/srv/www/www-nextcloud/public_html/lib/private/Security/Crypto.php","Line":113},"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0","version":"17.0.3.1"}

[ChristophWurst]

Do you auto-provision accounts? Please use the template from https://github.com/nextcloud/mail/issues/new?assignees=&labels=bug%2C+0.+to+triage&template=bug.md&title= so we can get a better understanding of your setup and problem.

[hbrunn]

thanks for the reply, this is indeed auto-provisioning + ldap. But I think I found the problem:

> occ config:app:get mail provisioning_settings
{"active":false,"version":1,"email":"%EMAIL%","imapHost":"XXX","imapPort":993,"imapSslMode":"ssl","smtpHost":"localhost","smtpPort":25,"smtpSslMode":"none","imapUser":"%EMAIL%","smtpUser":"%EMAIL%"}

So the account with the problem was provisioned before version 0.20, and stopped working some time after 1.0.0 (@NL66278 do you know exactly when you encountered this problem first?).

As you see the provisioning is disabled, I reenabled it via Settings / Administration / Groupware, and clicked 'Apply and create/update for all users'. (this for whomever finds this via google)

Is this a known migration issue I should have read about somewhere?

Anyways, for us the problem is fixed, so from my side this issue is solved.

[ChristophWurst]

The migration should be smooth. But of course it's possible that some of the old settings weren't migrated correctly. It's hard to tell without knowing the previous state or seeing the upgrade logs.

[hbrunn]

the logfile of the possibly fauly migration is gone for good, but I can restore backups of the db/files for debugging. Are we talking about the state before I overwrote all configs with the new provisioning or the state before whatever caused the backtrace?

Which values do you want me to post?

[ChristophWurst]

More like what was in config/config.php. Then we can compare it to the json in #2647 (comment)

[hbrunn]

sure, no problem:

  'app.mail.accounts.default' =>
  array (
    'email' => '%EMAIL%',
    'imapHost' => 'XXX',
    'imapPort' => 993,
    'imapSslMode' => 'ssl',
    'smtpHost' => 'localhost',
    'smtpPort' => 25,
    'smtpSslMode' => 'none',
  ),

That looks like a success to me.

But the thing is, we have with the same provisioning other users whose accounts just worked fine, also without the provisioning enabled + create/update.

I also realize that the account with the problem is a very old one. Is there a chance earlier versions wrote stuff into some user setting that I cleaned up for this account with re-enabling this? Is there something I can look up about that in the old database dumps?

[ChristophWurst]

Yep, seems fine.

So the thing is: with the new provisioning, we store the accounts in the database. That wasn't done before. But since we don't know the user password when the provisioning happens, the password is added later. The Argument 1 passed to OC\Security\Crypto::decrypt() must be of the type string, null given will pop up when an account without a password is accessed.

What is your user back-end?

[hbrunn]

LDAP

[hbrunn]

(so the account with the problem was ldap, and the other accounts that worked fine at the same time too)

[ChristophWurst]

Okay, just asking because some back-ends like SAML don't have a password in some cases.

I'm not sure why that account throws an error. Possibly

• The new provisioned account was created during the migration
• Provisioning was set to inactive
• The password was not updated thus

[NL66278]

The mail is indeed working now.

[hbrunn]

well, then let's take this as a glitch. Over here everyone's happy, and whoever runs into the problem too finds this issue and the fix by searching for the stack trace