I've setup an nginx/webdav instance. I can connect to it just fine. (If it matters, it uses
(I tested using
https://
and auth_pam
.)
In a web browser (chrome shown), I see everything I expect to see:

curl
as well, identical results -- all files/dirs shown.)
But when I connect using another client (so far I've tested cadaver
, macos Finder, and macos' mount_webdav
), I only see a subset:
-bash
$ cadaver --tolerant https://myhost.com/webdav/
...
dav:/webdav/? ls
Listing collection `/webdav/': succeeded.
Coll: #recycle 0 Nov 16 00:00
Coll: summary 0 Oct 29 14:11
fixperms.sh 26936 Apr 8 2024
dav:/webdav/?
What's interesting is that if I ignore the fact that I don't _see_ ./data/
, I can still read files within it (programmatically or in a terminal/shell). For instance, if ./data/somefile
existed on the server, then even though data
is not shown in the file listing, I can cat data/somefile
and get its contents without issue.
I can find no correlation between owner, group, or perms for files that are shown/not-shown, though the behavior is consistent between clients and reconnections.
The server is running on nginx-1.18.0 (ubuntu 22.04) with both --with-http_dav_module
(compiled into nginx) and the additional libnginx-mod-http-dav-ext
(ubuntu package) module. The nginx conf:
location /webdav {
root /path/subpath ;
rewrite ^/webdav/(.*)$ /$1 break;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
dav_access user:rw group:rw all:rw;
client_max_body_size 0;
create_full_put_path on;
client_body_temp_path /tmp/webdav-temp ;
auth_pam "Restricted";
auth_pam_service_name "common-auth";
autoindex on;
}
FYI, cadaver --tolerant
is to work around some complaints in cadaver since I'm requesting /webdav
even though webdav
is not actually part of the remote filesystem/path ... notice the nginx rewrite
rule. I cannot have the top-level /
as the webdav root and I have other top-level dirs being served, ergo the rewrite.
FWIW, I'm doing this to get a better remote-filesystem connection from macos to a remote network. sshfs
is the best I have atm, and its support on macos is years behind the main branch with no expectation of catching up, and quite a bit slower than (say) sshfs on linux. I need read-write access at some point, have not tested yet with this webdav setup.
(Note: originally asked on superuser, since deleted. I think it's more on-topic here.)
Asked by r2evans
(73 rep)
Dec 31, 2024, 06:51 PM
Last activity: Dec 31, 2024, 07:59 PM
Last activity: Dec 31, 2024, 07:59 PM