Some WEBDAV files accessible using odrive, but all work through Windows Explorer

Troubleshooting
1

When I attempt to access some files on a WEBDAV share in the odrive WebUI, it returns:
"WEBDAV_ITEM_NOT_FOUND".
When I try syncing the .cloudf file from Desktop Sync, it returns:
Can’t sync Filename.vbs.old.cloud.
The item does not exist on the WebDAV server.

It seems to be related to the file extension.
Working Extensions: vbs, txt, exe, zip, msi, html, dll
Failing Extensions: old, bat, log, reg, ps1, sql, ini, cfg, url

But if I connect to WebDAV using Windows Explorer, I can open all files without issue. I have checked the server configuration for the “Allow Unlisted File Extensions” (is checked), but it seems very strange that Windows can access the files but odrive cannot. Help! :grin:

My desktop agent version is prod 6236.
I am running Windows 10 64-bit, build 15063.

2

Hi @darren,
This sounds like it is IIS providing the WebDAV, correct? Take a look at this post here:

I found that even with the “Allow unlisted file name extensions” checked, The MIME types needed to be set to properly allow downloads.

3

IIS is providing the WebDAV, yes. But I can map a drive to this WebDAV and access these files without any problems through Windows Explorer. Doesn’t that suggest that there is something that odrive is doing differently than Windows, which causes odrive specifically to fail?

4

I suspect that the difference is that Windows is using some WebDAV command to retrieve the file, and I assume that for a download (vs. an upload or a rename) odrive is not using a WebDAV command. I guess it is just attempting to “download” the file, and thus running into the unknown MIME types issue?

5

Hi @darren,
In my testing IIS was returning a 404 for a GET on a resource that had an extension that was not explicitly defined in the MIME Type. WebDAV is really just HTTP with some additional verbs. Download is a standard GET.

WebDAV tends to be a bit “loose” in its standards and I have seen lots of variations between server implementations. It is possible that Explorer is doing something special, that is non-standard to get around the IIS restriction. I know Microsoft has a set of its own, Windows-specific WebDAV extensions that are additive to the general WebDAV standard, and we don’t implement those extensions. You could try looking at the IIS logs to see what the difference is in the Explorer request vs the odrive request.

Does adding the wildcard MIME mapping to IIS, as per the previous post, fix the problem?

6

I am not authorized to make changes to the configuration, though I can find out the settings. I confirmed (as expected) that there is not a wildcard mapping in place. And I confirmed that a MIME type entry exists for each of the file types that I successfully downloaded with odrive.

From my computer:

I ran: copy /y "L:\Transfer\Monitors\r*" "C:\Windows\Temp"
Command Result:
L:\Transfer\Monitors\RemoteMonitors.txt
L:\Transfer\Monitors\repadmin32.exe
L:\Transfer\Monitors\repadmin32.exe.old
3 file(s) copied.

This was logged:
#Software: Microsoft Internet Information Services 7.5
#Version: 1.0
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2017-09-22 08:04:50 SERVER.IP.ADDRESS PROPFIND /Share/Transfer/Monitors - 443 webdavusername my.pc.ip.address Microsoft-WebDAV-MiniRedir/10.0.15063 207 0 0 34
2017-09-22 08:04:50 SERVER.IP.ADDRESS PROPFIND /Share/Transfer/Monitors - 443 webdavusername my.pc.ip.address Microsoft-WebDAV-MiniRedir/10.0.15063 207 0 0 145
2017-09-22 08:04:50 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/RemoteMonitors.txt - 443 webdavusername my.pc.ip.address Microsoft-WebDAV-MiniRedir/10.0.15063 200 0 0 34
2017-09-22 08:04:51 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/repadmin32.exe - 443 webdavusername my.pc.ip.address Microsoft-WebDAV-MiniRedir/10.0.15063 200 0 0 275
2017-09-22 08:04:51 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/repadmin32.exe.old - 443 webdavusername my.pc.ip.address Microsoft-WebDAV-MiniRedir/10.0.15063 200 0 0 273

I visited odrive.com. I browsed to the same folder, then I attempted to retrieve these files:
RemoteMonitors.txt, repadmin32.exe, repadmin32.exe.old

The first two files downloaded without issue.
On clicking the third file, I received:
WEBDAV_ITEM_NOT_FOUND

This was logged:
2017-09-22 07:44:44 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/RemoteMonitors.txt - 443 webdavusername 216.227.130.34 python-requests/2.9.1 200 0 0 53
2017-09-22 07:44:49 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/repadmin32.exe - 443 webdavusername 216.227.130.34 python-requests/2.9.1 200 0 0 365
2017-09-22 07:44:55 SERVER.IP.ADDRESS GET /Share/Transfer/Monitors/repadmin32.exe.old - 443 webdavusername 216.227.130.34 python-requests/2.9.1 404 3 50 51

7

Hi @darren,
You can see that both clients are performing a GET on the resource. In the odrive case, IIS returns a 404 (Not Found) when the request is made.

Unfortunately I don’t know why IIS behaves differently here. The Windows client could be adding some additional request headers that we aren’t seeing to prompt IIS to serve the content despite the MIME type rule. Or, it could be that IIS makes exceptions for the Explorer client type. This restriction is definitely happening server-side, though.

8

Is the odrive User-Agent customizable? Would it make sense to change it to “Microsoft-WebDAV-MiniRedir/” when accessing WebDAV resources if it allowed access to contents that are normally blocked from being downloaded?

9

Hi @darren,
There isn’t a way to do this, currently. We also don’t know if it is the user agent that dictates this. It would be pretty wacky if that was the case, although not totally surprising considering the stuff I’ve seen MS do…