These two paths are equal:
\\myhostname\c$\temp
c:\temp
Is there a performance difference between them? Specifically, long sequential reads and writes.
I have a virtual directory in my site (test environment). It is a UNC share which is also used as a public FTP.
It is configured to connect as a domain admin account and "Test settings" says everything appears to be working. However when I try to connect to it I get:
500 - "Failed to start monitoring changes on \INTRANET\FTP\test\web.config because access was denied"
This is an ASP.NET YSOD. I am not sure why ASP.NET is getting involved at all as it's a static .jpg file I'm requesting.
I tried turning on failed request tracing and this is the specific error:
- ModuleName WindowsAuthentication
- Notification 2
- HttpStatus 500
- HttpReason Internal Server Error
- HttpSubStatus 0
- ErrorCode 0
- ConfigExceptionInfo
- Notification AUTHENTICATE_REQUEST
- ErrorCode The operation completed successfully. (0x0)
If I change the "Physical Path Logon Type" from ClearText to Network. I get the following IIS error:
HTTP Error 500.19 - Internal Server
Error The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information
- Module IIS Web Core
- Notification BeginRequest
- Handler Not yet determined
- Error Code
0x80070005- Config Error Cannot read configuration file due to insufficient permissions
- Config File
\\?\UNC\INTRANET\FTP\test\web.configRequested URL http://test.mydowmain.com:80/uploads/images/ca49acf6-6174-412e-8abd-59fab983e931.jpg
Physical Path
\\INTRANET\FTP\test\images\ca49acf6-6174-412e-8abd-59fab983e931.jpgLogon Method Not yet determined
- Logon User Not yet determined
- Failed Request Tracing Log Directory
C:\inetpub\logs\FailedReqLogFiles
This does not generate a failed request log strangely enough—I have set the failed request tracing to trace errors with error codes 400-999.
Also worth noting is that if I open the Configuration feature from within IIS, I see an access denied error.
I have exactly the same set up on my local dev machine to the same UNC path and the same user it works. Just on the test server it does not.
What am I doing wrong?
I have a Windows Server 2008 R2 network share setup as a map drive in Win 7 x64. I want to search it via Windows 7 but I always get "no items match your search". It's as though it's not even attempting to search.
The File Server role with Windows Search Service is installed. The drive holding the network share is added to the indexing options on the server, and it indicates that indexing is complete.
From what I understand, the search query should be sent to the server (where the content is indexed), executed, and the results returned.
Failed solutions:
create a symbolic link to the UNC. I find that to be an extreme fix to what should be a simple problem.
enable "Always Available Offline" for the UNC. In a corporate setting it's not acceptable to duplicate all server content locally, nor is it feasible with many TB's of server storage.
install the "Windows Desktop Search: Add-in for Files on Microsoft Networks" http://www.microsoft.com/downloads/details.aspx?DisplayLang=en&FamilyID=f7e981d9-5a3b-4872-a07e-220761e27283 It allows a UNC path to be entered into the indexing options on the client and then the index built locally. However, the add-on is not for Windows 7 and is not supported for x64.
Update:
The setup includes two clients (Both fully updated Win7 x64), one file server, no domain. Just to make it easy (security isn't an issue in this case), anonymous access is used. I really doubt it's a permissions problem as I can access, modify, and create content on the mapped drive. I just can't search it.
Searching on the server ALWAYS works. The share in question has lot of content: 2.17TB with 274,633 Files, however, the folder(s) I wish to search has only 11,503 files (54.3GB)
Searching on one of the two clients works most of the time. It appears to be somewhat unreliable. Some days it works, others it does not. Searching on the second client has never worked.
The index has been rebuilt on the server as well as both clients.
Update 2:
- From the client, if I highlight all files in the share, go to properties, and let Win 7 count the files, then proceed to do a search after the counting is complete, it works. I'm not sure why that worked (something to do with rebuilding the index, properly this time?). I have a feeling that as the fileserver content changes it wont stay working. Any thoughts?
We've got an EMC NX4 SAN box serving a CIFS share to a number of Windows Server 2008 R2 app servers. The app servers are using the CIFS share to serve lots of image files (~2500 ops/sec on the share), however neither the SAN nor the app servers are showing any obvious signs of stress.
Once in a while an app server will, apparently all of a sudden, drop the connection to the SAN. Any .NET code trying to serve a file from the SAN fails with:
System.IO.IOException: The specified network name is no longer available
If I RDP to the app server and try to access "\san-name" through explorer, I get the same error. All other app servers can access it just fine. I can also access "\ip-of-san" just perfectly, pinging works as well.
A reboot of the app server fixes the issue, but that's a somewhat drastic measure to the problem, given that it seems like the SAN is working fine and the computer can access it - it just looks like the "\san-name" access has barfed up.
This has happened to two different app servers during the last week, so I don't suspect a single app server of being the cause. Ignoring the cause for now - how would I restore the "\san-name" connection without rebooting the machine? And can I somehow query what went wrong?
Event logs shows nothing (besides related ASP.NET errors caused by the issue), neither on app servers nor on the SAN.
Update:
Based on the suggestions I'll try a restart of the Workstation service the next time and see if that helps the issue. Definitely not a fix, but way faster to do than to reboot the whole machine as I've currently been doing. Any way to query the status of the connections that the Workstation service maintains?
Update 2:
Confirmed that restarting the Workstation service "fixes" the issue. Next step is to try the reg change to heighten the MaxCmds value. Won't be able to confirm whether it's the issue, can only assume if it runs for a lengthy period without issues.
I am attempting to change directories to a file server such as:
cd \\someServer\\someStuff\
However, I get the following error:
CMD does not support UNC paths as current directories
What are my options to navigate to that directory?