Like a lot of users with very small instances, my instance is only used by my family (4 persons), and no one uses it a whole lot. As recommended in the manual, I use APCu for data caching ('memcache.local' => '\OC\Memcache\APCu').
Like others, am annoyed by the message “The database is used for transactional file logging” in “Security & setup warnings”. In my usecase, there’s no need for redis. Using APCu for locking isn’t a good idea (as explained somewhere here in the forum), so that’s not an option.
I searched quite a bit, but sadly, there doesn’t seem to be a way to get rid of the message.
So to not be constantly annoyed by this message, I patched /apps/settings/lib/SetupChecks/FileLocking.php to only display the message if the instance has more than 5 users.
This is a bit of a hack and I’m not sure if I did this correctly, but that’s what I could come up with, given my quite limited understanding of nextcloud and php. Works like a charm on my
Leaving this for everyone running a small instance and getting annoyed at this message.
--- FileLocking.php~ 2024-11-07 08:37:48.000000000 +0100
+++ FileLocking.php 2024-12-09 18:16:51.641194237 +0100
@@ -41,6 +41,21 @@
return ($this->lockingProvider instanceof DBLockingProvider);
}
+ private function countSeenUsers() {
+ $queryBuilder = \OC::$server->getDatabaseConnection()->getQueryBuilder();
+ $queryBuilder->select($queryBuilder->func()->count('*'))
+ ->from('preferences')
+ ->where($queryBuilder->expr()->eq('appid', $queryBuilder->createNamedParameter('login')))
+ ->andWhere($queryBuilder->expr()->eq('configkey', $queryBuilder->createNamedParameter('lastLogin')));
+
+ $query = $queryBuilder->execute();
+
+ $result = (int)$query->fetchOne();
+ $query->closeCursor();
+
+ return $result;
+ }
+
public function run(): SetupResult {
if (!$this->hasWorkingFileLocking()) {
return SetupResult::warning(
@@ -50,10 +65,12 @@
}
if ($this->hasDBFileLocking()) {
- return SetupResult::info(
- $this->l10n->t('The database is used for transactional file locking. To enhance performance, please configure memcache, if available.'),
- $this->urlGenerator->linkToDocs('admin-transactional-locking')
- );
+ if ($this->countSeenUsers() > 6) {
+ return SetupResult::info(
+ $this->l10n->t('The database is used for transactional file locking. To enhance performance, please configure memcache, if available.'),
+ $this->urlGenerator->linkToDocs('admin-transactional-locking')
+ );
+ };
}
return SetupResult::success();
Ultimately, it’s about performance, as Nextcloud does transactional file locking anyway, but if Redis is not configured, it uses the database for this functionality, which has two main drawbacks that become more significant the more users are working at the same time:
The process itself is slower, because an in-memory database like Redis, which works entirely in RAM, is much faster than a traditional database that writes each transaction to disk.
Relying on the database for file locking adds additional load, potentially impacting other database operations, which can reduce the overall performance of the system, especially under heavy use.
Why not use the time needed changing the code after every Nextcloud update to setup Redis once, and maybe even benefit from a performance boost that Redis might bring?
I mean, if it is recommended for an SMB server, it certainly cannot hurt to have it on a home server, right? …unless maybe you server is very limited in available RAM.
Yes, of course, any additional service running on a server introduces potential new security risks. On the other hand, the potential attack vectors can be greatly minimized by the following measures:
Don’t expose Redis over TCP, but only on localhost via UNIX socket.
Do not share the same Redis instance with other applications, or even better, use a separate VM exclusively for Nextcloud.
Run Redis as a dedicated user with low privileges (default in most distributions).
Set the correct permissions on the socket file
Enable authentication
You could further restrict it with ACLs or, if you really want to get fancy, SELinux or AppArmor, which imho shouldn’t be necessary on a home server, especially if the previous points, especially #2 have been followed.
This should eliminate most potential attack vectors against Redis on a home server, and it would certainly not be possible to remotely exploit any vulnerabilities in Redis directly.
But of course, the most secure services are always those that are not running at all.
If you really have just a small setup and you are not restricted by the performance draw back, I can see that you don’t want to run an extra service. It uses resources, needs to be updated, … and in the admin settings, there is just a warning, that the performance might be less than it could be in an optimized setup.
But this warning is just shown on the admin page? What is all the fuzz about to remove it? Perhaps it would be a good improvement, to be able to ignore it so it just shows up again on after the next update.
Yeah sure, and If you have very little memory (<2GB), it may even be counterproductive.
Of course I don’t mind if someone is modifing the code to make the message disappear, and if they don’t want to or can’t use Redis that’s of course fine too.
Yep. The ability to acknowledge messages so that they no longer appear on the “Settings and Alerts” page would indeed be a nice feature, and it would be especially useful for the log counter, because as it is now, you get warned for a week for the same log messages even if you’ve already acknowledged them, which makes the log counter much less useful than it could be.
This is exactly what has been requested several times on this forum and I also found at least 1 issue on github - but for reasons unbeknownst to me, devs don’t seem inclined to consider doing this.
Feel free to link the topic on github here, so people in the same situation can give it a thumbs up.
I’d rather look in a more general approach to improve the system, because just the file locking can quickly become the problem and if you quickly click the warning away, you are not even aware of the issue.
Especially when gathering information for problem descriptions here or on github, such information is important.
Perhaps because at the end of the day it’s a cosmetic issue that doesn’t affect the actual functionality of your Nextcloud in any way, and their full-time developers probably need to focus on implementing features that add real value for their paying customers, and/or fixing actual bugs that affect the core functionality.
However, if someone from the community wants to implement it and submits a pull request, who knows, maybe it will be merged, or maybe it could be done with an app?
…unless maybe you server is very limited in available RAM.