解决文件权限正确,但 systemd 服务仍然提示没有权限,启动失败。提示信息:service: Failed to execute command: Permission denied

本文解决了一个常见的系统管理问题,即在systemd下启动kubelet时遇到的Permission denied错误,尽管文件权限设置正确。错误源于SELinux的安全上下文不匹配,文章详细解释了原因并提供了解决方案。

现象

文件权限正确,但是通过 ·systemd· 启动时仍然报 Permission denied 错误。

文件权限:

[core@localhost ~]$ ll /usr/local/bin/
total 192512
-rwxrwxr-x. 1 core core  39813120 Jun  6 09:00 kubeadm
-rwxrwxr-x. 1 core core  44032000 Jun  6 09:00 kubectl
-rwxrwxr-x. 1 core core 113283800 Jun  6 09:00 kubelet

错误内容:

Jun 06 10:48:52 localhost systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jun 06 10:48:52 localhost systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Jun 06 10:48:52 localhost systemd[1]: kubelet.service: Failed with result 'exit-code'.
Jun 06 10:49:02 localhost systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 79.
Jun 06 10:49:02 localhost systemd[1]: Stopped kubelet: The Kubernetes Node Agent.
Jun 06 10:49:02 localhost systemd[13884]: kubelet.service: Failed to execute command: Permission denied
Jun 06 10:49:02 localhost systemd[13884]: kubelet.service: Failed at step EXEC spawning /usr/local/bin/kubelet: Permission denied

解决方案

这个依然是 SELinux 搞的鬼。

这是由于执行文件的 安全上下文 不正确导致的错误,我这边是因为可执行文件是先存放在用户主目录,然后移动到目标目录的。
但是将可执行文件从用户主目录移动到目标目录时它们的 SELinux 上下文不会自动变更,依然是用户主目录。所以出现了问题。

既然知道了原因,那么解决方案也有了,执行下面的命令即可解决。

sudo restorecon -rv /usr/local/bin/

其中 /usr/local/bin/ 时执行文件所在的目录,执行时需要替换成正确的目录。

启动 MongoDB 服务时遇到 `permission denied` 错误,通常是由于服务配置、文件权限或 SELinux/AppArmor 等安全机制限制所导致。以下是一些常见的排查与修复方法: ### 检查 MongoDB 数据目录和日志目录的权限 MongoDB 服务默认以 `mongod` 用户身份运行(在某些系统上可能为 `mongodb`)。因此,需要确保数据目录(如 `/var/lib/mongodb`)和日志目录(如 `/var/log/mongodb`)的拥有者为 `mongod` 用户。 ```bash sudo chown -R mongod:mongod /var/lib/mongodb sudo chown -R mongod:mongod /var/log/mongodb ``` 同时,确保这些目录的权限设置合理,通常为 `755` 或 `700`: ```bash sudo chmod -R 755 /var/lib/mongodb sudo chmod -R 755 /var/log/mongodb ``` ### 检查 MongoDB 服务文件权限 在某些 Linux 系统中,`/var/run/mongodb` 目录下的 `.pid` 文件或 socket 文件可能因权限问题无法被创建或访问。该目录通常由 systemd 服务启动时创建,并由 `mongod` 用户拥有。可以通过修改服务文件来指定正确的运行时目录权限: 编辑 MongoDB 的 systemd 服务文件(如 `/usr/lib/systemd/system/mongodb.service` 或 `/etc/systemd/system/mongodb.service`),确保包含以下内容: ```ini [Service] User=mongod Group=mongod RuntimeDirectory=mongodb RuntimeDirectoryMode=0755 ``` 保存后重新加载 systemd 并重启服务: ```bash sudo systemctl daemon-reexec sudo systemctl restart mongodb ``` ### 检查 SELinux 或 AppArmor 安全策略 如果系统启用了 SELinux 或 AppArmor,它们可能会阻止 MongoDB 访问特定目录或文件。可以临时禁用 SELinux 来测试是否与此有关: ```bash sudo setenforce 0 # 临时禁用 SELinux ``` 若问题消失,则需调整 SELinux 策略或永久禁用它(不推荐): ```bash sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config ``` 对于 AppArmor,可以禁用或调整其配置文件: ```bash sudo systemctl stop apparmor sudo systemctl disable apparmor ``` ### 检查 MongoDB 日志文件权限 如果 MongoDB 无法写入日志文件,也可能导致启动失败。确保日志文件路径(如 `/var/log/mongodb/mongod.log`)存在且权限正确: ```bash sudo touch /var/log/mongodb/mongod.log sudo chown mongod:mongod /var/log/mongodb/mongod.log sudo chmod 644 /var/log/mongodb/mongod.log ``` ### 检查 MongoDB 锁文件 如果 MongoDB 非正常关闭,可能会留下锁文件(如 `/var/lib/mongodb/mongod.lock`)。该文件阻止了服务再次启动。可以手动删除该文件并尝试重启服务: ```bash sudo rm /var/lib/mongodb/mongod.lock sudo systemctl start mongodb ``` ### 使用 `journalctl` 查看详细错误信息 若上述方法未能解决问题,可使用 `journalctl` 命令查看 MongoDB 服务的详细启动日志,以定位具体错误原因: ```bash sudo journalctl -u mongodb.service --since "1 hour ago" ``` ### 示例:修复 MongoDB 权限问题的完整脚本 ```bash #!/bin/bash # 设置 MongoDB 用户和目录 MONGO_USER="mongod" DATA_DIR="/var/lib/mongodb" LOG_DIR="/var/log/mongodb" RUN_DIR="/var/run/mongodb" # 修改目录权限 sudo chown -R $MONGO_USER:$MONGO_USER $DATA_DIR sudo chown -R $MONGO_USER:$MONGO_USER $LOG_DIR sudo mkdir -p $RUN_DIR sudo chown -R $MONGO_USER:$MONGO_USER $RUN_DIR sudo chmod -R 755 $DATA_DIR sudo chmod -R 755 $LOG_DIR sudo chmod -R 755 $RUN_DIR # 删除锁文件 sudo rm -f $DATA_DIR/mongod.lock # 重启 MongoDB 服务 sudo systemctl daemon-reload sudo systemctl restart mongodb ``` 通过上述方法,通常可以解决 MongoDB 服务启动时遇到的 `permission denied` 问题。若问题依旧存在,建议结合具体日志进一步排查。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值