This may be a kind of bug, but not a clear bug with rclone, but rather with Windows.
When I booted Windows, logged in, ran rclone with rclone serve webdav --addr localhost:8000 --baseurl /test C:\somedir, and tried to browse it in explorer with \\localhost@8000\test, explorer said it was not accessible.
This only applies to the FIRST WebDAV server Windows see (after boot). So, to work around this, we can mount "dummy" WebDAV server without --baseurl before mounting the desired WebDAV server.
This problem may be caused by 404 error returned when rclone`s WebDAV with --baseurl received access on it's top page (localhost:8000/). I mocked rclone WebDAV server to return dummy page with status code 200, and the problem didn't happen.
That is strange! I wonder why Windows looks at the root when you gave it a path?
Perhaps try adding a trailing \ to your browse \\localhost@8000\test\ then windows will know test is not a file.
Yes, it's strange.
Actually, even if I specified a deeper folder like \\localhost@8000\test\some\folder, explorer returned an error. Windows seems to check the top page first regardless of the specified path.
For testing, I used a kind of proxy for webdav, available on webdav proxy with a secret folder · GitHub
Could you try running the webdav server with -vv and report back exactly what request Windows makes?
I think requests to the top page won't be logged, even with -vv.
Hmm...
Can you try wireshark?
We could potentially make a workaround for this but I need to know what Windows is requesting. It might be doing a CORS request or something else.
Do you think it is worth doing a work-around? Maybe using a --base-url is a niche feature?
This is unsuccessful result (first WebDAV server for explorer),
and this is successful result (not the first):
In the unsuccessful case, Windows requests the top page (OPTIONS request), while not in the successful case.
I myself could workaround this by mounting a "dummy" server first, but if there are no significant side effects with changing the response code from 404 to 200, it might be better. FYI, I need --baseurl to obfuscate file location from other users (by default, Windows doesn't allow password auth for non-SSL WebDAV servers).
I've tested only on a single Windows 11 machine but now I tested also on Windows 10 machine and reproduced the same behavior.
That makes sense. Windows will be caching the CORS status of the domain I think.
It probably makes sense for us to reply to OPTIONS with a non 404 result here.
Try this and see if it helps
v1.67.0-beta.7811.72425b121.fix-webdav-cors on branch fix-webdav-cors (uploaded in 15-30 mins)
1 Like
I tested and this works! Thank you!
Thanks for testing 
I've merged this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.67 - I'll put it in v1.66.1 also.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.