Bug #68926 [Com]: is_writable returns false but file_put_contents works

From: Date: Fri, 26 Aug 2016 12:48:12 +0000
Subject: Bug #68926 [Com]: is_writable returns false but file_put_contents works
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-203572@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68926&edit=1 ID: 68926 Comment by: alex dot goris at fastlikehell dot com Reported by: lukyer at gmail dot com Summary: is_writable returns false but file_put_contents works Status: Analyzed Type: Bug Package: *Directory/Filesystem functions Operating System: Windows 8 64b Prof. PHP Version: 5.6Git-2015-01-27 (Git) Assigned To: ab Block user comment: N Private report: N New Comment: I believe I have this bug in my development environment. I am running PHP 5.6.22, 64-bit version, my workstation is Windows 10 Pro x64. I am developing in Visual Studio using the DevSense phptools plugin, this plugin debugs the code using xdebug and the built-in webserver of php.exe I have created the following test script: <?php var_dump(is_writable("//10.151.140.102/TestAlex/SubFolder1/")); var_dump(file_put_contents("//10.151.140.102/TestAlex/SubFolder1/Test.txt", "Testing...")); var_dump(is_writable("//127.0.0.1/c$/temp/SubFolder1/")); var_dump(file_put_contents("//127.0.0.1/c$/temp/SubFolder1/Test.txt", "Testing...")); ?> Which outputs: script1.php:2:boolean false script1.php:3:int 10 script1.php:4:boolean true script1.php:5:int 10 Note that the first line returns false However, I do have write permissions on the //10.151.140.102/TestAlex/SubFolder1/ folder. Also, the Test.txt file exists in that directory with the 'Tersting...' string. Note that am a member of the Administrators group on the 10.151.140.102 machine. I was surprised to see the is_writable() function returning true on the \\127.0.0.1\c$\... share, this I can not explain... This is going wrong on 2 different development machines (both running above mentioned configuration). On our test webserver, which runs Windows 2008 R2 x64, Apache 2.4.4 and php 5.6.16 the is_writable() function correctly sees the \\10.151.140.102\TestAlex\... path as writable and returns true Previous Comments: ------------------------------------------------------------------------ [2015-06-05 17:34:21] ab@php.net @webmastersguide2000, thanks for the report. How it looks like, your issue is different from what is originally reported here. If it is on the local FS, it's most likely a misconfiguration. The unmapped unix users are unlikely to be in the game, but what were imaginable for example is the ACLs difference concerning the system account for CLI and the impersonated account used under IIS. If you still think it's the same issue, please prove it with some stable reproduce case. Maybe some rolle could play that those files are additionally shared through SMB. Please test also the latest VC11 builds like PHP 5.6, the 5.4 branch only accepts the security fixes so we won't be able to pass any corrections there, just for the case. Thanks. ------------------------------------------------------------------------ [2015-06-04 21:28:02] webmastersguide2000 at yahoo dot com > This issue is related to SAMBA. The problem does occur when files are accessed locally, without SMB. (SAMBA is Linux, SMB is Windows). In our case, the storage is _also_ shared from the affected machine to other clients via SMB, but the problem occurs when the files are accessed locally, not via SMB. ------------------------------------------------------------------------ [2015-06-04 21:06:42] yohgaki@php.net This issue is related to SAMBA. Anyone who experiences this, please add your Samba configurations. There is similar issue reported for session storage on mounted (shared) file system. This may be the reason why some users have session storage issue on mounted files under windows. ------------------------------------------------------------------------ [2015-06-04 19:13:28] webmastersguide2000 at yahoo dot com I get a similar symptom going back to at least 5.4.19, but without Samba. We are running: PHP Version 5.4.19 System Windows NT DEV-LMS2 6.1 build 7601 (Windows Server 2008 R2 Enterprise Edition Service Pack 1) i586 Build Date Aug 21 2013 01:06:09 Compiler MSVC9 (Visual C++ 2008) Architecture x86 Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--disable-isapi" "--disable-nsapi" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci=C:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=C:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8-11g=C:\php-sdk\oracle\instantclient11\sdk,shared" "--with-enchant=shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--with-mcrypt=static" "--disable-static-analyze" "--with-pgo" In my case at least, is_writeable also returns false for directories which are writeable. ------------------------------------------------------------------------ [2015-02-12 19:00:59] ab@php.net I've spent some time on debugging this and can confirm. The reason for this behavior is here https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ChangeNotes.html#id2578661 . You probably could check that - you use samba3 or above - the folder owner is mapped to something like "nobody", with either full or restricted access rights (use right click -> security -> advanced) You also could play with the access rights on the linux machine, just to see whether it changes something in PHP behavior. The issue here is that unmapped unix user accounts are mapped to built-in windows SIDs, which are obviously have nothing to do with windows ACLs. We could currently look whether it's possible to cover this part within PHP. In general it looks more like samba compat issue, because as you've mentioned - the native shares work well. Regards ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=68926 -- Edit this bug report at https://bugs.php.net/bug.php?id=68926&edit=1

« previous php.bugs (#203572) next »