Nextcloud still thinks its running on 32-bit after upgrade to 64-bit

Hey there! :v:

I’ve finally had some time to upgrade my RaspberryPi (and the nextcloud running on it) to 64-bit. :partying_face:
But unfortunately after the upgrade I’m getting a warning that NC is running on 32-bit PHP, which is confusing.

Message shown in "Security & setup warnings":
  • It seems like you are running a 32-bit PHP version. Nextcloud needs 64-bit to run well. Please upgrade your OS and PHP to 64-bit! For further details read the documentation page about this :arrow_upper_right:.

What I did:

  1. After some thought I decided a fresh install is probably easiest and safest to accomplish.
  2. I setup a fresh Raspberry Pi OS 64-bit on a new ssd and copied all nextcloud files and the db to it preserving all user/group/permission settings.
  3. Started nextcloud and db via docker, just the way I did the past years.
  4. Upgraded to NC25.
  5. Hotfixed the “Cannot access files” error as described here.

Thanks for any help in advance.

Nextcloud version (eg, 20.0.5): 25.0.1
Operating system and version (eg, Ubuntu 20.04): Raspberry Pi OS
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.54
PHP version (eg, 7.4): PHP 8.1.13

The issue you are facing:
Nextcloud thinks its 32-bit, but actually isn’t

Is this the first time you’ve seen this error? (Y/N):
Yes

Steps to replicate it:

Hard to tell, look above for what I did…

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'instanceid' => '*******',
  'passwordsalt' => '*******',
  'secret' => '*******',
  'trusted_domains' =>
  array (
    0 => '*******',
  ),
  'trusted_proxies' =>
  array (
    0 => '*******',
  ),
  'overwriteprotocol' => 'https',
  'overwritehost' => '*******',
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'pgsql',
  'version' => '25.0.1.1',
  'overwrite.cli.url' => '*******',
  'dbname' => '*******',
  'dbhost' => '*******',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => '*******',
  'dbpassword' => '*******',
  'installed' => true,
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => '*******',
  'mail_domain' => '*******',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtphost' => '*******',
  'mail_smtpport' => '*******',
  'mail_smtpauth' => 1,
  'mail_smtpname' => '*******',
  'mail_smtppassword' => '*******',
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
);

Please check:

getconf LONG_BIT
uname -m
cat /proc/cpuinfo | grep lm
2 Likes

Okay, I think I got it now… I kinda feel stupid. Seems like I did not choose the right image. I have adjusted my docker-compose file at some point but must’ve reverted it during the upgrade process… Currently having the arm32v7 images running. Will try to run the arm64v8 images and report back. Just waiting for another backup before I do something stupid…

Thanks a ton for the hint, I realized that getconf LONG_BIT differed for host and container. :man_facepalming:

Edit:
Okay, it’s resolved. My bad…