Using 9.4.1 (44384) on macOS Sequoia, if the option Cryptomator / "Auto detect & open vault in browser" is checked, I am seeing that using Quick Look (space bar) leads to this error:
Connection failed (/dav/somedir/masterkey.cryptomator).
I do not see that error pop up when using other protocols such as SFTP on a different server.
But I also find it odd that when I download the same file that I tried to quick look, then the download succeeds, not showing the error - the error only comes up when using quick look. But both operations should internally use the same path, i.e. download the file and optionally decrypt it if necessary, so either both should look for cryptomator or not. But one does, and the other doesn't. Weird, but maybe that helps you to figure out what's wrong.
I have verified that the webdav server gives a 404 status in this case, which I hope is the correct and expected behavior:
/tmp % curl -v "http://192.168.4.218/dav/0152/masterkey.cryptomator"
* Trying 192.168.4.218:80...
* Connected to 192.168.4.218 (192.168.4.218) port 80
> GET /dav/0152/masterkey.cryptomator HTTP/1.1
> Host: 192.168.4.218
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Content-Type: text/html
< Content-Length: 9
<
* Connection #0 to host 192.168.4.218 left intact
Not found
I don't have other webdav servers around for testing right now, so it could as well be a bug in that server, but I can't see how. I can do more tests if you need to and reply within the next 1-2 weeks (I may not have access to this server later any more).
Using 9.4.1 (44384) on macOS Sequoia, if the option Cryptomator / "Auto detect & open vault in browser" is checked, I am seeing that using Quick Look (space bar) leads to this error:
I do not see that error pop up when using other protocols such as SFTP on a different server.
But I also find it odd that when I download the same file that I tried to quick look, then the download succeeds, not showing the error - the error only comes up when using quick look. But both operations should internally use the same path, i.e. download the file and optionally decrypt it if necessary, so either both should look for cryptomator or not. But one does, and the other doesn't. Weird, but maybe that helps you to figure out what's wrong.
I have verified that the webdav server gives a 404 status in this case, which I hope is the correct and expected behavior:
I don't have other webdav servers around for testing right now, so it could as well be a bug in that server, but I can't see how. I can do more tests if you need to and reply within the next 1-2 weeks (I may not have access to this server later any more).