Skip extra file check during upgrade (security.txt gets in the way)

Hey Nextcloud community,

When updating using the web updater, Nextcloud checks for extra or unexpected files.

For our servers, we are deploying a security.txt in the root of our domains, as per RFC 9116 (see security.txt - Wikipedia).

Unfortunately, the updater does not recognize this security.txt and thus fails the integrity check.

Is there any way to either skip this check, or add the security.txt as an exception?

I get why this check is there, it makes sense. But for now, I can only move the security.txt in some other folder and back after the update. That means I cannot use the web GUI, but always have to have a SSH connection open as well.
That kinda sucks. :frowning:

This question has been asked a few times, but usually it’s about folders like “cgi-bin” or “.well-known” that really shouldn’t be there. With security.txt, there’s no other place to put it.

Maybe someone has a solution or workaround for this?
Thanks in advance!


Afaik (or at least I couldn’t find anything), you can only disable the integrity check globally by adding the following line to the config.php, which I wouldn’t recommend doing on a production system:

'integrity.check.disabled' => true,

The CLI updater is more reliable anyways. I would create a small bash script and create a bash alias for it, so you can upgrade with one simple command.


mv /var/www/nextcloud/security.txt ~/
sudo -u www-data php /var/www/nextcloud/updater/updater.phar --no-interaction
mv ~/security.txt /var/www/nextcloud
exit 0

Ok thanks, I’ll check both solutions out.

The bash script is certainly the more elegant solution, probably a good way to automate updates, too. Didn’t think about that tbh…

Again, many thanks!

Well, I’m not sure that’s a good idea in general, unless maybe if there’s a way to update to minor versions only, which I haven’t found either, or at least I couldn’t find a documented option in the updater.phar to do so.

Of course, you could query the output of occ update:check in a script, so that it only runs the updater.phar if the main version remains the same.

But then you’d still have the problem that if an update gets stuck for some reason, and you don’t have access to your server at the time, Nextcloud may be unavailable until you get access again to troubleshoot the issue.

So, to be honest, I wouldn’t fully automate it, but that’s of course up to you… :slight_smile:

Thanks for the heads up, but I think in our case that’s okay… or, a risk I can live with. Triggering this via pipeline etc. beats logging on to a growing number of servers manually :slight_smile:

We do have a close content-based HTTPS monitoring, so if an upgrade fails and NC is stuck in maintenance mode, we’ll get a message and start troubleshooting. That should be well within our SLAs. Fingers crossed! :smile:

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.