The share is reachable. The folder opens. The file is right there in the listing, with its name spelled correctly. Double-click it and Windows says "File Not Found."
That specific contradiction is almost never a missing file. It is the URL underneath the name.
Why a file that exists gets a 404
A WebDAV client turns a filename into a URL path before it sends anything. The server then decodes that path and looks up the file. Every step in that chain has its own opinion about what a legal filename is, and they rarely agree.
The classic case is a non-ASCII name. A client that percent-encodes UTF-8 correctly sends %E7%BD%91%E7%9B%98.txt, and the server decodes it and finds the file. A client that sends the raw bytes sends /η½η.txt, and the server applies its own charset guess, which may not be UTF-8 at all. Same file, two different paths, one of which does not exist. The server is not lying when it answers 404 - it is truthfully reporting that the path you asked for is not there.
The four checks that find it
- Copy the name into a browser address bar on the same URL the client is using. If the browser shows a different file, or nothing, the encoding is the problem, not the storage.
- Compare the response headers for a real file and for the missing one. A genuine missing file returns 404 with no Content-Type; a mis-encoded path often returns 404 with the server's normal error page, or 400, or even 200 with an empty body.
- Watch for the redirect. Some servers redirect a path with a space or a non-ASCII character to an escaped path, and a client that does not follow the redirect reports the first response as the final one.
- Check whether the name contains anything that has to be escaped at all: spaces, #, ?, %, or a path separator that the server treats as a directory boundary.
If the same share mounts and the same client opens ASCII-named files perfectly, you have narrowed it to encoding, and you can stop blaming the network.
The practical fix
Any client that is going to be used with real-world folder names has to percent-encode outgoing paths as UTF-8 and decode incoming headers as UTF-8, and it has to follow redirects while doing it. Getting that wrong is a client bug that no amount of server-side configuration will fix.
ScsDriver mounts a WebDAV share as a normal Windows drive letter and handles the encoding and redirect handling at the driver level, so CJK-named files open from Explorer the same way ASCII-named files do. It is $5.50 as a one-time purchase - the license is yours permanently, no annual renewal - and there is a 7-day full-feature trial if you want to test it against your own folders first.
Full disclosure: I work on ScsDriver, and everything above comes from supporting it in the field.
