title: Laravel Storage: Permission Issue - Storage::move() vs get(), put(), delete()
body: <p>I find this a little odd.  Using the laravel <a href="https://laravel.com/docs/5.6/filesystem#retrieving-files" rel="nofollow noreferrer">Storage</a> facade, if I try to move a file:</p>
  
  <pre><code>Storage::move ($source_file, $dest_file);
  </code></pre>
  
  <p>I'm given the following error:</p>
  
  <pre><code>rename(/source/file/name1.docx, /dest/file/name2.docx): Permission denied
  </code></pre>
  
  <p>However, if I try to explicitly take a copy of the file, write it to the destination, and remove the original as follows:</p>
  
  <pre><code>$fcontents = Storage::get ($source_file);
  Storage::put ($dest_file, $fcontents, 'public');
  Storage::delete ($source_file);
  </code></pre>
  
  <p>It works just fine.</p>
  
  <p>I'm running Laravel on an nginx CentOS platform.  A slight complicating factor is that the underlying file-system is a mounted Samba share.  However, this causes no issues on the command-line.</p>
  
  <p>From a shell command, if I execute a move (with the same user as that running the nginx service) <code>mv /source/file/name1.docx /source/file/name2.docx</code>, it doesn't complain about any permission problems.</p>
  
  <p>Anyone have a clue?</p>
  
  <hr>
  
  <p><strong>EDIT 20/02/2018 to add more info</strong></p>
  
  <p>The samba mount looks as follows in <code>/etc/fstab</code></p>
  
  <pre><code>//10.1.12.123;public /my/mount/point/public cifs credentials=/my/passfile,uid=1003,gid=1003 0 0
  </code></pre>
  
  <p>The mount works fine, and I can traverse the filesystem in my Bash shell.</p>
  
  <pre><code>@&gt; ls -lFd /my/mount/point/public
  drwxrwxrwx 11 webuser webgroup  0  Dec 4 13:30 /my/mount/point/public//
  </code></pre>
  
  <p>(I'm not sure if the double-slash at the end of the above line is significant).</p>
  
  <p>As an aside, the 777 privilege is defined by the mounting process apparently.  I don't seem to have the ability to change this.  I shall look to reducing this privilege as an off-line activity, but for the purposes of this problem what I intend to demonstrate is that file-system level permission does not seem to be the cause of the problem.</p>