Support intro
Sorry to hear you’re facing problems 
help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.
In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:
example
Or for longer, use three backticks above and below the code snippet:
longer
example
here
Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can 
Nextcloud Desktop version (eg, 20.0.5): 3.4.1
Operating system and version (eg, Ubuntu 20.04): manjaro-5.13.19-2-MANJARO
The issue you are facing:
I had major issues with an upgrade (mariadb-related) and decided to cleanly install Nextcloud from scratch using Postgres as a backend. Everything worked fine, but in order to restore the file system I am trying to sync files back from desktop to to the server. For about 75% of these files it’s worked without issue, but the large swathes of important and files just don’t sync. I only noticed when I ran out of disk space in my home dir, and it was because the sync client had created logs of over 80GB in ~/.config/Nextcloud/logs.
Here is an excerpt from the CLIENT LOG:
[ debug nextcloud.gui.socketapi /build/nextcloud-client/src/nextcloud-client/src/gui/socketapi/socketapi.cpp:205 ] [ OCC::SocketListener::sendMessage ]: Sending SocketAPI message --> "STATUS:NOP:/home/simon/Nextcloud/Document Archi
ve/Sharepoint/Invoices Bills Receipts Scans/inv24092020-04-14-26_0001.pdf" to QLocalSocket(0x7f5098459790)
2022-01-09 14:20:40:399 [ info nextcloud.gui.socketapi /build/nextcloud-client/src/nextcloud-client/src/gui/socketapi/socketapi.cpp:362 ]: Received SocketAPI message <-- "RETRIEVE_FILE_STATUS:/home/simon/Nextcloud/Document Archive/Sharepoint/Invoices Bills
Receipts Scans/inv24092020-04-21-28_0001.pdf" from QLocalSocket(0x7f5098459790)
2022-01-09 14:20:40:399 [ debug nextcloud.sync.database.sql /build/nextcloud-client/src/nextcloud-client/src/common/ownsql.h:145 ] [ OCC::SqlQuery::bindValue ]: SQL bind 1 -9216054451900880633
2022-01-09 14:20:40:399 [ debug nextcloud.sync.database.sql /build/nextcloud-client/src/nextcloud-client/src/common/ownsql.cpp:295 ] [ OCC::SqlQuery::exec ]: SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildr
enRemote, contentchecksumtype.name || ':' || contentChecksum, e2eMangledName, isE2eEncrypted FROM metadata LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
These errors appeared after I manually dragged and dropped some files that I wanted to restore to their correct locations. There doesn’t appear to be any consistency to the issue as a directory full of scanned documents with the same naming convention might have 8/40 sync’d in one folder, but 40/40 in another.
There’s seems to be two types of errors appearing on the admin side. One related to folder scanning and the other md5 checksums.
Please see below from the SERVER LOG
This relating to checksums:
{"reqId":"Ii812VozQ3tfG2Zigyqu","level":3,"time":"2022-01-09T14:20:21+00:00","remoteAddr":"10.5.4.71","user":"OMITTED","app":"no app in context","method":"POST","url":"/remote.php/dav/bulk","message":"Computed md5 hash is incorrect.","userAgent":"Mozilla/5.0 (Linux) mirall/3.4.1git (Nextcloud, manjaro-5.13.19-2-MANJARO ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"23.0.0.10","id":"61daf31dc2930"}
And this which I believe is related to the parsing and subsequent file upload of the local directory contents:
{"reqId":"drJo8boCvZXxk4Obgi5y","level":4,"time":"2022-01-09T14:22:29+00:00","remoteAddr":"10.5.4.71","user":"simon.greer","app":"webdav","method":"POST","url":"/remote.php/dav/bulk","message":"Unknown error while seeking content","userAgent":"Mozilla/5.0 (Linux) mirall/3.4.1git (Nextcloud, manjaro-5.13.19-2-MANJARO ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"23.0.0.10","exception":{"Exception":"Sabre\\DAV\\Exception","Message":"Unknown error while seeking content","Code":500,"Trace":[{"file":"/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php","line":129,"function":"isAt","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->","args":["--boundary_.oOo._HjrVbhS7RHbXLIxGCSqmXqVYiCRSdrSM--\r\n"]},{"file":"/var/www/html/apps/dav/lib/BulkUpload/BulkUploadPlugin.php","line":69,"function":"isAtLastBoundary","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->","args":[]},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPost","class":"OCA\\DAV\\BulkUpload\\BulkUploadPlugin","type":"->","args":[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->","args":["method:POST",[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/lib/Server.php","line":339,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":166,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php","Line":111,"CustomMessage":"--"},"id":"61daf31dc28f4"}
I’m pretty much at my wit’s end with this and could really do with some help. I’ve reinstalled Nextcloud from scratch twice now and am stuck for ideas. I’ve tried repairing files, DB, etc. but gotten nowhere. What confuses me, is if there are no local config files or file-based indices (I’ve selectively only moved the files that are actually genuine and nothing else), and the database is completely new, how does the new installation have any awareness of file state/locking etc.?
LDAP is switched on, and the first thing that I do is change the username mapping to UID (from UUID) as it’s a nightmare trying to use DAV and the uniqueness is not an issue for us. I don’t think that’s relevant, but I thought I’d mention it all the same.
Help very much appreciated.
Server:
| Operating System: | Linux 5.13.19-2-pve x86_64 |
|---|---|
| CPU: | Intel(R) Xeon(R) CPU E5-2650L v4 @ 1.70GHz (28 cores) |
| Memory: | 157.00 GB |
PHP 8.0.14
Memory Limit: 512 MB
Max Execution Time: 3600
Upload max size: 512 MB
DB pgsql
PostgreSQL 14.1 (Debian 14.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
85.7 MB
Running in a priveleged LXC container. Reverse proxied through Traefik with Middleware configured as follows:
middlewares:
nextcloud-redirectregex:
redirectRegex:
permanent: true
regex: "https://(.*)/.well-known/(card|cal)dav"
replacement: "https://${1}/remote.php/dav/"
nextcloud-stsheaders:
headers:
stsSeconds: "15552000"
stsIncludeSubdomains: "true"
stsPreload: "true"
accesscontrolalloworigin: "*"
customresponseheaders:
X-Frame-Options: "SAMEORIGIN"