There are some errors regarding your setup. (admin/overview)

ℹ️ Support
,
1

Nextcloud version (eg, 20.0.5): Nextcloud Hub 3 (25.0.3)
Operating system and version (eg, Ubuntu 20.04): Debian GNU/Linux 11 (bullseye)
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.54
PHP version (eg, 7.4): PHP 7.4.33

The issue you are facing: Moving servers from CentOS7 (vmware exsi) to Debian 11 (proxmox ve), I built a new OS, completely installed all pre-reqs for NextCloud on the new Debian VM. Then put my old system in maintenance mode, after this I rsync the ‘nextcloud’ folder found in ‘/var/www’ to the new Debian VM (place back into ‘/var/www’). Dumped the mariadb ‘nextcloud’ database and rsync it as well to the new Debian VM and then imported it into the running mariadb service. Ran a recursive chown on the ‘nextcloud’ folder to make sure the user was correct for the ‘apache2’ service. (which on rsync -Aaxvt)

After doing all these steps, nextcloud started up and I started seeing this error.

There are some errors regarding your setup.

It was not possible to execute the cron job via CLI. The following technical errors have appeared:

* Your data directory is invalid. Ensure there is a file called ".ocdata" in the root of the data directory.
* Cannot write into "apps" directory. This can usually be fixed by giving the web server write access to the apps directory or disabling the App Store in the config file.
* Your data directory is not writable. Permissions can usually be fixed by giving the web server write access to the root directory. See https://docs.nextcloud.com/server/25/go.php?to=admin-dir_permissions.

A background job is pending that checks for user imported SSL certificates. Please check back later.

You are currently running PHP 7.4.33. Upgrade your PHP version to take advantage of performance and security updates provided by the PHP Group ↗ as soon as your distribution supports it.

I went ahead setup my SSL which works, I only have three (3) users all which can login and upload/download with no problems. I even upgraded the server from 25.0.1 to 25.0.3 without any issues.

I’ve checked and the ‘.ocdata’ is in the data directory.
I’ve updated / verified that the database table ‘oc_storages’ is correct.

Pretty, much just stuck with these errors at this point. Not sure what to check next.

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

Steps to replicate it:

  1. Listed above…
  2. Leaving below empty since, I see nothing in the logs error wise.

The output of your Nextcloud log in Admin > Logging:

PASTE HERE

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

PASTE HERE

The output of your Apache/nginx/system log in /var/log/____:

PASTE HERE

PASTE HERE


Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

PASTE HERE
2

ended up clearing all the logs. restarted the server, still nothing in the logs showing what could be the problem. so I went over everything from the start to end and found that I missed putting in the cron job. after finding the right setting and rebooting server, all started working as intended.

example, of what I did before reboot…

crontab -u www-data -e

# append this line at the bottom of the file:

5 * * * * php -f /var/www/nextcloud/cron.php

#
^--- added this below the cron.php line (or saving will fail)

# save and quit

# then ran manually
sudo -u www-data php -f /var/www/nextcloud/cron.php

reboot now
3

and the fat you moved between different distributions make me think something is bad with you file permissions. Please double check files and directories are owned by the web server user and the user can read and write the files…

Take a look at https://docs.nextcloud.com/server/latest/admin_manual/maintenance/migrating.html this might include useful advice.

4

Yeah this is one of the links I had read prior to doing the move. But still had to correct quite a bit as far as permission and including the one entry in the DB. Still not exactly sure what the cron job does, but it did seem to do the trick. Servers been up and running smooth now, like nothing happened.