We have a windows file system driver which is registered as FILE_DEVICE_DISK_FILE_SYSTEM. The virtual file system can be accessed through either a drive letter or the UNC path. The driver has been working fine for us on Windows 2003.
However, when we install the driver on Windows 2008, driver letter access works fine, but the access through UNC path gives us the following error:
Open Folder:
\machinename\iwserver is not accessible. You might now have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
The specified server cannot perform the requested operation.
The same UNC path access works fine if I use it from a Windows 2003 machine. Has anybody seen this issue?
wrote in message news:xxxxx@ntfsd… > We have a windows file system driver which is registered as FILE_DEVICE_DISK_FILE_SYSTEM. The virtual file system can be accessed through either a drive letter or the UNC path. The driver has been working fine for us on Windows 2003. > > However, when we install the driver on Windows 2008, driver letter access works fine, but the access through UNC path gives us the following error: > --------------------------------------- > Open Folder: > \machinename\iwserver is not accessible. You might now have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. > The specified server cannot perform the requested operation. > -------------------------------------- > > The same UNC path access works fine if I use it from a Windows 2003 machine. Has anybody seen this issue? > > Thanks, > JP >
We have a windows file system driver which is registered as FILE_DEVICE_DISK_FILE_SYSTEM. The virtual file system can be accessed through either a drive letter or the UNC path. The driver has been working fine for us on Windows 2003.
However, when we install the driver on Windows 2008, driver letter access works fine, but the access through UNC path gives us the following error:
Open Folder:
\machinename\iwserver is not accessible. You might now have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
The specified server cannot perform the requested operation.
The same UNC path access works fine if I use it from a Windows 2003 machine. Has anybody seen this issue?
Are you correctly handling the IOCTL_REDIR_QUERY_PATH_EX request being
made to you to resolve the UNC path?
Pete
Thanks,
JP
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
We don’t handle IOCTL_REDIR_QUERY_PATH_EX at all. We are still using DDK version 3790.1830 and IOCTL_REDIR_QUERY_PATH_EX is not even defined in that version. Do we have to upgrade the DDK to support Vista and Windows 2008?
I was reading this article: http://msdn.microsoft.com/en-us/library/aa489124.aspx. It says that if a driver registers as a local disk file system (by calling IoCreateDevice with the DeviceType parameter set to FILE_DEVICE_DISK_FILE_SYSTEM), the driver must NOT call FsRtlRegisterUncProviderEx to register as a UNC provider with MUP.
Our driver is registered as a local disk file system and we don’t call FsRtlRegisterUncProviderEx. So are we still going to get IOCTL_REDIR_QUERY_PATH_EX?
We don’t handle IOCTL_REDIR_QUERY_PATH_EX at all. We are still using DDK version 3790.1830 and IOCTL_REDIR_QUERY_PATH_EX is not even defined in that version. Do we have to upgrade the DDK to support Vista and Windows 2008?
I was reading this article: http://msdn.microsoft.com/en-us/library/aa489124.aspx. It says that if a driver registers as a local disk file system (by calling IoCreateDevice with the DeviceType parameter set to FILE_DEVICE_DISK_FILE_SYSTEM), the driver must NOT call FsRtlRegisterUncProviderEx to register as a UNC provider with MUP.
Our driver is registered as a local disk file system and we don’t call FsRtlRegisterUncProviderEx. So are we still going to get IOCTL_REDIR_QUERY_PATH_EX?
The issue here is that you must register with MUP and register as a file
system for FM to mount your device stack. Therefore if you call
FsRtlRegisterUncProvider() (the non-Ex version) you also need to
register as a local file system. If you call
FsRtlRegisterUncProviderEx() this internally calls the local file system
registration for you.
I dynamically determine if the Ex version exists for the platform and if
it does not then call the non-Ex and the local file system registration
routine.
In either case, on Win 7 you need to handle the
IOCTL_REDIR_QUERY_PATH_EX IOCtl, this is most likely your issue. If it
is not defined in your DDK version then simply define it or upgrade to a
new WDK.
Pete
Thanks very much,
JP
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
> Our driver is registered as a local disk file system and we don’t call FsRtlRegisterUncProviderEx.
Then forget the \server\share naming.
Actually in order for FM to correctly sit on top of your redirector, you
must also register as a local file system. The
FsRtlRegisterUncProviderEx() does this for you while
FsRtlRegisterUncProvider() does not and you must call
FsRtlRegisterFileSystem() yourself.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
I have created an unnamed DeviceObject of type FILE_DEVICE_NETWORK_REDIRECTOR. I then call FsRtlRegisterUncProviderEx dynamically using the device object and “L”\Device\MyFilesys\MyNetworkRedirector" as the name.
But I am getting error 0xC0000039(STATUS_OBJECT_PATH_INVALID) returned from FsRtlRegisterUncProviderEx. Anybody has sample code to show how to get FsRtlRegisterUncProviderExt to work?
The key point here is that she has a *local* file system, not a network file system.
Three machines:
Machine ‘A’ - the system on which her file system is exported and shared via SMB. This is running Windows Server 2008.
Machine ‘B’ - a Server 2003 box accessing her exported file system (via SMB.) This works.
Machine ‘X’ - a Server 2008 box accessing her exported file system (via SMB.) This fails.
I suspect it is the SMB2 implementation that is causing some subtle difference in behavior here. My advice would be to use irp tracker or filespy or filemon (or all three) to watch the I/O operations to your file system and see if you can observe any explicit failures. If not, then you’ll need to compare a successful trace (such as when accessing an NTFS drive) with an unsuccessful trace.
I would suggest NOT using Explorer to do this - use the command line. It will do far less “work” over the network and make analyzing it easier.
Anyway I think that if you change device from FILE_DEVICE_DISK_FILE_SYSTEM to FILE_DEVICE_NETWORK_FILE_SYSTEM it should work. There is still support for legacy redirectors on Vista, Win Server 2008 and Windows 7, so FsRtlRegisterUncProvider() + FsRtlRegisterFileSystem() + handling IOCTL_REDIR_QUERY_PATH should be enough.
Use FileSpy to discover and analyze which IRP fails. I remember that as we started to support Vista we had to add support for all file information classes of IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY, not only FileBothDirectoryInformation. It might be similar for IRP_MJ_QUERY_INFO and IRP_MJ_QUERY_VOLUME_INFO.
Anyway I think that if you change device from FILE_DEVICE_DISK_FILE_SYSTEM to FILE_DEVICE_NETWORK_FILE_SYSTEM it should work. There is still support for legacy redirectors on Vista, Win Server 2008 and Windows 7, so FsRtlRegisterUncProvider() + FsRtlRegisterFileSystem() + handling IOCTL_REDIR_QUERY_PATH should be enough.
One more item, when you call the FsRtl routine, you will receive an open
on the device name you pass in to the call. Generally this comes in as
an open with a NULL file name, if you fail this the FsRtl call will fail.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
Changing a local file system into a network redirector doesn’t seem like a very good solution for solving network (SRV) access issues. I’m curious why you think it might solve her problem in this instance.
Further, in the past I’ve found that SRV does not like to “re-export” other network file systems (it has been able to configure it to do so in the past, though, to build “gateway” products.) Thus, I would expect it would yield uniform behavior for both types of remote clients, but that would be “no access” rather than “works for W2K3, fails for W2K8.”
My understanding was that OP has de facto redirector, but she calls IoCreateDevice() with wrong device type. It is quite unclear in original message if the error is related to her redirector or SMB redirector running on other machine. If scenario is her local FSD shared by SMB server the whole discussion is quite misleading and my understanding wrong. Tony, I am sorry for ignoring of your previous message, I have somehow missed it.
I have tried to access the UNC path from command line doing the following:
edit \localhost\iwserver\default\main\WORKAREA\jzhuang\a.txt
The edit command or dir command works perfectly fine on both Windows 2008 and Windows 2003. Does it work against your theory?
The other thing I’d like to mention is that our driver doesn’t even call IoRegisterFileSystem right now because it crashes on Windows 2003 sp1. Do you think that would be one of the problem?
Hi Tony,
This appears to be some kind of SMB2 problem.
IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY Single entry works fine.
However, after single entry, if there are more then 3 files/directories in the listing STATUS_INVALID_NETWORK_RESPONSE is returned.
(Here is the full path \Device\Mup\localhost\iwserver\ )
No errors are returned from our driver, so it must have something to do with buffer size restrictions in SMB2 or something else.
Any ideas how to debug this further?
I have not found any differences between successful and unsuccessful traces except for the sizes of the returned listings.
We update size in Information field of IO_STATUS_BLOCK
ntdll!_IO_STATUS_BLOCK
+0x000 Status : 0n0
+0x000 Pointer : (null)
+0x004 Information : 0x240
Here is the FileSpy trace of the failed path : IRP_MJ_DIRECTORY_CONTROL failure happens at #113
(notice that Y:\ and \Device\Mup\localhost\iwserver reference the same device)
When we call our Win2K8 server from Win2K3 we go though Y:. However, when we call win2K8 server from another win2K8 machine (or using \localhost) we go through \Device\Muo\localhost\iwserver.
Time sent Dur. Process Thread ID DeviceObject Type IRP Request IRP Flags TopLvlIrp FileObject FsContext FsContext2 FO Flags Sop Path Status More info