I am having some issues with general client (desktop and web) usage. None of the issues can be replicated on demand and are very unusual form my experience of both nextcloud and owncloud.
All of these errors imply that I have to, at least once a week, clear specific (and always distinct) oc_filecache entries generating errors on the Nextcloud client and leading to some unexpected behavior while using the nextcloud webpage for the same purpose. I usually avoid touching the database for web applications that I have not written myself, but these index/cosmetic errors are too much of an eyesore.
The most frequent errors I have gotten on the client are:
- The file has been deleted from the server (translated from portuguese)
- Not permitted, because you do not have permission to add files to this folder (translated from portuguese)
- I can conclude that oc_filecache records are not being removed/updated after some files are moved/renamed/deleted. I have found that both the old and new filename exist on oc_filecache after a rename
- I only remove records that show up as an error in the client and have no corresponding filesystem file on the server. I have done ~10 removals spread over 3 weeks. Maybe a lotal of 20 records.
- after removing the bad record, the client shows a green checkmark as it should
- running the ‘occ’ file:scan and cleanup tools has produced no results. After analyzing the code, I understood that these will only create records
- sometimes, the file:scan tool will add a new record for the final name of a renamed file. In this case, the old record is kept
- files were never renamed manually on the CLI of the server
- when this happens for a folder, accessing the folder in the web interface, sends you back to the default webpage (owncloud.domain.tld)
- when this happens for a file, accessing the file in the web interface, a 404 is returned with information: remote address and request ID. I have not been able to ma
- I have searched this issue extensively on this issue and the most similar results are the following:
File was deleted from server, but still visible on web-ui (also for desktop-client)
OCC files:cleanup - Does it delete the db table entries of the missing files?
Fastest way to remove large number of filecache entries
Unfortunately, the most useful logs between (webserver, nginx, nextcloud, audit and client) have been those of the client. Others are barren at the times the issue happens. Audit logs shows similar information than oc_activity about the troublesome renames and removes. It is always nominal compared to other instances.
Nextcloud Server version (eg, 18.0.2): 18.0.2
Nextcloud Desktop version (eg, 18.0.2): 2.4.3
Operating system and version (eg, Ubuntu 20.04): OpenBSD 6.6
Apache or nginx version (eg, Apache 2.4.25): nginx 1.16.1
PHP version (eg, 7.1): php 7.3.16
RDBMS: postgresql 11.7
Storage: local filesystem storage, no additional features
Additional features: LDAP integration for user management and authentication only.
The issue you are facing:
I am facing various client issues with a slightly larger server that I am running. See the top of this post.
Is this the first time you’ve seen this error? (Y/N):
Yes, I started seeing this errors after migrating all the way from Owncloud 9. The first instances of the error only showed up after 3 weeks to a month. Over 2 months after the upgrade, the errors keep comming up. Other instances do not have this error.
Steps to replicate it:
Cannot replicate on demand. Issue is always related to moving or renaming files.
The output of your Nextcloud log in Admin > Logging:
No records at the time of the rename events.
The output of your config.php file in
/path/to/nextcloud (make sure you remove any identifiable information!):
<?php $CONFIG = array ( 'integrity.check.disabled' => true, 'instanceid' => 'INSTANCEID', 'passwordsalt' => 'SALT', 'secret' => 'SECRET', 'trusted_domains' => array ( 0 => 'owncloud.domain.TLD', 1 => 'nextcloud.domain.tld', 2 => 'cloud.domain.tld', ), 'datadirectory' => ((php_sapi_name () == 'cli')? '/var/www': '') . '/nextcloud/data', 'overwrite.cli.url' => 'https://owncloud.domain.tld', 'version' => '184.108.40.206', 'dbtype' => 'pgsql', 'dbname' => 'owncloud', 'dbhost' => '127.0.0.1:5432', 'dbtableprefix' => 'oc_', 'dbuser' => 'DBUSER', 'dbpassword' => 'DBPASSWORD', 'logtimezone' => 'UTC', 'installed' => true, 'loglevel' => 1, 'ldapIgnoreNamingRules' => false, 'memcache.local' => '\\OC\\Memcache\\Redis', 'filelocking.enabled' => 'true', 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => 'localhost', 'port' => 6379, 'timeout' => 0, 'password' => '', 'dbindex' => 0, ), 'mail_from_address' => 'FROMADDRESS', 'mail_smtpmode' => 'sendmail', 'mail_domain' => 'domain.tld', 'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory', 'maintenance' => false, 'default_locale' => 'pt', 'lost_password_link' => 'disabled', 'mail_sendmailmode' => 'pipe', );
The output of your Apache/nginx/system log in
No relevant logs in either HTTP, HTTPS or error logs. While cross-referencing other logs, I can see there are no timeouts.
The output of your audit.log:
Only records showing that the file was in fact moved or deleted.
I bet there is more info I could include in this post, but I cannot see what else might be relevant right now. This not a new instance as I have show, so I can include some details about its past.
The only paths I see towards a solution are:
- reinstall the server. Not sure how this would help. My resource constraints make it more acceptable to keep fixing these errors as they come up
- nuke and rebuild oc_filecache. Not sure how this would really help in the long run as some of the emerging problems seem to be about files being renamed
- reinstall desktop clients. I fail to see how this would avoid these issues in oc_filecache, but it is my best bet considering that we upgraded client in-place (keeping files as documented elsewhere on these forums) between owncloud and nextcloud. This is mostly FUD speaking.