I'm using Windows 7 x64 Enterprise, IIS, and PHP 5.6.32 in my development environment. My application's website has the following settings:
My production server is the same setup running on Server 2008 R2.
I am needing to use exec()
, shell_exec()
, etc. to execute an executable (pdftk if it matters). However, whenever I use any of these functions, I always get "Unable to fork XXX"
in the PHP error log. I've tried runing whoami
, ping xxx
, and other simple commands with the same result. None of the typical shell functions will work--they always result in the same error. I have checked my php.ini
file and verified those functions haven't been disabled.
However, in my production environment, I do not have this problem, and I have no clue why. It only seems to be affecting my development environment. During my research, I did stumble across this (http://tech.trailmax.info/2012/12/php-warning-shell_exec-unable-to-execute-on-iis-7/) which, for some reason, does fix my problem; but, it completely breaks my SQL Server Windows authentication (which I need).
I have also disabled my antivirus in hopes maybe it was the culprit. It was not.
While doing more troubleshooting, I did find that proc_open()
does work. We are using Prince for generating PDFs and I noticed it was working, while my exec()
wasn't. When I looked at the Prince class, I discovered it was using proc_open()
which explains why it seems to work.
Does anyone know why exec()
and the related functions seem to work without issue in my production environment and not my development environment? And why does proc_open()
work but the other shell functions do not? Thanks!
I wanted to post an update to this since I figured out the issue. The answer can be found here in the very last post by 1heer2351 at zonnet dot nl1
:
Located the problem and have been able to fix it.
I am using a special user for my Application Pool (say AppPoolUser), so PHP runs as this user. The new exec function uses CreateProcessAsUser() with impersonation. This means that the AppPoolUser must have the right to change the process level token.
You can assign this right to the user in the "Local Security Settings" -> User Rights Assignment.
I have granted my AppPoolUser the "Replace a process level token" setting -> fork error has gone.
Thought this might be useful information, so access is required to cmd.exe but in addition the "Replace a process level token" setting.
This is exactly what I did. I had created a new App Pool User using my domain account. By default, the Replace a process level token
setting includes DefaultAppPool
. Since I created a new App Pool User, it was not included in this policy setting. Adding the App Pool User I created resolved my issue.