IIS App Pool Crashing when App Pool User connects to fileshare

At my workplace, we use Visual Studio to create ASP.NET MVC websites for most of our in-house applications. We have one particular site that is being... obstinate with file connections. What we have observed is that whenever the site reaches out to a Fileshare Server to access attachment documents, the IIS app pool will crash, and need to be manually restarted.

In order to connect to the fileshares, we assign a service account to the IIS App Pool User, and then that user is granted folder access to the folders designated for that application.

Checking the event viewer, we are able to see that the reason the app pool shut down is because it had a rapid succession (within milliseconds) of permission errors, and once IIS hits a quota of rapid errors, it forces the app pool to stop.

So far, here's the things we have checked on:

• We have confirmed that the Service Account has the correct permissions to access the designated fileshare folders. All permissions have been correct since before we began looking into it.
• We have attempted to create a virtual folder in the IIS application to avoid absolute paths. No Change.
• We have overhauled the application to use only absolute path references to the fileshare. This resulted in ONE successful file access, followed by the App Pool crashing from the second attempt on.
• We cannot replicate this issue on any of our development servers or machines. This only happens in our CAT and Prod environments. Those environments are also on a failover system, and consist of two separate servers each, with a primary and a back up which both have their own IIS app references to the application data, which is stored on a third separate server (I didn't set this up, but it was what we were told we need to use).

The servers we are using are running Windows Server 2016, and are therefore running IIS 10.0.

I should also mention that we have several web applications running on these servers, which also access attachment files in the same fashion as the problem site, and are structured the same way as the problem site, but the only site that has any issues is the site in question. Every other site functions as intended. All of the other App Pool User Service accounts have the same permissions as the problem site (with access to their relative files of course).

It has stumped me as to why we have a single site that is acting out when from everything I can think of, it has identical settings to the other sited housed on that server, which are not having issues.

Any ideas would be appreciated.

Turns out that the application was using an older method of checking for MIME type on the attachment files. This process uses older Windows libraries, and runs them through a local application on the machine to analyze internal file data. The permissions issues wasn't about access to the fileshare, it could apparently get there just fine. The issue was trying to open the application to determine MIME type. Every time the application pulled information about an attachment, it would try to get this MIME information.

The MIME determination has been changed to a C# System.Web function:

string mimeType = MimeMapping.GetMimeMapping(filename);

With this change in place, the application is no longer trying to access system files on the server, and is no longer generating permission denial errors.