Laravel Storage: Permission Issue - Storage::move() vs get(), put(), delete()

Question

I find this a little odd. Using the laravel Storage facade, if I try to move a file:

Storage::move ($source_file, $dest_file);

I'm given the following error:

rename(/source/file/name1.docx, /dest/file/name2.docx): Permission denied

However, if I try to explicitly take a copy of the file, write it to the destination, and remove the original as follows:

$fcontents = Storage::get ($source_file);
Storage::put ($dest_file, $fcontents, 'public');
Storage::delete ($source_file);

It works just fine.

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.

From a shell command, if I execute a move (with the same user as that running the nginx service) mv /source/file/name1.docx /source/file/name2.docx, it doesn't complain about any permission problems.

Anyone have a clue?

---

EDIT 20/02/2018 to add more info

The samba mount looks as follows in /etc/fstab

//10.1.12.123;public /my/mount/point/public cifs credentials=/my/passfile,uid=1003,gid=1003 0 0

The mount works fine, and I can traverse the filesystem in my Bash shell.

@> ls -lFd /my/mount/point/public
drwxrwxrwx 11 webuser webgroup  0  Dec 4 13:30 /my/mount/point/public//

(I'm not sure if the double-slash at the end of the above line is significant).

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.

Answer 1

It may be that the answer is in the documentation!

Laravel's Illuminate\Filesystem{} class makes use of the PHP function rename().

Reading in the detail of the documentation page on this function, I found the following >>

On UNIX-like operating systems, filesystems may be mounted with an explicit uid and/or gid (for example, with mount options "uid=someuser,gid=somegroup"). Attempting to call rename() with such a destination filesystem will cause an "Operation not permitted" warning, even though the file is indeed renamed and rename() returns (bool) true.

This is not a bug. Either handle the warning as is appropriate to your use-case, or call copy() and then unlink(), which will avoid the doomed calls to chown() and chmod(), thereby eliminating the warning.

Sigh. It may not be a bug, but it certainly feels like one.

Besides, although it feels close, this doesn't completely reflect my problem, because the file is not "indeed renamed" (i.e. moved) correctly. And "Operation not permitted" is not the error I receive. Still, it's the most likely explanation I've found so far.