New Nextcloud setup with cron and transactional file locking problems (solved)

I set up Nextcloud on a new instance of Debian, and thought I had added all the pieces for memory cache and file cache, and had set up cron to run php -f /var/www/html/nextcloud/cron.php correctly. But in the Administration Overview screen I was still seeing this:

  • Last background job execution ran 2 hours ago. Something seems wrong.
  • The database is used for transactional file locking. To enhance performance, please configure memcache, if available.

But had installed Redis and APCu and configured them … so what is wrong?

I should mention that I’m using php 8.2. Apparently, with that new version of php, the APCu code now needs an additional setting that wasn’t needed before.

Find your way to /etc/php/8.2/mods-available and edit the apcu.ini file. Add this:


Finally! I have the green check mark: All checks passed.

How to test if you cron job is going to run correctly:

sudo -u www-data php -f /var/www/html/nextcloud/cron.php

I had to add the sudo package to Debian, because the basic server build did not come with that. But what it does do, is let me switch user and do the command. First, I specify the same user that Apache is going to use: www-data and then I run the PHP interpreter, using the file /var/www/html/nextcloud/cron.php

Prior to the change, it erred out with a rather ugly OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

Now after the change it simply runs without reporting anything (everything ran sucessful)

Mildly amusing: 7.3 miles and 13 green lights in a row

I happened to be driving back from Tulare tonight, and wanted to pick up tacos for dinner at BT’s on Mooney Boulevard in Visalia. I waited at the left hand turn signal at the intersection of Tulare Avenue and CA-63 (Mooney) in Tulare. Turned left, put the cruise control on 40 MPH, stayed in the right lane. I didn’t have to tap the brakes or adjust the speed for the next 7.3 miles. Never even hit a yellow light, though for one intersection a cross-traffic car had pulled up so I thought I might. Thirteen green lights in a row. 🙂

Yes, 40 MPH is really slow for this trip. I wasn’t in a hurry, and know that optimal fuel efficiency is around 30 MPH: higher than that and I’m burning fuel to defeat wind resistance. 40 MPH is a fair trade-off. I’m not so slow that I’m a hazard, and Mooney is two or three lanes the whole way.

New OpenSuSE Tumbleweed cannot ssh in

Problem: I’ve installed OpenSuSE Tumbleweed fresh on new hardware, and I cannot log in as root with ssh. The solution is three steps.

I should also mention the symptoms: I could try to log in with ssh root@host and I would get prompted for the password – as if it was going to work. But no matter how many times I put in the password, I would simply get prompted to enter the Password again, as if I had typed it wrong.

I used an ISO of OpenSuSE Tumbleweed and the super easy to use Imagewriter to make a bootable USB. I installed openSuSE Tumbleweed fresh, with the option to delete every existing disk partition no matter what: this is about the simplest OpenSuSE Tumbleweed install I can make. Oh, and I installed it as a server install, without a graphical user environment. It’s going to be a Nextcloud server. Actually, the whole idea of installing Tumbleweed for a server was a bad idea. I’m going to wipe it and install OpenSuSE Leap. Problem is, I’d like to install and configure and the database and Nextcloud from the machine I’m typing this on, and not from the text console attached to the physical hardware. For that, I’m going to need ssh.

Care to guess what doesn’t work out of the box?


  1. cp /usr/etc/ssh/sshd_config /etc/ssh/
  2. edit sshd_config and change the following
    • PermitRootLogin yes
    • PasswordAuthentication yes
  3. reboot now

So, apparently the idea is that allowing root to ssh in with “just” a password is a bad idea. This is why the default settings were changed to make it not work. But this does leave us with a bit of the “pulling ourselves up by our bootstraps” problem: how can I use ssh-copy-id root@host if I cannot complete the operation by logging in as root?

We’ve got to be able to authenticate before the keys can be copied up; otherwise any random bad guy would load their keys in. But if we’re not allowed to authenticate “because passwords are bad”, then we’re not allowed to authenticate….

This is way less of a problem if I’m working on a virtual machine. VMs have a virtual console, and opening that is trivial. I can log in as if I were on the physical console at the same time I have web pages open searching for the way to fix this problem.

But today’s case wasn’t a virtual machine – it was a physical machine in the other room. Without a web browser.

Well, okay, sure, I could install Lynx, but last time I tried, most web sites (including Google) didn’t work. I’m pretty sure the text ssh session doesn’t have a clipboard I could copy/paste “/usr/etc/ssh/sshd_config” to and from, either. But I digress.

The other minor pain point is that there are many articles on the Internet that talk about the PermitRootLogin option and the PasswordAuthentication option. But they say to edit the file: /etc/ssh/sshd_config

That file doesn’t exist there, in a freshly minted ISO from OpenSuSE. They moved it to /usr/etc/ssh because that’s where packages place these files. If someone in the sshd project comes up with a better version, this is where the updated configuration file can be put (without warning) because users are not supposed to store user data in /usr. It’s too much of a hassle to then copy the default file from /usr to /etc without clobbering the user supplied updates: so they don’t. That’s up to me.

But it does mean that the config file I need to edit isn’t there. Gee, thanks.

Now that I have the ssh key copied up to the new server, I’ll go ahead and turn off the root-allowed-to-log-in-with-a-password option.

But man what a PITA it was to get to this point.