3

我觉得这有点奇怪。使用 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 挂载如下所示/etc/fstab

//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 特权显然是由安装过程定义的。我似乎没有能力改变这一点。我将把这个特权作为一种离线活动来减少，但是为了解决这个问题，我打算证明文件系统级别的权限似乎不是问题的原因。

4

1 回答 1

2

答案可能在文档中！

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

阅读有关此功能的文档页面的详细信息，我发现以下内容>>

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

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

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

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

于 2018-02-20T10:56:44.653 回答