Caveat: In Windows, WebDAV with --baseurl cannot be mounted (browsed in explorer.exe) if it was the first WebDAV server Windows see after its boot

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.


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 :slight_smile:

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.