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

Created on 12 Feb 2020 · 14Comments · Source: nextcloud/mail

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.

Source

NL66278

All 14 comments

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.

ChristophWurst on 13 Feb 2020

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.

hbrunn on 19 Feb 2020

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.

ChristophWurst on 19 Feb 2020

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?

hbrunn on 19 Feb 2020

More like what was in config/config.php. Then we can compare it to the json in https://github.com/nextcloud/mail/issues/2647#issuecomment-588054786

ChristophWurst on 19 Feb 2020

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?

hbrunn on 19 Feb 2020

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?

ChristophWurst on 19 Feb 2020

LDAP

hbrunn on 19 Feb 2020

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

hbrunn on 19 Feb 2020

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

ChristophWurst on 19 Feb 2020

The mail is indeed working now.

NL66278 on 19 Feb 2020

🚀1

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

hbrunn on 19 Feb 2020

👍1

Perfect!

ChristophWurst on 19 Feb 2020

just to be sure: Thanks for your help, and thank you for the code!

hbrunn on 19 Feb 2020

❤1

Was this page helpful?

0 / 5 - 0 ratings