server
server copied to clipboard
nextcloud
`Sabre\DAV\Exception` `Unknown error while seeking content` upload error leads to client freeze
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Steps to reproduce
- Installed Nextcloud Hub II and Desktop Client 3.4.1
- The client freezes when trying to upload a changed file.
- Currently not clear which condidition triggers the error. The log message is unspecific.
Expected behaviour
The client should sync the file with the server.
Actual behaviour
The client freezes. See this related issue: https://github.com/nextcloud/desktop/issues/4106
Server configuration
Operating system: Ubuntu 18.04.6 LTS (Bionic Beaver) Nextcloud version: (see Nextcloud admin page) version: 23.0.0.10 Updated from an older Nextcloud/ownCloud or fresh install: Upgraded since OwnCloud 5 or 6…
Logs
Web server error log
Web server error log
Dez 28 17:09:43 jarvis Nextcloud[21403]: {"reqId":"0hgEj8EYAmtZMK2RzNhl","level":4,"time":"2021-12-28T17:09:43+01:00","remoteAddr":"IP_ADDRESS_REDACTED","user":"lars","app":"webdav","method":"POST","url":"/remote.php/dav/bulk","message":"{\"Exce
ption\":\"Sabre\\\\DAV\\\\Exception\",\"Message\":\"Unknown error while seeking content\",\"Code\":500,\"Trace\":[{\"file\":\"/var/www/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php\",\"line\":129,\"function\":\"isAt\",\"cl
ass\":\"OCA\\\\DAV\\\\BulkUpload\\\\MultipartRequestParser\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php\",\"line\":69,\"function\":\"isAtLastBoundary\",\"class\":\"OCA\\\\DAV\\\\BulkUploa
d\\\\MultipartRequestParser\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php\",\"line\":89,\"function\":\"httpPost\",\"class\":\"OCA\\\\DAV\\\\BulkUpload\\\\BulkUploadPlugin\",\"type\":\
"->\"},{\"file\":\"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php\",\"line\":472,\"function\":\"emit\",\"class\":\"Sabre\\\\DAV\\\\Server\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php\"
,\"line\":253,\"function\":\"invokeMethod\",\"class\":\"Sabre\\\\DAV\\\\Server\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php\",\"line\":321,\"function\":\"start\",\"class\":\"Sabre\\\\DAV\\\\Serv
er\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/apps/dav/lib/Server.php\",\"line\":339,\"function\":\"exec\",\"class\":\"Sabre\\\\DAV\\\\Server\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/apps/dav/appinfo/v2/remote.php\",\"lin
e\":35,\"function\":\"exec\",\"class\":\"OCA\\\\DAV\\\\Server\",\"type\":\"->\"},{\"file\":\"/var/www/nextcloud/remote.php\",\"line\":166,\"args\":[\"/var/www/nextcloud/apps/dav/appinfo/v2/remote.php\"],\"function\":\"require_once\"}],\"
File\":\"/var/www/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php\",\"Line\":111,\"CustomMessage\":\"--\"}","userAgent":"Mozilla/5.0 (Linux) mirall/3.4.1git (Nextcloud, arch-5.15.11-arch2-1 ClientArchitecture: x86_64 OsArchi
tecture: x86_64)","version":"23.0.0.10"}
I am also suffering from the same problem. I found this issue after noticing that the Windows Desktop client is no longer syncing after a recent update (nextcloud help #129862)
I see the following in my server logs
{
"reqId": "U0mhUkrh947JoXn2fn91",
"level": 4,
"time": "2022-01-04T08:23:03+00:00",
"remoteAddr": "redacted",
"user": "redacted",
"app": "webdav",
"method": "POST",
"url": "/remote.php/dav/bulk",
"message": "Unknown error while seeking content",
"userAgent": "Mozilla/5.0 (Windows) mirall/3.4.1stable-Win64 (build 20211221) (Nextcloud, windows-10.0.19042 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/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
"line": 129,
"function": "isAt",
"class": "OCA\\DAV\\BulkUpload\\MultipartRequestParser",
"type": "->",
"args": [
"--boundary_.oOo._fYSlcaj4VeLLbjrfOnsBCIlAcPzhiaz/--\r\n"
]
},
{
"file": "/var/www/html/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php",
"line": 69,
"function": "isAtLastBoundary",
"class": "OCA\\DAV\\BulkUpload\\MultipartRequestParser",
"type": "->",
"args": []
},
{
"file": "/var/www/html/nextcloud/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/nextcloud/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/nextcloud/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/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 321,
"function": "start",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/var/www/html/nextcloud/apps/dav/lib/Server.php",
"line": 339,
"function": "exec",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/var/www/html/nextcloud/apps/dav/appinfo/v2/remote.php",
"line": 35,
"function": "exec",
"class": "OCA\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/var/www/html/nextcloud/remote.php",
"line": 166,
"args": [
"/var/www/html/nextcloud/apps/dav/appinfo/v2/remote.php"
],
"function": "require_once"
}
],
"File": "/var/www/html/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
"Line": 111,
"CustomMessage": "--"
}
}
Same problem here after upgrading to 3.4.0/3.4.1. I am running the client on MacOS arm64, so it seems that all operating systems and architectures are affected.
Same here with Nextcloud on Ubuntu 20.04.3, PHP 7.4, desktop 3.4.1 on Arch Linux.
I've been scratching my head with this one for days now. Arch Linux 3.4.1. Nextcloud on TrueNAS k3s w/ php 8.0.
Any workarounds or anything? I've literally got half of all users' files available.
See https://github.com/nextcloud/desktop/issues/4106
Downgrading the client to 3.3.6 seems to work around the issue.
I am having the same issue and files are not being uploaded. (NC23 and Win Client 3.4.1)
But the strange thing is that folders are being uploaded immediately when files keep pending...
@Sim0nW0lf Please see my open ticket i have on your MS files still showing as syncing i've been asking for a fix for a while now https://github.com/nextcloud/desktop/issues/3526
I experience the same, Ubuntu NC Desktop app 3.5.4, when up- or downloading several thousand tiny files:
[webdav] Error: Sabre\DAV\Exception: Unknown error while seeking content at <<closure>>
0. /var/www/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php line 129
OCA\DAV\BulkUpload\MultipartRequestParser->isAt("--boundary_.oOo ... n")
1. /var/www/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php line 71
OCA\DAV\BulkUpload\MultipartRequestParser->isAtLastBoundary()
2. /var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89
OCA\DAV\BulkUpload\BulkUploadPlugin->httpPost(Sabre\HTTP\Request {}, Sabre\HTTP\Response {})
3. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 472
Sabre\DAV\Server->emit("method:POST", [Sabre\HTTP\Requ ... }])
4. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 253
Sabre\DAV\Server->invokeMethod(Sabre\HTTP\Request {}, Sabre\HTTP\Response {})
5. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 321
Sabre\DAV\Server->start()
6. /var/www/nextcloud/apps/dav/lib/Server.php line 360
Sabre\DAV\Server->exec()
7. /var/www/nextcloud/apps/dav/appinfo/v2/remote.php line 35
OCA\DAV\Server->exec()
8. /var/www/nextcloud/remote.php line 171
require_once("/var/www/nextcl ... p")
POST /remote.php/dav/bulk
Probably the issue https://github.com/nextcloud/desktop/issues/1035 is related, too.
Just saw, before a bunch of these errors, there is another entry in the log:
{"reqId":"xkkG1cah6d1K4KKlCHvr","level":3,"time":"2023-01-06T16:45:32+01:00","remoteAddr":"xxx.xxx.xxx.xxx","user":"myuser","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.5.4-20220806.084713.fea986309-1.0~focal1 (Nextcloud, ubuntu-5.4.0-136-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.2.3","data":[],"id":"63b8463baf9b1"}
Still an issue NC27
{"reqId":"no5vGlxKVQQR2kP9ZY63","level":3,"time":"2023-10-22T03:26:01-05:00","remoteAddr":"184.100.209.34","user":"username","app":"webdav","method":"POST","url":"/remote.php/dav/bulk","message":"Unknown error while seeking content","userAgent":"Mozilla/5.0 (Windows) mirall/3.4.4stable-Win64 (build 20220318) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"27.0.2.1","exception":{"Exception":"Sabre\\DAV\\Exception","Message":"Unknown error while seeking content","Code":500,"Trace":[{"file":"/var/www/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php","line":129,"function":"isAt","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->"},{"file":"/var/www/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php","line":71,"function":"isAtLastBoundary","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPost","class":"OCA\\DAV\\BulkUpload\\BulkUploadPlugin","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/apps/dav/lib/Server.php","line":364,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/remote.php","line":172,"args":["/var/www/nextcloud/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php","Line":111,"message":"Unknown error while seeking content","exception":[],"CustomMessage":"Unknown error while seeking content"},"id":"65358ba2afcf3"}
Yup. in NC28 I also stillllll see this problem.
But at least in NC28 you can see that the error still exists as there is no a warning in the overview page /s
393 errors in the logs since February 24, 2024
Is this a joke? I mean we are talking about files not getting synchronized, right? Did I miss a workaround? Synchronizing files is the core feature of Nextcloud and no one cares for 3 years if it's buggy?
Did you update all clients to the latest versions. In my case the error was caused by an outdated windows client with Version 3.4.1 After updating it, all errors are gone.
I got stuck at 3.4.2. Looks like this is the latest version Ubuntu 22.04 distributes via normal packages. I guess you might get newer versions when using snap or flatpack or whatever &/%$&/§$ packaging system you like. Don't know yet if the errors are gone but at least a few files which weren't synced before are no visible on server side. Thanks so far.
But can we please keep in mind that a client updated "fixes" as server side bug? That doesn't sound like good code quality :(
Sorry for being the one who is rude or is anger someone but I use Nextcloud for a long time now (coming from OC and switched over on the early times of NC). And I have seen NC going down a road I don't like. You know, something is not right when feature richness is more important than stability. Please focus on the core features. Thx.
maybe the connection with older clients or clients using outdated commands should be blocked. But of course that would be a problem on such distros that don't update the packages anymore...
This appears to be a duplicate of nextcloud/desktop#5824 which was fixed in nextcloud/desktop#5871 (released in Desktop v3.10.0 + backported to v3.9.1) + #39221 (released in Server v28.0.0 + backported to v26.0.5 + v27.0.2).
Is anyone able to reproduce this behavior in combination with Desktop >= v3.10.2?
All the reports in this issue (that include version info anyway), are using Desktop 3.4.x or 3.5.x, where I'd expect this behavior to occur.
But can we please keep in mind that a client updated "fixes" as server side bug? That doesn't sound like good code quality :(
That sounds like speculation. The bulk uploader functionality requires careful coordination between the client and server (https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/bulkupload.html). Where this stack trace is being triggered is during the read from the client. It doesn't seem fair to state this is (or was) a server-side only matter (nor that anyone involved somehow papered over a "server matter" by making adjustments the desktop client) - unless you're aware of something the rest of us aren't.
Downgrading the client to 3.3.6 seems to work around the issue.
Makes sense. Bulk upload wasn't yet implemented in the desktop client in v3.3.6 (it was first added in v3.4.0).
P.S. Numerous bulk upload related bugs have been addressed in the desktop client since v3.4.1. If you're not running at least v3.10.2, expect to experience these bugs:
https://github.com/nextcloud/desktop/pulls?q=in%3Atitle+bulk+is%3Apr+is%3Aclosed
Is anyone able to reproduce this behavior in combination with Desktop >= v3.10.2?
Still having an eye on this.
But can we please keep in mind that a client updated "fixes" as server side bug? That doesn't sound like good code quality :(
That sounds like speculation. [...]
I think we have a different understanding of source code safety. I don't need to speculate about clients raising server side exception because this is what this issue literally is about. And whenever a client is able to crash server side code that means something on server side is wrong. In this case it is a "friendly reminder" to always expect the client to be bogus. But the way down to "real" attacks (e.g. DoS) isn't far from here. That's what concerns me.
regards Daniel
Is anyone able to reproduce this behavior in combination with Desktop >= v3.10.2?
The Unknown error while seeking content errors are gone. There are lot of other error messages but we already have talked about code quality and the errors are not related to this issue :)
Thanks @emc02
This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.
Having this problem with 3.3.4, 3.9, and 3.13.2 on Mac. Clearly a lot of people have been having this problem for at least 2 years. I fail to see why every one of the numerous times this has been complained about, on Github or in the NextCloud forums, it is closed, when it has never been fixed.
Also seeing this with version 29.0.4.1 Please reopen if possible. Otherwise I'd happily create a new issue instead.
I fail to see why every one of the numerous times this has been complained about, on Github or in the NextCloud forums, it is closed, when it has never been fixed.
Same error output doesn't necessarily mean exactly the same underlying root cause. The code has been changed on both the server and client side since the original report.
Also, there's only so much we can do about people running out-of-date clients.
Otherwise I'd happily create a new issue instead.
Yes, please do so. That's the correct way to handle this so that things can be looked at in the current context of the code bases. Thank you.