PHP File Operations using UNC Paths on IIS7
Hi folks
I'm having some trouble with a PHP script I've written to write some directories to the file system using IIS7.5.
I'm using Windows Authentication with Anonymous Authentication disabled (thus current user credentials are passed through to IE). The script would run and write files to the same server and worked fine.
The directory being written to definitely has the correct permissions. When writing to the directory on FS1, I was originally using the local disk drive:
This worked. I've made sure the user logged in (thus running the script) also has Full Control to the directory.
Because this folder is shared out to users as "Data", I then changed this to a UNC path:
This also worked.
However, I've moved the website to an alternative server (to seperate roles). The previous server (FS1) is now just a file server, with the second (WEB1) hosting the website. Both are Win2k8 R2 VMs using IIS7.5.
If I use the same UNC path on WEB1, I get a permission denied PHP error when running mkdir. I've tried writing back the other way as well (run the script from FS1 to a folder on WEB1) and get the same result.
I have Kernel-mode authentication turned OFF, extended protection turned OFF and Kerberos as the only authentication provider.
So I'm not sure why if I write to a UNC path on the same server all is fine, but if i write to a UNC path on a different server (same NTFS permissions) I get "permission denied".
I'm having some trouble with a PHP script I've written to write some directories to the file system using IIS7.5.
I'm using Windows Authentication with Anonymous Authentication disabled (thus current user credentials are passed through to IE). The script would run and write files to the same server and worked fine.
The directory being written to definitely has the correct permissions. When writing to the directory on FS1, I was originally using the local disk drive:
$basepath = D:\\Data;This worked. I've made sure the user logged in (thus running the script) also has Full Control to the directory.
Because this folder is shared out to users as "Data", I then changed this to a UNC path:
$basepath = \\\\FS1\\Data;This also worked.
However, I've moved the website to an alternative server (to seperate roles). The previous server (FS1) is now just a file server, with the second (WEB1) hosting the website. Both are Win2k8 R2 VMs using IIS7.5.
If I use the same UNC path on WEB1, I get a permission denied PHP error when running mkdir. I've tried writing back the other way as well (run the script from FS1 to a folder on WEB1) and get the same result.
I have Kernel-mode authentication turned OFF, extended protection turned OFF and Kerberos as the only authentication provider.
So I'm not sure why if I write to a UNC path on the same server all is fine, but if i write to a UNC path on a different server (same NTFS permissions) I get "permission denied".
Its probably because the account used doesn't allow network access. Check the account used for the application pool and for the web site.
Sometimes the PHP predefined constants are helpful. You might try using DIRECTORY_SEPARATOR in your file paths.
I am pretty sure this is due to permissons problems as I've mentioned before and not an issue with directory separators. Otherwise local unc path wouldn't work.
ASKER
Yeah you're right kmalte the local UNC path is working, just not when calling the UNC path to a remote server.
I've got the directory running as Windows Authentication (we're in an AD environment). I'm running the script in the browser logged in with my own account and the directory on the remote server also has Full Control NTFS permissions for my account (just the same as when testing a local server directory with the same NTFS permissions and it works).
So, the NTFS permissions are identical on both the remote and the local directory, but only fails if running the script against the remote UNC path.
I've got the directory running as Windows Authentication (we're in an AD environment). I'm running the script in the browser logged in with my own account and the directory on the remote server also has Full Control NTFS permissions for my account (just the same as when testing a local server directory with the same NTFS permissions and it works).
So, the NTFS permissions are identical on both the remote and the local directory, but only fails if running the script against the remote UNC path.
But what account is used for the application pool?
ASKER
Okay just checked what user was being used when running the script using Process Monitor, it's "IIS APPPOOL\DefaultAppPool"
So, as you suggest kmalte, it seems an issue with the app pool user? I've gone into Advanced Settings for the DefaultAppPool and the Identity is set to "ApplicationPoolIdentity".
So, as you suggest kmalte, it seems an issue with the app pool user? I've gone into Advanced Settings for the DefaultAppPool and the Identity is set to "ApplicationPoolIdentity".
Youre in the right place. What you need now is either an AD account (if the servers are in the same AD) or setup the same local account with the same password on both servers.
ASKER
Hmm I'd prefer to not specify the user. Given the application web site is using "Application user (pass-through authentication)", I'm guessing this is sent to the App Pool for use? So not sure why I would need to specify a single user?
Also, just to try it, I changed the Identity for the App Pool from ApplicationPoolIdentity to my own AD account as a custom account. After cycling IIS I was then unable to browse to the website in the browser using my AD account and got a 401 unauthorised error.
Also, just to try it, I changed the Identity for the App Pool from ApplicationPoolIdentity to my own AD account as a custom account. After cycling IIS I was then unable to browse to the website in the browser using my AD account and got a 401 unauthorised error.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Awesome, solved it using php bug #52376 as posted.
Hope I didn't break your sleep in :) 3pm here in Aust. Thanks so much for your help!
"The correct solution is to actually set the "Physical Path Credentials"Annoying bug, doesn't seem definite if it is a problem with PHP or IIS7, but alas a workaround. I'm using the latest version of PHP 5.3.3 so I guess the bug still isn't fixed.
This however raises an IIS bug that the credentials of the Application Pool don't get passed to the path correctly, although it's set to take over the App Pool credentials"
Hope I didn't break your sleep in :) 3pm here in Aust. Thanks so much for your help!
ASKER
Solved.