text: go to bug id or search bugs for
  New/Additional Comment:
  Description:
  ------------
  When samba drive is mapped in Windows, call to is_writable returns false on folders and files although these are actually writable.
  is_readable seems working ok.
  Test script:
  ---------------
  echo is_writeable("Z://fdvtest"); // returns 0
  file_put_contents("Z://fdvtest/file", "content"); // works fine
  Add a Patch
  Add a Pull Request
  Cannot reproduce here:
  var_dump(is_writable('p:\tmp'));
  var_dump(file_put_contents('p:\tmp\hello.txt', 'hello'));
  this delivers
  bool(true)
  int(5)
  @lukyer please check what exactly is causing this behavior and provide some more data, so we can reproduce and debug.
  Thanks.
  Drive Z in my case is Samba mapped drive using "Map network drive" function in Windows Explorer. "tmp (\\192.168.0.15\bughunt)". Any other drives works as expected. Just network Samba drives are problematic.
  var_dump(is_writable('Z:\tmp'));
  var_dump(file_put_contents('Z:\tmp\hello.txt', 'hello'));
  output:
  bool(false)
  int(5)
  I've spent some time on debugging this and can confirm. The reason for this behavior is here .
  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
  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" "-" "--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.
  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.
  > 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.
  @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.
  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
  Related To: Bug #73543
  This is not directly related to Samba.
  Accessing AD share from a machine not joined to domain produce similar results.
  Bottom line is: You MUST NOT make any decisions based on manual ACL inspection, if you are not the access control entity.
  I've had to namespace something to get my code going forward.
  <?php
  namespace Same\As\One\You\Use\Them\In;
  function is_readable($file)
  {
  if(file_exists($file) && is_file($file))
  {
  $f = @fopen($file, 'rb');
  if(fclose($f))
  {
  return true;
  }
  }
  return false;
  }
  function is_writable($file)
  {
  $result = false;
  if(file_exists($file) && is_file($file))
  {
  $f = @fopen($file, 'ab');
  if(fclose($f))
  {
  return true;
  }
  }
  return false;
  }
  ?>
  I confirm, that this issue is not related to Samba. My setup is a mapped NFSv4 network drive between two linux machines. The client is not part of the domain, while the server is.
  ()
  This Stackoverflow question covers additional information about my setup. User id mapping seems to be correct for example.