因此,我意外地运行了chmod -x /
与预期不同的程序,从而破坏了服务器上的大量内容。因此,我无法以正常方式登录,只能使用其他方法。
我试过这个修复意外 chmod 后的服务器权限但遇到了很多权限问题,有点像“更改 '/proc/sys/net/etc.' 的权限”,然后它仍然不起作用。我在很多其他目录中也遇到了这个问题。
如果您能告诉我如何解决这个问题或者您需要的任何其他信息,那就太好了。
答案1
该命令chmod -x /
仅从根目录中删除可执行位。如果您仍以以下身份登录根,您可以轻松地用 来撤销更改chmod +x /
。
显然您没有以以下身份登录根再也无法登录了,所以您已经将自己锁定在系统之外。这个问题仍然可以修复。我刚刚做了同样的事情,我运行了chmod -x /
,关闭了终端,结果系统崩溃了,我甚至无法重新启动。
我通过 Live-USB 启动解决了这个问题,问题是,我们无法使用它chmod
来恢复损坏的根文件系统的正确权限,因为它没有名称。但我们知道根文件系统存储为 inode 编号 2。我们可以使用该命令debugfs
来恢复正确的权限。
我们lsblk | grep -v loop
可以确定损坏的文件系统的设备名称。
然后我们可以debugfs -w /dev/sdXY
运行根,请看下面我的例子:
# debugfs -w /dev/sdb2
debugfs 1.44.1 (24-Mar-2018)
debugfs: modify_inode <2>
Mode [040644] 040755 # here enter correct permissions and hit enter
User ID [0] # here and in the following prompts only hit enter
Group ID [0]
Size [4096]
Creation time [1564191527]
Modification time [1564191527]
Access time [1567339087]
Deletion time [0]
Link count [24]
Block count high [0]
Block count [8]
File flags [0x80000]
Generation [0x0]
File acl [0]
High 32bits of size [0]
Fragment address [0]
Direct Block #0 [127754]
Direct Block #1 [4]
Direct Block #2 [0]
Direct Block #3 [0]
Direct Block #4 [1]
Direct Block #5 [9265]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
debugfs: quit # here we quit
此根文件系统的权限现在是正确的,我可以重新启动到之前损坏的系统。