Upgrade to 1.14.0 on NC 24.0.6 yields BadFunctionCallException: authMethod is not a valid attribute

[CacheMinimal]

Steps to reproduce

1. Begin with an instance of NC 24.0.6 and Mail 1.13.9 installed
2. Configure and test mail account to local IMAP server using mail app per user (as opposed to the global Groupware settings)
3. Upgrade to Mail 1.14.0

Expected behavior

Mail should upgrade and continue to be functional via the web UI.

Actual behavior

Upon login to previously working user account the dashboard mail widget just spins and never shows any content. Attempting to click into the Mail app yields:

Internal Server Error
The server was unable to complete your request.

If this happens again, please send the technical details below to the server administrator.

More details can be found in the server log.

Technical details
Remote Address: <Removed for privacy>
Request ID: <Removed for privacy>

Mail app version

1.14.0

Mailserver or service

Local Dovecot IMAP/Postfix SMTP

Operating system

Ubuntu Server 20.04.5 LTS

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database

MySQL

Additional info

[index] Error: BadFunctionCallException: authMethod is not a valid attribute at <<closure>>

 0. /srv/www/nextcloud/lib/public/AppFramework/Db/Entity.php line 165
    OCP\AppFramework\Db\Entity->setter()
 1. /srv/www/nextcloud/lib/public/AppFramework/Db/Entity.php line 73
    OCP\AppFramework\Db\Entity->__call()
 2. /srv/www/nextcloud/lib/public/AppFramework/Db/QBMapper.php line 322
    OCP\AppFramework\Db\Entity::fromRow()
 3. /srv/www/nextcloud/lib/public/AppFramework/Db/QBMapper.php line 341
    OCP\AppFramework\Db\QBMapper->mapRowToEntity()
 4. /srv/www/nextcloud/apps/mail/lib/Db/MailAccountMapper.php line 98
    OCP\AppFramework\Db\QBMapper->findEntities()
 5. /srv/www/nextcloud/apps/mail/lib/Service/AccountService.php line 72
    OCA\Mail\Db\MailAccountMapper->findByUserId()
 6. /srv/www/nextcloud/apps/mail/lib/Controller/PageController.php line 129
    OCA\Mail\Service\AccountService->findByUserId()
 7. /srv/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php line 225
    OCA\Mail\Controller\PageController->index()
 8. /srv/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php line 133
    OC\AppFramework\Http\Dispatcher->executeController()
 9. /srv/www/nextcloud/lib/private/AppFramework/App.php line 172
    OC\AppFramework\Http\Dispatcher->dispatch()
10. /srv/www/nextcloud/lib/private/Route/Router.php line 298
    OC\AppFramework\App::main()
11. /srv/www/nextcloud/lib/base.php line 1030
    OC\Route\Router->match()
12. /srv/www/nextcloud/index.php line 36
    OC::handleRequest()

GET /apps/mail/
from <Removed IP> by <Removed user> at 2022-10-11T09:07:19+00:00

[jejusek]

The same. After upgrading to v 1.14 mail app collapsed. Page displays system error - contact to admin. Logs are the same. App is fun but now the app is useless.

[ChristophWurst]

The migration didn't run.

[ChristophWurst]

https://github.com/nextcloud/mail/blob/stable1.14/lib/Migration/Version1140Date20220701103556.php is the migration. Could you please check if your table oc_mail_accounts has a column auth_method?

[CacheMinimal]

The migration didn't run.

I guessed something like that due to the new authentication methods mentioned in the release notes. Is there anything I can provide to help you work out why it did not run? Is there a way I can force it to re-run?

Nothing special was done on my system. Simply logged into the UI as admin and ran the upgrade from the App store.

[CacheMinimal]

https://github.com/nextcloud/mail/blob/stable1.14/lib/Migration/Version1140Date20220701103556.php is the migration. Could you please check if your table oc_mail_accounts has a column auth_method?

Yes, it does as the last column. It is set to "password" for all my rows.

[ChristophWurst]

https://github.com/nextcloud/mail/blob/stable1.14/lib/Db/MailAccount.php#L117 attribute exists on the entity model

[CacheMinimal]

https://github.com/nextcloud/mail/blob/stable1.14/lib/Db/MailAccount.php#L117 attribute exists on the entity model

Is that a statement or question? If the latter, could you expand a little so that I can check what you are asking?

[ChristophWurst]

Statement. I'm checking possible causes for the problem.

[ChristophWurst]

This doesn't make sense at the moment. Could oyu check your apps/mail/lib/Db/MailAccount.php for the private $authMethod property?

If it's there then your server is using a cached version of the file in the opcache.

[ChristophWurst]

I'm spinning up a 24 Docker instance to see if it happens with vanilla nextcloud

[ChristophWurst]

Nope, new installation of 24 and Mail v1.14.0 is fine. So this must be specific to installations that upgraded from an earlier version.

[CacheMinimal]

This doesn't make sense at the moment. Could oyu check your apps/mail/lib/Db/MailAccount.php for the private $authMethod property?

In apps/mail/lib/Db/MailAccount.php on my server the declaration is there but it is protected rather than private:

class MailAccount extends Entity {
        protected $userId;
        protected $name;
        protected $email;
        protected $inboundHost;
        protected $inboundPort;
        protected $inboundSslMode;
        protected $inboundUser;
        protected $inboundPassword;
        protected $outboundHost;
        protected $outboundPort;
        protected $outboundSslMode;
        protected $outboundUser;
        protected $outboundPassword;
        protected $signature;
        protected $lastMailboxSync;
        protected $editorMode;
        protected $order;
        protected $showSubscribedOnly;
        protected $personalNamespace;
        protected $authMethod;

If it's there then your server is using a cached version of the file in the opcache.

That was it! I'm running PHP FPM. Restarting the PHP FPM service on the server made it read the new code and mail once again works fine.

Thanks for your assistance in tracing this anomaly. Any ideas why this should have happened with this update to Mail when I have been following the same procedure to upgrade the app for several years without the need to restart FPM?

[ChristophWurst]

I believe a call to https://www.php.net/manual/en/function.opcache-reset.php after Nextcloud updates any app could help.

For larger installations we always instruct to restart the web servers after an upgrade https://docs.nextcloud.com/server/stable/admin_manual/maintenance/manual_upgrade.html.

Any ideas why this should have happened with this update to Mail when I have been following the same procedure to upgrade the app for several years without the need to restart FPM?

Luck, or PHP wasn't as aggressive with caching before. It's hard to tell.

[ChristophWurst]

Check https://stackoverflow.com/questions/34260252/opcache-clears-too-quickly and your opcache settings.

[CacheMinimal]

Check https://stackoverflow.com/questions/34260252/opcache-clears-too-quickly and your opcache settings.

Thanks for this. I checked my PHP opcache settings and found that I had followed the server tuning guide at:

https://docs.nextcloud.com/server/latest/admin_manual/installation/server_tuning.html#enable-php-opcache

I had 'opcache.validate_timestamps = 0', which clearly applies to all PHP scripts and not just config.php as the document could be read to suggest. No idea how I have got away with things working during previous upgrades!

I have updated the PHP opcache settings on another server with mirror settings and can confirm I was able to update from mail 1.13.9 to 1.14.0 without any issues or needing to restart anything. Sorry to have bothered you with the troubleshooting due to a configuration misunderstanding on my behalf.

[Samonitari]

I experience the same problem.

The thing is, on one server I have the opcache.validate_timestamps "tuning", on another I don't, and both failed to work after the update to 14.0. Restarting the php-fpm service helped both.

So, @CacheMinimal I think it is not a "configuration" problem on your behalf"

[ChristophWurst]

So, @CacheMinimal I think it is not a "configuration" problem on your behalf"

Mind sharing your insights on what else caused this missing opcache invalidation despite source file changes?

[Samonitari]

So, @CacheMinimal I think it is not a "configuration" problem on your behalf"

Mind sharing your insights on what else caused this missing opcache invalidation despite source file changes?

I wish I'd knew something useful, but I can only write something to indicate I've read your request, and I'd gladly help.

I checked multiple times with rg (ripgrep), no validate_timestamps which evaluate to 0 neither in the /etc/php7/ nor in the nextcloud folder (except the doc txt in the latter) in one of my nextcloud servers. Nevertheless, I needed to restart the php-fpm service.

[ChristophWurst]

Try php --info | grep opcache to find your current configuration

[ChristophWurst]

If CLI and web server don't use the same php.ini you might need to invoke php differently.

[Samonitari]

Running php-fpm --nodaemonize --fpm-config /etc/php7/fpm/php-fpm-nextcloud.conf --info | grep opcache (as the service's user, in the nextcloud folder, with nextcloud's php-fpm service stopped) yields the following

opcache.blacklist_filename => no value => no value
opcache.consistency_checks => 0 => 0
opcache.dups_fix => Off => Off
opcache.enable => On => On
opcache.enable_cli => Off => Off
opcache.enable_file_override => Off => Off
opcache.error_log => no value => no value
opcache.file_cache => no value => no value
opcache.file_cache_consistency_checks => On => On
opcache.file_cache_only => Off => Off
opcache.file_update_protection => 2 => 2
opcache.force_restart_timeout => 180 => 180
opcache.huge_code_pages => Off => Off
opcache.interned_strings_buffer => 8 => 8
opcache.lockfile_path => /tmp => /tmp
opcache.log_verbosity_level => 1 => 1
opcache.max_accelerated_files => 10000 => 10000
opcache.max_file_size => 0 => 0
opcache.max_wasted_percentage => 5 => 5
opcache.memory_consumption => 128 => 128
opcache.opt_debug_level => 0 => 0
opcache.optimization_level => 0x7FFEBFFF => 0x7FFEBFFF
opcache.preferred_memory_model => no value => no value
opcache.preload => no value => no value
opcache.preload_user => no value => no value
opcache.protect_memory => Off => Off
opcache.restrict_api => no value => no value
opcache.revalidate_freq => 2 => 2
opcache.revalidate_path => Off => Off
opcache.save_comments => On => On
opcache.use_cwd => On => On
opcache.validate_permission => Off => Off
opcache.validate_root => Off => Off
opcache.validate_timestamps => On => On

[ChristophWurst]

I can't see anything wrong.

[meichthys]

I'm also seeing a similar issue when I upgraded from 25.0.0RC5 to 25.0.1RC1:

I do remember following the tuning guide here: https://docs.nextcloud.com/server/latest/admin_manual/installation/server_tuning.html#enable-php-opcache , but after checking my php-fpm php.ini config, opcache.validate_timestamps is commented out.

Also, as requested above, the MailAccountId attribute does not exist in /var/www/nextcloud/apps/mail/MailAccount.php

The admin apps page indicates I'm on Mail v 2.0.3

I've tried rebooting the machine and restarting the php-fpm service: systemctl restart php8.1-fpm, but with no luck yet.

[ChristophWurst]

Also, as requested above, the MailAccountId attribute does not exist in /var/www/nextcloud/apps/mail/MailAccount.php

The admin apps page indicates I'm on Mail v 2.0.3

The feature was added with 2.1. archiveMailboxId is not in the source code of v2.0.3. I searched locally.

[meichthys]

Ah. ok. i guess i need 2.1.0 which doesn't seem to be available as an update yet. Is there a way to update to RC or beta versions of apps from the admin menu?

[meichthys]

🤦‍♂️ It looks like I must have changed to the stable channel at some point after which i used the nextcloud vm update script to update to an RC version. I'm back on Beta in the UI now and can see v2.1 for Mail now. Sorry for the confusion.