Overview
In some situations you may see that the file preview and download do not work in the Web client - the preview remains blank, and downloads do not happen.
Details
The most common reason for this issue is that the URL that is seen in the browser by the end user is not the same as the path in the IIS web site that provides the M-Files Web Access.
This happens most often when a proxy changes the path because the public DNS hosts several services, so an extra virtual directory is added to distinguish them publicly, but the actual web server(s) do not have that folder.
In such cases the path that M-Files sees is different than what the browser sees, which means that HTTP cookies do not match between them, so you can see "Session Not Found" errors in the requests for the file contents.
For example, you may have this setup:
Main public DNS name: https://portal.company.com/
M-Files Web Access is then seen by end users at: https://portal.company.com/m-files-web
Another service, say reporting is at: https://portal.company.com/reports
However, the actual server hosting M-Files web hosts it at the root of the site, not in the "m-files-web" virtual directory.
What happens is that a proxy sits between the browser and the IIS server hosting M-Files and it routes the /m-files-web path to the root / of the IIS site, thereby breaking the session cookies.
Solution
First, see if you are using an old version of M-Files server, there is a known issue that may cause this without such setup, you can read more about it here: /article/Preview-and-file-download-does-not-work-in-new-web-in-22-12-with-session-not-found-error.
If you are hitting the scenario with the path change, there are a few approaches:
- Recommended: See if you can avoid the virtual directory in the first place - e.g., by dedicating a DNS name to each vault as this adds other benefits such as easier way to distinguish where your users are, avoids an issue explained below, and lets you define, for example, Federated Authentication settings easily at the vault-level configuration instead of the registry. In that case you could have something like https://vault1.company.com and https://vault2.company.com for the M-Files web access, without virtual directories and URL rewriting/change.
- If this is not possible, you need to match the path that the end user sees to the path the M-Files Web Access has in IIS. Usually, that would mean setting up the web access in a virtual directory (called "m-files-web" in this example). This has a few considerations and caveats, please follow this article for more details how to do this and the potential issues: /article/M-Files-Web-clients-installed-in-a-virtual-directory.
