这两天,连续有朋友向我咨询Joomla\Filesystem\File::delete: Failed deleting inaccessible file e073973564324817a97a08fec366b16e这个问题,最开始以为是简单的权限问题,但实际的发现,后台的目录权限都是正常,因此,就决定研究一下,看看这个问题的具体原因。由于我本地的服务器从来没有遇到过此类问题,因此,本案例使用的是一个购买D计划朋友的测试环境,为阿里云的虚拟主机。

1,问题描述


用户购买了D计划的全站包,然后部署到阿里云的虚拟主机上,一切都正常,但是当修改全局设置,点击保存的时候程序提示错误Joomla\Filesystem\File::delete: Failed deleting inaccessible file e073973564324817a97a08fec366b16e。错误截图如下:

delete_error.png

2,问题分析


上面的错误已经很明显的提示不能删除文件,那么肯定是文件的权限不够,并且看这个文件的文件名,应该是一个临时文件。那么就进一步的确定,可能是tmp这个临时文件的写权限没有。因此,第一步,我的检查就是登录后台,在全局设置->文件夹权限一栏中查看。结果让我有点失望,上面显示都是正常的。如图:

目录权限ok.png

最后面一行清楚的说明了tmp临时目录是可写的。这怎么可能?

3,寻找解决方案


3.1 升级Joomla

使用google搜索,发现遇到这种的问题的人很少,那么基本上可以判断这是一个小众问题,很可能是我犯了一些低级错误,或者这个问题只在某一些固定的区域才会发生。

按照经验,对Joomla核心进行了升级从原先的3.9.3升级到了最新的3.9.8版本。升级之后,清理了缓存,发现问题依然存在

3.2 降低PHP版本

通过后台,可以看到用户使用的PHP版本为7.2.这个版本我用得比较少,可能是版本太高导致的问题。因此,就将服务器的PHP版本切换到7.0,然后重启,发现问题依然存在。

3.3 验证测试环境

这个时候就非常的困惑了,这个问题怎么会发生呢。难道是代码有问题,我将用户的网站备份,放到我的环境中,发现工作完全正常啊。这就坚定了肯定是服务器环境的问题,但问题出在了什么地方呢。

3.4 分析源码

开始分析Joomla的源码,在libraires/src/filesystem/file.php这个文件中找到了源码,发现代码逻辑上并没有错误,当文件无删除权限的时候抛出异常。那么最终的可能就是tmp下的文件真的可写吗?

带着这个疑问,在ftp目录下找到了tmp目录,在这个目录下,发现了问题,文件居然不可写。如图:

不能删除文件.png

上图中的权限一栏 是rw-r--r-- 。joomla对这个文件没有写权限,这怎么可能?首先我已经设置了tmp目录为777,其次,这个文件明显是一个临时文件为joomla创建,为什么会没有写权限呢?这也太奇怪了。我马上联想到虚拟空间的管理后台,在调整权限的地方感觉和以往的程序不太一样,感觉挺别扭的。截图如下:

虚拟空间设置权限.png

这个权限设置的界面,看似很高级,但对真正的程序员来说,这个设置界面有些让人疑惑的地方,还不如直接让我写777更直接。

上面虽然我已经成功了将tmp目录设置为可读可写,但是tmp目录下新的文件的权限还是不可写(Joomla每一次执行都会产生一些临时文件,虽然你可以通过ftp对不能删除的文件修改权限,但新产生的文件依然没有删除权限,所以即使你删除了上面提示的文件,这个错误也不会消息的)

joomla程序写权限.png

问题分析到这了,基本上就清楚了,客户的虚拟主机有一套自己的权限控制机制,而这套控制机制是有bug。客户无法通过ftp客户端或者管理后台来对其进行调整。只能提交工单。  

3,总结


如何解决这个问题呢?

请联系你的空间提供商,让他们将tmp目录设置为程序可读可写。最主要的一点就是要让程序产生的临时文件可读可写。

用户评分: 0 / 5

不活动星星不活动星星不活动星星不活动星星不活动星星
 

评论

  • 未找到评论