php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #71883 PHP exec() over UNC path on Windows
Submitted: 2016-03-22 21:10 UTC Modified: 2017-07-25 19:47 UTC
Votes:10
Avg. Score:4.5 ± 0.7
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:7 (70.0%)
From: hobbes at visionfriendly dot com Assigned:
Status: Verified Package: IIS related
PHP Version: 5.6.19 OS: Windows 2012R2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: hobbes at visionfriendly dot com
New email:
PHP Version: OS:

 

 [2016-03-22 21:10 UTC] hobbes at visionfriendly dot com
Description:
------------
My environment is Windows Server 2012 R2, IIS 8, Active Directory, and a file share. IIS, AD, and the file share are all separate VMs.

I have a website, www.example.com, set up in IIS. The application pool identity is set up as the AD user IUSR_example, which has "full control" permissions on the folder containing the site files. The site files are on the file share, which IIS references via UNC path.

In general, the site works in that it can serve up PHP, ASP.Net, and ASP Classic pages, and the code can even create new files.

However, I am having a problem that seems specific to PHP exec(). I've tried calling whoami, dir, and ffmpeg, and I get nothing returned from them. Using Sysinternals Procmon I have confirmed that the executable never starts.

Weirdly enough, I am able to make the exact same calls with ASP Classic (using WScript.Shell), and it works perfectly. I am also able to get PHP exec() working when the scripts are NOT running over the UNC path. 

Here's what I've tried/found:

•When using ASP, procmon reports that w3wp.exe spawns a cmd.exe process, which in turn spawns conhost.exe and (for example) ffmpeg.exe. The output file from ffmpeg successfully appears.
•When using PHP, procmon reports that w3wp.exe spawns a php-cgi.exe process, which in turn creates a cmd.exe and a conhost.exe. A thread for ffmpeg.exe never appears.
•cmd.exe is invoked with a command line that looks like this: cmd.exe /c ""--the command to be executed--""
•The command line for the cmd.exe process is exactly the same for both ASP Classic and PHP.
•In Procmon, the user is always reported as IUSR_example 
•I've tried adding 2>&1 to the end of the command
•I've tried giving the IUSR to the "Replace Process-level Token" right
•I've tried turning off FastCGI impersonation and switching between "NamedPipe" and "TCP" under Process Model > Advanced Settings
•There are no errors in the PHP error log
•There are no errors in any of the Windows Event logs

Note that this is not specific to ffmpeg. Any other use of exec() also fails. Also, I would prefer not to use WScript.Shell from within PHP because eventually we will be using WordPress plugins that rely on exec().

How can I further troubleshoot this?

(I posted this on ServerFault, but so far there haven't been any answers.)

Test script:
---------------
$cmd = '"\\\\myShare\\inetpub\\wwwroot\\example.com\\ffmpeg\\bin\\ffmpeg" -i "\\\\myShare\\inetpub\\wwwroot\\example.com\\input.jpg" -vf  "crop=100:100:70:80" "\\\\myShare\\inetpub\\wwwroot\\example.com\\output.jpg"';

exec($cmd, $output, $return_var);

Expected result:
----------------
Procmon indicates that ffmpeg starts.

A new file appears called output.jpg

Actual result:
--------------
Procmon does not indicate that ffmpeg starts.

Output.jpg does not appear

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-03-23 03:53 UTC] pajoye@php.net
Check what happens in proc open to see what kind of errors happen where.

If you copy it (anonymize it) on gist :)
 [2016-03-23 17:36 UTC] hobbes at visionfriendly dot com
Wow.  Using proc_open() allowed me to successfully execute commands.  This in turn allowed me to use procmon to discover the difference between the way I was using exec() and proc_open().  Long story short, I would call this a core bug in PHP running on Windows when the PHP scripts are on a network share.  Here are the key details:

* exec() defaults the current working directory to the path of 
  the PHP script, which in my case is a UNC path.
* cmd.exe does not allow you do have a UNC path as the current 
  working directory, and cmd.exe claims that it will revert to 
  the Windows folder.
* Although cmd.exe continues to execute and conhost.exe is 
  spawned, the original working directory still causes some 
  sort of problem, and the desired executable is never started.

So a simple workaround is to chdir() to a local directory before calling exec().  However, there are a lot of WordPress plugins that rely on exec(), so in my opinion exec() should be agnostic to whether the PHP script is running on a share.

Thank you for your help, @pajoye!  What can we do to get this submitted as a bug to be fixed in the next release?
 [2017-01-18 17:27 UTC] internero at gmail dot com
Exactly same issue here: but with PHP 5.4.24 running on IIS 7.5 with Windows Server 2008R2, inside a load balanced server farm, using UNC paths to share PHP files to servers.

The big problem is that we cannot just chdir() to a local drive/folder because the command passed to exec() save files. If we change chdir(), files saved just get lost (ie go to the wrong place).

I think this need to be fixed in all PHP versions with active support.

And thanks a lot for finding the the actual reason of processes not running when using UNC path.
 [2017-07-25 19:47 UTC] kalle@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2017-07-25 19:47 UTC] kalle@php.net
Reclassified as a doc issue
 [2018-04-24 13:57 UTC] frank at louwers dot be
Please note this is Windows related, not (only) IIS related. Happens in Windows + Apache + PHP as well!

As a workaround, use the chdir() method. Do not try to be clever and try to avoid this issue by moving make a "symlink" (or whatever that's called in the windows world) to the UNC. You will then suffer from wierd 403 bugs that only pop up once every X request.
 [2023-01-05 11:45 UTC] melindaetinw81 at gmail dot com
this might help.....
(https://www.myatriumhealth.us/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 14:01:29 2024 UTC