title: Windows service cannot access UNC path
body: <p>I have a windows service written in C# running on Windows Server 2012.  The service is running as a domain user with permissions on the local machine and NTFS permissions to shared network resources on an Isilon SAN.  I can access shared files and directories in Windows Explorer when logged on as this user with the following format:</p>
  
  <pre><code>\\isilon\path\to\dir\
  </code></pre>
  
  <p>However, calls to</p>
  
  <pre><code>System.IO.Directory.Exists()
  </code></pre>
  
  <p>always return false.  At first I thought it was this:
  <a href="http://support.microsoft.com/kb/827421" rel="noreferrer">http://support.microsoft.com/kb/827421</a>
  However, implementing the workaround suggests that you can use</p>
  
  <pre><code>System.IO.Directory.GetDirectories()
  </code></pre>
  
  <p>to just access the directories (without checking first if they exist) instead.  This just throws</p>
  
  <pre><code>System.IO.IOException: An unexpected network error occurred.
  </code></pre>
  
  <p>This same service code works when running on another server (Windows 2008) on the same network.  </p>
  
  <p>What is really crazy is that if I reboot the server, the file system calls succeed at first.  Then after some amount of time, or after accesses to the same file path from that computer, the programmatic calls will start to fail and will never spontaneously succeed again.  Rebooting the server fixes the issue for a very short while.</p>
  
  <p>I'm totally stumped as it shouldn't be necessary to reboot a Windows server instance hardly ever.  I don't have any idea what could be affecting the fileshare permissions or accessibility.  Maybe it is related to the new implementation of SMB 3.0 on Windows server 2012?</p>
  
  <p><strong>Edit:</strong> OK, It turns out that I'm not crazy.  The version of OneFS (the FileSystem running on the Isilon SAN) was not explicitly compatible with Windows server 2012.  While it claimed to be compatible with SMB.  Updating from OneFS version 6.5.5.14 to 6.5.5.20 fixed the problem immediately and has been stable since.</p>