Help with IO.DirectoryInfo

[Rhodo]

I'm new to VB.net and tasked with moving an older web application to a new server. Among other functions, this application looks for PDFs in a folder using IO.DirectoryInfo. When I run the application within Visual Studio, it works with no error. But when I publish the site to IIS v10 on a network server, the following code returns the following error:

Dim di As New IO.DirectoryInfo("\\Pdf-server\Pdfs\New")

produces error (not sure why the error message strips the slashes '\'):

Source: mscorlib Exception: Access to the path \Pdf-serverPdsNew is denied.

The folder's permissions and sharing are open to this account & folder's read-only is turned off. Any idea what's happening here?

[Rhodo]

sorry, error message is:

Source: mscorlib Exception: Access to the path \Pdf-serverPdfsNew is denied.

[techgnome]

The folder's permissions and sharing are open to this account

Are you sure about that? Have you verified the account it's running under?

-tg

[Rhodo]

Are you sure about that? Have you verified the account it's running under?

-tg

I confirmed it with our network admin. And, I'm able to navigate to the folder and create a .txt file. The application uses windows authentication. Is this login user the account that needs access? Or is it some built-in IIS account? Is there another way I can determine if it's a permissions issue?

[PlausiblyDamp]

If your application is running under IIS then it will be the identity of the App Pool that needs to be given permissions. https://docs.microsoft.com/en-us/iis...ool-identities is an old article but still pretty relevant about the topic.

[techgnome]

I confirmed it with our network admin. And, I'm able to navigate to the folder and create a .txt file. The application uses windows authentication. Is this login user the account that needs access? Or is it some built-in IIS account? Is there another way I can determine if it's a permissions issue?

built-in IIS account <- this ... it's likely using the built in ISUSER (or something close to that) and needs to be granted access. That's why I asked have you verified the account it's running under.

-tg

[Rhodo]

This is very helpful. Thank you both. The application pool identity is "ApplicationPoolIdentity". I don't see this as an account I can grant access in the folder -> security tab. Should I see this account? I added "IIS_IUSERS" to the folder's security tab, but I'm still getting the "access is denied" error. Not sure it matters, but IIS and this folder are on different machines. Is there something I'm missing?

[Rhodo]

This problem persists. It appears to be an issue when accessing a folder on a remote server.

When I point IO.DirectoryInfo to a folder on the IIS machine (I'll call, \\web_server\pdf_folder) , it works!

But when I point to a folder on a remote server (\\file-server\pdf_folder), I get "access denied".

On the remote server (\\file-server\pdf_folder), I've given the group file-server\IIS_IUSRS full control on the folder. And, for the application pool, I tried all the built-in accounts and also a custom account with admin privileges. But still no luck. Anyone have a clue what's going?

[OptionBase1]

Remember - accessing a share on a remote server requires you have permissions in TWO places:

1. The "Share" permissions.
2. The "Folder" permissions.

If all you've changed is the "Folder" permissions, then perhaps the "Share" permissions are still preventing access. Most restrictive wins. Full control on the folder level + no access on the share level = no access through the share.


If that doesn't work, one more option is, on the IIS machine where you CAN open a folder:

-Enable auditing on that folder so that when that folder is accessed an event is generated.
-Run your code that successfully accesses that folder.
-Check the event logs and see what user account it was that accessed that folder, that is the account that IIS is using for accessing content.
-Perhaps it is a different account than you think.

Edit: Or, depending on what level of security auditing is enabled on the remote server, you might already be able to see, in the Security log on the remote server, login/authentication attempts originating from the IIS server, and that should list the account that is being used as well.

[sapator]

Firstly , i don't think IIS_IUSRS applies to PC to serverfolder , I think the permission is under USERS or NT authority or something similar. I'm no expert at this so ask your admin.
Also i would just do an on-0ff given the folder an EVERYONE with full permissions . Just for the test and then remove the permissions.
If this does not work, I have seen at work occurrences that it may not matter what permissions you give to the folder and run the app after if the remote PC is under an administrative root.
What you may try if that is the case is impersonation, so this is my POST no #7 on this tread: https://www.vbforums.com/showthread....(User-folders)
Note that this: If LogonUser("username", "domain", "password", 3, 0, tokenHandle) may have to be changed to this: If LogonUser("username", "domain", "password", 9, 0, tokenHandle) , if it does not work.
Make sure you are given the correct username, password and domain from your admin with FULL permissions. If it works then your admin can lower down the permissions and you keep testing until you find the absolute minimum permissions that this will work.

If nothing works then check your files and folder NOT to be read only.

[techgnome]

Also, I don't think IIS_IUSRS is a global account, or a network account, it's a local machine account... it's used to access local resources when necessary. So the IIS_IUSRS account on machine A isn't the same as IIS_IUSRS account on machine B ... in fact, if I recall correctly (and there is a chance I could be wrong about this) they are provisioned as "MachineA/IIS_IUSRS" and "MachineB/IIS_IUSRS" as opposed to "DOMAIN/IIS_ISUSRS" which is why it still doesn't work when reaching across to a remote system. This is by design. What you SHOULD be doing is creating a properly provisioned domain user, grant that user the access, and then impersonating that user when you need to reach across network resources.

-tg

[Rhodo]

Ah, that makes sense! Setting the impersonation to a specific user in web.config worked! Thank you sapator and techgnome!

[techgnome]

Awesome... I didn't realize you were resource hopping at first, otherwise I would have pointed you in that direction at first. Man, that drags up some (not so) fond memories.

-tg