Sample Header Ad - 728x90

nginx webdav missing some files in non-browser clients

0 votes
0 answers
64 views
I've setup an nginx/webdav instance. I can connect to it just fine. (If it matters, it uses https:// and auth_pam.) In a web browser (chrome shown), I see everything I expect to see: enter image description here (I tested using 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