Laravel 存储：权限问题 - Storage::move() 与 get()、put()、delete()答案

【问题标题】：Laravel Storage: Permission Issue - Storage::move() vs get(), put(), delete()Laravel 存储：权限问题 - Storage::move() 与 get()、put()、delete()
【发布时间】：2018-07-27 16:32:23
【问题描述】：

我觉得这有点奇怪。使用 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 以添加更多信息

/etc/fstab 中的 samba 挂载如下所示

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

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

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

（我不确定上一行末尾的双斜杠是否重要）。

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

【问题讨论】：

您是否检查了源目录和目标目录的所有权和权限。移动文件有时会出现问题，但复制没有问题。那么请您确认您在该服务器上的目录权限和所有权。
@webDev 我安装的 Samba 驱动器上的权限是 777。这不是我可以控制的，因为 cifs 安装过程似乎代表我设置了权限。
@webDev 我已经更新了问题描述，以便为您添加更多信息。

标签： php laravel centos laravel-storage

【解决方案1】：

可能答案就在文档中！

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

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

在类 UNIX 操作系统上，文件系统可以使用显式 uid 和/或 gid（例如，使用挂载选项 “uid=someuser，gid=somegroup”）。尝试用这样的方式调用 rename() 目标文件系统将导致“不允许操作” 警告，即使文件确实被重命名并且 rename() 返回（布尔）真。

这不是错误。处理适合您的警告用例，或调用 copy() 然后 unlink()，这将避免注定要调用 chown() 和 chmod()，从而消除警告。

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

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

【讨论】：