Network Share Permissions

I have 3.1 up and running, with the addition of the special DLL that allows the Flash upload tool to be disabled.

Now I'm trying to add some additional roots for several users and am getting this error:

"Attempted to access a path that is not on the disk"

I've compared permissions from the working roots and the non-working roots and all seems okay. I'm using Windows Auth with impersonation.

Any ideas?

A bit more pertinent info:

All the roots are pointed to DFS shares. However, the roots that work are for data that reside on the server running FileVista (though the DFS share name is not).

All the roots that don't work are on another server. I'm using the standard notation \\servername/sharename in the root setup in FileVista.

Hi Loren,
I guess you are using the following security mode in web.config:

<authentication mode="Windows"/>
<identity impersonate="true"/>

and you have enabled "Integrated Windows Authentication" in IIS for FileVista.

So your problem seems to be the double-hop issue which occurs when the ASPX page tries to use resources that are located on a server that is different from the IIS server. The first "hop" is from the web browser client to the IIS ASPX page; the second hop is to the remote resource. The remote resource requires a primary token. Therefore, the IIS server must know the password for the client to pass a primary token to the remote resource. The double-hop using a secondary token occurs, for example, when the browser client is authenticated to the IIS ASPX page by using NTLM authentication. In this example, the IIS server has a hashed version of the password as a result of using NTLM. If IIS turns around and passes the credentials to the remote resource, IIS is passing a hashed password. The remote resource cannot verify the password thus you get the "access denied" error.

On the other hand, if your browser client is authenticated to the IIS ASPX page by using Basic authentication, the IIS server has the client password and can make a primary token to pass to the remote resource. The remote resource can verify the password and does authenticate as the domain user. 

So please enable Basic authentication and disable Anonymous and Integrated authentication in IIS for FileVista. This will prompt the user for their credentials, authenticate them, and also pass the credentials as the WindowsIdentity to ASP.NET. Realize that Basic authentication sends user credentials in Base64 encoding, which can easily be decrypted. That's why I recommend that you use Secure Sockets Layer (SSL) with this configuration.

Let me know the result.

I disabled integrated authentication for the FileVista virtual directory. To confirm, all users, even those already domain-authenticated, are required to login.

Now when I try to add a new non-local virtual root in FileVista admin I get this error:
"Root folder is created but the given path does not exist physically and cannot be created."

I am using the same notation for the non-local roots as for the local roots: \\servername/sharename

Loren

It's fixed.

A Mac user reported an issue with Firefox for the Mac. There was some indication of digest authentication, so I turned that off for the FileVista virtual root. That fixed the Firefox issue and the non-local server issue.

One non-critical issue did pop up: A user reported that Opera doesn't work. I didn't get the version (I told him to use IE), but the symptom is that the page only partially loads and then freezes.

Loren

As you can see on the description site opera is not (yet?) supported.

http://www.gleamtech.com/products/
filevista.asp

Loren,
So did you turn off only "digest authentication" or "Integrated Windows Authentication" too for fixing the problem?

Opera is not supported because of some limitations, for example it does not allow the web applications to pop-up their own context menu. Partially loading issue may be fixed but context-menu issue is a bigger problem.

Hi Cem-

I have both Digest and Integrated auth methods disabled for that virtual directory. So it is using basic auth only, but SSL is required.

Thanks for all your help and for the great product!

Loren