Edit report at http://bugs.php.net/bug.php?id=50542&edit=1

 ID:               50542
 Comment by:       
 Reported by:      dd at headlineweb dot nl
 Summary:          scandir() cannot open UNC paths since PHP 5.3.1
 Status:           Feedback
 Type:             Bug
 Package:          *Directory/Filesystem functions
 Operating System: win32 only - W2003
 PHP Version:      5.3.1
 Assigned To:      pajoye

 New Comment:

Hi Pajoye,



thanks for your fast reply. I've dugg a bit deeper (thanks to your link)
and got it working by leaving ""Physical Path Credentials" untouched
(viz. take over the credentials from the Application Pool) and by
changing the "Physical Path Credentials Logon Type" from "ClearText" to
"Network".



By doing so it now works fine.



Regards and thanks for your help,

Bram.


Previous Comments:
------------------------------------------------------------------------
[2010-03-09 15:59:47] paj...@php.net

hi Bram,



This doc (IIS link) is incomplete, it is important to remember that the
IUSR(_xxx) is impersonate and anonymous. See:



http://support.microsoft.com/kb/207671



This user also has limitations per default, which limits access to
remote resources. The reasons and possible workarounds are explain in
this kb.



PHP 5.2 impersonation was only partial and fails to actually run a
process under the choosen users.



We have tested 5.3 share access (normal shares or DFS) successfully
using 2k3, 2k8 (incl. R2 for both). To test it:



- create a user´(site1user for example)

- Open the IIS manager

- change the Physical Path Credentials (iis 7.x) and set it to this new
users

- be sure that this user has access to the remote shares

------------------------------------------------------------------------
[2010-03-09 15:34:52] bramus at bram dot us

Just tested both the PHP 5.3.2 and the (in this thread posted) PHP
5.3.3-dev builds and the problem still remains.



The problem occurs on both WIN2K8 (IIS7) and WIN2K8R2 (IIS7.5) servers.

Haven't tested on WIN2K3 though.



And yes, impersonate is enabled (as per instructions as seen on
http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/)
and the IIS user has access to the needed folder and files (the given
site runs fine when PHP 5.2.x is used).



Right now I'm getting this (both PHP 5.3.2 as PHP 5.3.3-dev) returned on
a file where the IIS User + the magic "Everyone" has access to:

- file_exists: false

- filesize: stat failed for $file

- file_get_contents: permission denied

- etc.



Regards,

Bram.

------------------------------------------------------------------------
[2010-02-25 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

------------------------------------------------------------------------
[2010-02-17 22:49:18] paj...@php.net

@dd at headlineweb dot nl 



We have setup a test environment with two windows server 2003. File/dir
operations work as expected using 5.3.2RC2.



However, it is important to verify that the php user (IUSR_xxx for
example) actually has access to the share. That's also means that
impersonate must be set. The default IIS user did not have access to the
shares (or any other resources but www).



You said earlier that impersonate is set and the user has access to the
share. Can you verify that it is actually set? If it still fails, then
we will cruelly need access to your config or at least the exact details
about the settings you use on each server. So we can setup the exact
same config in our labs (at Microsoft).





------------------------------------------------------------------------
[2010-02-14 13:20:04] dd at headlineweb dot nl

Hi pajoye,



sorry, but it still does not solve my problem with this package:



php-5.3.2RC2-nts-Win32-VC9-x86.zip

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=50542


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50542&edit=1

Reply via email to