【linux】对/usr/目录 |
您所在的位置:网站首页 › linux怎么读文件夹 › 【linux】对/usr/目录 |
一、问题背景
在安装ansys的时候,脑子抽风,以为/usr/目录是共享目录,直接把所有文件或目录的权限完全设置为全用户自由读写和执行即可。 但是没想到执行了命令sudo chmod -R 777 /usr/命令之后,出现了一大堆sudo权限错误。 较为典型的几个错误如下: 1、/usr/bin/sudo must be owned by uid 0 and have the setuid bit set 2、sudo: error in /etc/sudo.conf, line 0 while loading plugin “sudoers_policy” 上面的错误表示 /usr/bin/sudo 文件的权限或所有者不正确。为了修复这个问题,需要将该文件的所有者更改为用户 ID 0(即 root 用户),并设置 setuid 位。 从恢复模式进入系统来解决这个问题。 首先用reboot命令重启系统。 在开机时,遇到主板相应的那个界面时,例如超微主板界面如下。如果你是Ubuntu系统,需要疯狂的按shift键。其他系统进入恢复模式的按键,你们可以去查查,一般来说就是esc或shift。 系统将进入恢复模式。 三、在恢复模式中执行以下命令在恢复菜单中,选择 “root - Drop to root shell prompt” 选项。
最后,执行exit命令退出命令模式。 选择resume normal boot,这样就能回到正常桌面中。
这样重启之后,就能正常显示桌面了。 四、解决error日志文件不断生成的问题参考:Ubuntu下error_log过大的终极解决方案 大概是因为仍然有些文件或目录的权限仍然不对,导致cups服务不断生成错误日志。足足占满了我的硬盘,我才发现!!! 通过tail命令查看错误日志文件的最后几行内容,发现几乎全部都是以下几句 cqu@cqu-X12DPi-N-T-6:/var/log/cups$ tail error_log E [xxxx] 目录“/usr/lib/cups/notifier”带有不安全的权限许可 (040777/uid=0/gid=0)。 W [xxxx] Notifier for subscription 62 (dbus://) went away, retrying! E [xxxx] 目录“/usr/lib/cups/notifier”带有不安全的权限许可 (040777/uid=0/gid=0)。 W [xxxx] Notifier for subscription 62 (dbus://) went away, retrying!随后,执行下面几条命令即可解决。 sudo chmod 755 /usr/lib/cups/notifier/dbus # 修改 这个路径的权限 sudo chown root.root /usr/lib/cups/notifier/dbus # 修改 dbus文件的归属用户,如果是文件夹最好加-R sudo rm /var/log/cups/error* # 删除 error 文件 sudo /etc/init.d/cups restart # 重启服务 tail error_log # 查看 error 文件,如果返回空,说明成功了这么设置之后,并没有解决。 4.2 谨慎修改/usr/bin文件夹的权限于是我借鉴了解决ubuntu中的cups目录下的error_log日志沾满磁盘空间的问题的建议,直接将/usr/lib目录全部权限改为755。 执行命令sudo chmod 755 -R /usr/lib。 之后,我发现又开始出现那个【/usr/bin/sudo must be owned by uid 0 and have the setuid bit set】的错误了。 痛定思痛,我不得不深入探究这个错误到底是啥意思。 首先上面我在恢复模式中为啥要执行chmod 4755 /usr/bin/sudo,而不是chmod 755 /usr/bin/sudo呢,因为4位数的权限模式的最高位表示特殊权限。 最高位为 4,表示该文件具有 set user ID (SUID) 权限。SUID 使程序在执行时具有文件所有者的权限,而不是执行程序的用户的权限。在这种情况下,sudo 将以 root 用户权限运行,因为 /usr/bin/sudo 文件通常由 root 用户拥有。 而在命令chmod 755 /usr/bin/sudo中,没有特殊权限,因此 sudo 将以执行程序的用户权限运行。 使用chmod 4755 时,sudo 将以 root 用户权限运行,而使用 chmod 755 时,sudo 将以执行程序的用户权限运行。通常,为了使 sudo 正常工作,需要设置 SUID 权限,因此一定要使用chmod 4755。 所以我又得去恢复模式执行一遍chmod 4755 /usr/bin/sudo。 4.3 对/var/文件夹的权限做一个默认设置因为上面两个步骤还没解决问题,所以不得不再继续尝试! 经过博主JensLee的开导——error_log塞满了70+G的错误日志。Notifier for subscription 94 (dbus://) went away, retrying!,我又执行命令sudo chmod 755 -R /var/,来修改目录/var/的权限为默认。当然,在修改权限前,还是要删除一下文件和重启CUPS服务的。 4.4 试试删除cups里的所有文件我上面三步都做了,还是没解决。 这次我怀疑是不是那个/var/log/cups/里的access*(以access开头的几个file)文件的问题,可能命令sudo chmod 755 -R /var/只能修改目录的权限,不能修改文件的权限吧。 于是乎我将这个cups的error文件全删了的同时,也把那几个access文件也删了,自然用的是sudo rm -rf xxx命令。 4.5 修改crash和log文件夹的权限因为上面四步执行之后,还是存在这个问题。但是奇怪的是,我用Ubuntu自带的disk usage analyzer分析时并没有呈现出任何大文件。 有一次因为磁盘占用满了,而我恰好在满了之后关机。结果导致开机的时候开不了机,最后无可奈何在tty模式下查看var目录下的信息。 无意中发现log目录和crash目录并不是755的目录默认权限。 于是就用命令chmod -R 755 xxx改成drwxr_xr_x的默认755权限。
我发现在/usr/bin/中存在一个sudoedit指针,指向的是sudo文件。 它的权限是777,当我怀疑这个指针文件有毛病后,就手贱用命令sudo chmod 755 sudoedit修改这个指针的权限。 无可奈何,原来的愚蠢的我不知道指针文件默认就是777权限,而且对指针文件进行权限更改时就会对源文件进行权限更改,所以最后执行上面命令之后,我又出现了文章开头提到的错误,需要再去恢复模式修改sudo文件的权限设定。 4.7 重读错误日志文件——修改notifier目录权限上面我也写出来过,这里我们再贴一次错误日志文件不断输出的内容。 cqu@cqu-X12DPi-N-T-6:/var/log/cups$ tail error_log E [xxx] 目录“/usr/lib/cups/notifier”带有不安全的权限许可 (040777/uid=0/gid=0)。 W [xxx] Notifier for subscription 62 (dbus://) went away, retrying!解读一下: 我们可以看到 CUPS(Common UNIX Printing System)错误日志中有两类消息:错误(E)和警告(W)。 错误消息(E):目录“/usr/lib/cups/notifier”带有不安全的权限许可 (040777/uid=0/gid=0)。 这条错误消息表明,/usr/lib/cups/notifier 目录的权限设置不安全。目录的权限为 040777,意味着所有用户都有读、写和执行权限(rwxrwxrwx)。这可能导致目录的安全风险。 我们通过命令ls -h来输出相关目录的权限信息。可以看到notifier的权限是777,并且里面也有几个文件权限也是777。 所以我们执行命令sudo chmod 755 /usr/lib/cups/notifier来修改回它的权限。 这将更改目录的权限为 rwxr-xr-x,只允许所有者(在此例中为 root 用户,uid=0 和 gid=0)读、写和执行,而其他用户只能读取和执行。 警告消息(W):Notifier for subscription 62 (dbus://) went away, retrying! 这条警告消息表示订阅 62 的通知器(在这种情况下是使用 D-Bus 通信的通知器)已断开连接。CUPS 将尝试重新连接。这不是一个严重的问题,可能只是一个暂时的网络连接问题或通知器进程意外终止。我们先把上面的错误解决了,说不定这个警报就没了。 如果还没解决,这个警告反复出现,可能需要进一步检查 D-Bus 通知器的设置和配置。 4.8 根据安装ssh服务器时弹出的警报重新设置权限执行完上面4.7的步骤后,那个error日志不断增长的问题终于解决了!!! 另外,在安装ssh服务器的时候,它警报我有些目录的权限还是太大,我又根据它的提示来修改了一些权限。 相信这样一步步地更改,就会恢复到很正常的权限设定了。 日子就是这样,慢慢过,总能过好。 RefCSDC博主“”上海一亩地“”写的文章【Linux系统目录下文件权限、所有者全部恢复】中,提到用相近机器的权限文件去恢复权限设定。 可能他的意思是我用上面的三条命令,还是没办法恢复至初始设定。 不过大家可以尝试一下下面两条命令(我没试过,这是AGI生成的,有效性存疑,谨慎尝试哦),第一条是给所有目录设置默认权限,第二条的修改对象是文件: sudo find /usr/ -type d -exec chmod 755 {} \; sudo find /usr/ -type f -exec chmod 644 {} \;既可以在恢复模式中执行,也可以在执行上面三条命令之后,进入正常模式的终端中执行。 如此执行之后,特定的目录或文件,可能需要特定的权限,你们根据自己需要进行自定义修改。 RESPECT!!! |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |