[Solved] Setting up Nextcloud: OCC, Cron

I have installed Nextcloud Hub 9 (30.0.1) and I am exploring its many functions.

Several of the recommendations the package gives require command line use of occ. I have not been able to get that to work even when running it from the directory nextcloud is installed in.

I thought I might get around that by installing their occ web app but when run that produces an internal error.

I wonder whether there is some special process involved in giving the system occ commands when nextcloud is running on freedombox.

I am not sure whether this question belongs here or on a nextcloud forum?

Ken

Debian GNU/Linux 12 (bookworm) and FreedomBox version 24.22. FreedomBox is up to date.
8x Intel(R) Core™ i7-9700 CPU @ 3.00GHz
500g sd main drive, 2T ssd drive plugged into USB-C and 4T USB drive plugged in to USB

You can run occ commands like this:
sudo podman exec --user 33 nextcloud-freedombox /var/www/html/occ

Several of the recommendations the package gives require command line use of occ.

What do you mean by this? It shouldn’t be necessary to use occ manually. Can you give us an example where you saw this?

1 Like

Nice, thanks for that. That seems to work, now I get all the occ help stuff on the screen so it looks like I should be able to use it. .

Sorry my explanation for my use of occ was not sufficient. Here are the things I am trying to do using occ. They come from the Administration | Overview - Setup and Overview nextcloud screen.

It tells me I have 9 errors in the log (will look at those in a bit) and then goes on to detail 4 things:

  • Server has no maintenance window start time configured. This means resource intensive daily background jobs will also be executed during your main usage time. We recommend to set it to a time of low usage, so users are less impacted by the load caused from these heavy tasks. For more details see the [documentation :arrow_upper_right:] When I go to the documentation for this item, it wants me to use occ to set the maintenance window start time. You mention that I shouldn’t need to use occ manually. Is there another way to fix this?

  • One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command occ maintenance:repair --include-expensive to perform the migrations. Is this something I should go ahead and do manually?

  • Some headers are not set correctly on your instance - The Strict-Transport-Security HTTP header is not set (should be at least 15552000 seconds). For enhanced security, it is recommended to enable HSTS. For more details see the documentation :arrow_upper_right:. It recommends settings in the Apache VirtualHost file. At Hardening and security guidance — Nextcloud latest Administration Manual latest documentation I see that this looks like a good idea but takes a while to reverse if it causes a problem. It doesn’t seem to involve occ, but I am not sure. Can I just edit the mentioned file to add the recommended code? Where would I find the file to edit?

  • Detected some missing optional indices. Occasionally new indices are added (by Nextcloud or installed applications) to improve database performance. Adding indices can sometimes take awhile and temporarily hurt performance so this is not done automatically during upgrades. Once the indices are added, queries to those tables should be faster. Use the command occ db:add-missing-indices to add them. Missing indices: “mail_messages_strucanalyz_idx” in table “mail_messages”, “mail_class_creat_idx” in table “mail_classifiers”, “mail_acc_prov_idx” in table “mail_accounts”, “mail_alias_accid_idx” in table “mail_aliases”, “systag_by_objectid” in table “systemtag_object_mapping”, “mail_messages_mb_id_uid_uidx” in table “mail_messages”, “mail_smime_certs_uid_email_idx” in table “mail_smime_certificates”, “mail_trusted_senders_idx” in table “mail_trusted_senders”, “mail_coll_idx” in table “mail_coll_addresses”. For more details see the documentation :arrow_upper_right:. Looking at the docs linked, I have the idea that this is something the system will take care of itself and that these steps are only to control when this maintenance is done to avoid busy times. Am I on the right track about that or should I dig into the suggested occ commands?

When I run OCC Web from the Nextcloud screen, I get this:

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: [my ip addr]
  • Request ID: [code here snipped]

Thanks for your help with this.

Ken

This one also shows up on the Administration | Overview - Setup and Overview nextcloud screen.

The PHP OPcache module is not properly configured. The OPcache buffer is nearly full. To assure that all scripts can be hold in cache, it is recommended to apply “opcache.memory_consumption” to your PHP configuration with a value higher than “128”… For more details see . . .

This shows up sometimes, but seemed to disappear today, perhaps because the system updated to the latest point version overnight. After adding some further apps just now, it has come back. Not sure what I need to do with that item.

I have messed things up now!

I wanted to address the issues issue in Overview about setting up a time window in cron to do some tasks.

I went to this page Background jobs — Nextcloud latest Administration Manual latest documentation and used the commands there to set up cron using the command crontab -u www-data -e

After I made the recommend change, I followed the recommend step to confirm and this was the result:

ken@fbox:~$ sudo crontab -u www-data -l
[sudo] password for ken:
#[snip]
*/5 * * * * php -f /var/www/nextcloud/cron.php

Not knowing I had broken cron, I went ahead to install a couple of apps including OneDrive Integration and it failed producing errors like these:

[files_external_onedrive] Fatal: Error during app loading: Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found
GET /nextcloud/index.phpps/richdocuments/settings/fonts.json
from 24.69.89.88 by – at Nov 9, 2024, 4:18:56 PM

[files_external_onedrive] Fatal: Error during app service registration: Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found
GET /nextcloud/index.phpeader/api/poll?lastReqId=Hk19NaaxaiJSceDuSYu6
from 24.69.89.88 by – at Nov 9, 2024, 5:00:51 PM

I disabled that app in the NC gui but it would not let me remove the app. Going back to the logs I see thousands of entries now:

|Fatal|files_external_onedrive|Error Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found

Error during app service registration: Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found|
| — | — |

Nov 9, 2024, 5:41:47 PM

|Fatal|files_external_onedrive|Error Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found

Error during app loading: Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found|
| — | — |

Nov 9, 2024, 5:41:46 PM

|Fatal|files_external_onedrive|Error Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found

Error during app service registration: Interface “OCA\Files_External\Lib\Config\IBackendProvider” not found|
| — | — |

Nov 9, 2024, 5:41:46 PM

Those are still coming in even though the app has been disabled.

When I go to Overview now I see the warning I was trying to fix about cron I was trying to deal with is now preceded by new warnings:

  • Last background job execution ran 1 hour ago. Something seems wrong. Check the background job settings.

  • 6033 errors in the logs since November 8, 2024, 10:32:45 PM

  • Server has no maintenance window start time configured. This means resource intensive daily background jobs will also be executed during your main usage time. We recommend to set it to a time of low usage, so users are less impacted by the load caused from these heavy tasks. For more details see the documentation :arrow_upper_right:.

The FB log system also says:

Nextcloud cron.php job

Status

Static

Failed to start

Path

/lib/systemd/system/nextcloud-cron-freedombox.service

Triggered by

Service logs

November 9, 2024

5:21 PM

nextcloud-cron-freedombox.service: Unit process 4951 (podman) remains running after unit stopped.

systemd

5:21 PM

nextcloud-cron-freedombox.service: Unit process 4947 (conmon) remains running after unit stopped.

systemd

5:21 PM

nextcloud-cron-freedombox.service: Failed with result ‘exit-code’.

systemd

5:21 PM

nextcloud-cron-freedombox.service: Main process exited, code=exited, status=1/FAILURE

systemd

5:21 PM

2024-11-09 17:21:58.930209927 -0800 PST m=+0.337489713 container exec_died 9e2ce48c55a04051f031c3b98596d20ecf1a840e47f77576ccfc3d8b226afdf1 (image=docker.io/library/nextcloud:stable-fpm, name=nextcloud-freedombox, PODMAN_SYSTEMD_UNIT=nextcloud-freedombox.service, io.containers.autoupdate=registry)

podman

5:21 PM

#11 {main}

podman

5:21 PM

#10 /var/www/html/cron.php(148): OC\BackgroundJob\JobList->getNext(false, NULL)

podman

I guess when they say break it and you get to keep both pieces, they were thinking of me!

No idea where to go from here . . . .

Ken

I am wondering whether it might be best to remove NC altogether and reinstall it?

I am well beyond my depth here . . . .

In cockpit, under Services, there is a red flag and this item:

Nextcloud cron.php job Failed to start Static

Clicking on it, I see these recent log items:

Service logs

November 9, 2024

7:56 PM

nextcloud-cron-freedombox.service: Unit process 18167 (podman) remains running after unit stopped.

systemd

7:56 PM

nextcloud-cron-freedombox.service: Unit process 18162 (conmon) remains running after unit stopped.

systemd

7:56 PM

nextcloud-cron-freedombox.service: Failed with result ‘exit-code’.

systemd

7:56 PM

nextcloud-cron-freedombox.service: Main process exited, code=exited, status=1/FAILURE

systemd

7:56 PM

2024-11-09 19:56:32.342334206 -0800 PST m=+0.291374366 container exec_died 9e2ce48c55a04051f031c3b98596d20ecf1a840e47f77576ccfc3d8b226afdf1 (image=docker.io/library/nextcloud:stable-fpm, name=nextcloud-freedombox, PODMAN_SYSTEMD_UNIT=nextcloud-freedombox.service, io.containers.autoupdate=registry)

podman

7:56 PM

#11 {main}

podman

7:56 PM

#10 /var/www/html/cron.php(148): OC\BackgroundJob\JobList->getNext(false, NULL)

podman

7:56 PM

#9 /var/www/html/lib/private/BackgroundJob/JobList.php(197): OC\BackgroundJob\JobList->buildJob(Array)

podman

7:56 PM

#8 /var/www/html/lib/private/BackgroundJob/JobList.php(288): OCP\Server::get(‘OCA\Files_exter…’)

podman

7:56 PM

#7 /var/www/html/lib/public/Server.php(39): OC\AppFramework\Utility\SimpleContainer->get(‘OCA\Files_exter…’)

podman

Server has no maintenance window start time configured.

This warning is safe to ignore. Unless you have thousands of user, this shouldn’t matter.

One or more mimetype migrations are available. and Detected some missing optional indices.

These are safe to fix from occ, but on the dev side we should take care of this automatically in some next release.

Some headers are not set correctly on your instance

If you set the Override domain on the FreedomBox interface, this will disappear.

Setting up cron jobs on your own is unnecessary: your Nextcloud already does that with systemd-timers. Look at the output of $ sudo systemctl list-timers and see nextcloud-cron-freedombox.timer. You should delete whatever cronjob you created after which all those logs should stop generating.

2 Likes

Thanks! Interesting and useful.

1 Like