Question

我发现这有点奇怪。如果我尝试移动文件，请使用laravel Storage外观：

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

我发出以下错误：

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

但是，如果我尝试显式获取该文件的副本，请将其写入目标，然后删除原始文件，如下所示：

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

它运作得很好。

我在nginx CentOS平台上运行Laravel。一个轻微的复杂因素是底层文件系统是已安装的Samba共享。但是，这会导致命令行没有问题。

从shell命令，如果我执行移动（使用与运行nginx服务的用户相同的用户）mv /source/file/name1.docx /source/file/name2.docx，它不会抱怨任何权限问题。

任何人都有线索？

编辑20/02/2018以添加更多信息

samba mount在/etc/fstab

中的内容如下所示

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

mount可以正常工作，我可以遍历Bash shell中的文件系统。

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

（我不确定上述行末尾的双斜线是否显着）。

顺便说一句，777特权显然是由安装过程定义的。我似乎没有能力改变这种状况。我将把这个权限作为一个离线活动来减少，但是出于这个问题的目的，我打算证明文件系统级权限似乎不是导致问题的原因。

Answer 1

可能答案在文档中！

Laravel的Illuminate\Filesystem{}类使用PHP函数rename()。

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

在类UNIX操作系统上，文件系统可能附带了   显式uid和/或gid（例如，使用mount选项   ＆＃34; UID =对待SomeUser，GID = somegroup＆＃34）。试图用这样的方法调用rename（）   目标文件系统将导致＆＃34;操作不被允许＆＃34;   警告，即使文件确实已重命名并且rename（）返回   （布尔）是的。

这不是错误。根据您的要求处理警告   用例，或调用copy（）然后unlink（），这将避免   注定要调用chown（）和chmod（），从而消除警告。

叹息。它可能不是一个错误，但它确实感觉像一个。

此外，虽然感觉很接近，但这并不能完全反映我的问题，因为文件不＆＃34;确实已重命名＆＃34; （即移动）正确。并且＆＃34;不允许操作＆＃34;不是我收到的错误。不过，这是我迄今为止发现的最可能的解释。

Laravel存储：权限问题 - 存储:: move（）vs get（），put（），delete（）

1 个答案: