/usr/bin/containerd: Operation not permitted

博客记录了Docker程序重启失败的问题,通过查看日志发现关键错误信息为Failed at step LIMITS和status=205/LIMITS。排查系统最大打开文件数等设置后,参考网友解答,修改docker.service和containerd.service相关配置项,重新加载systemd配置并重启Docker解决问题。

问题
今天在重启docker程序的时候一直启动不起来,通过systemctl status docker和jourctl -xu docker也没有发现什么有用的报错信息,无奈只好查看/var/log/message,发现以下错误提示:

Started containerd container runtime
Starting Docker Application Container Engine...
Failed at step LIMITS spawning /usr/bin/containerd: Operation not permitted
containerd.service: main process exited, code=exited, status=205/LIMITS
Unit containerd.service entered failed state.
containerd.service failed.

其中最为关键的信息是
Failed at step LIMITS和status=205/LIMITS,两个Limits信息

解决过程
看到有limits报错提示,本身的想到是不是系统ulimits和sysctl.conf里面的最大打开文件数是不是不够,查看以下信息:

ulimit -n
65535
sysctl -a|grep fs.nr_open
fs.nr_open = 65535

发现这两处都已经配置了,再查看一下当年已经打开的文件数

lsof -Ki|wc -l

发现打开的文件数也没有超过系统设置的上限
百度搜索网友的解答说是docker.service、containerd.service里面有一项配置不能超过系统的配置
1、修改 /usr/lib/systemd/system/docker.service

LimitNOFILE、 LimitNPROC、LimitCORE这三个选项的值都改成65535

LimitNOFILE=65535
LimitNPROC=65535
LimitCORE=65535

2、修改/usr/lib/systemd/system/containerd.service
将LimitNOFILE、 LimitNPROC、LimitCORE、TasksMax这三个选项的值都改成65535

LimitNOFILE=65535
LimitNPROC=65535
LimitCORE=65535
TasksMax=65535

然后重新加载systemd配置再重启docker就可以了

登录后复制 
systemctl daemon-reload
systemctl restart docker

 

### 解决方案 当遇到 `ossutil` 权限问题(Operation not permitted),通常是因为文件系统的权限设置不当或者挂载选项配置错误所致。以下是可能的原因分析以及对应的解决方法: #### 1. 文件系统权限不足 如果目标路径的权限不足以让当前用户执行操作,则可能会触发此错误。 - **验证权限** 使用以下命令检查目标目录的权限: ```bash ls -ld /path/to/mountpoint ``` - **调整权限** 如果发现权限不足,可以尝试修改目录权限: ```bash chmod 755 /path/to/mountpoint chown user:usergroup /path/to/mountpoint ``` 这里的 `user` 和 `usergroup` 是实际使用的用户名和组名[^1]。 #### 2. 挂载参数不正确 OSSFS 的挂载参数如果不正确也可能引发权限问题。例如,默认情况下某些挂载模式会限制非 root 用户的操作。 - **重新挂载并指定允许所有用户的选项** 添加 `-o allow_other` 参数来确保其他用户也可以访问该挂载点: ```bash ossfs bucket-name mount-point -o url=http://your-endpoint -o allow_other ``` - **启用更宽松的安全策略** 可以通过增加 `uid`, `gid` 或者 `mp_umask` 参数进一步控制权限分配: ```bash ossfs bucket-name mount-point -o uid=1000,gid=1000,umask=0022 ``` #### 3. FUSE 版本兼容性问题 FUSE 库的不同版本可能导致功能差异或冲突,从而影响权限管理逻辑。 - **检查已安装的 FUSE 版本** 执行如下命令获取当前系统中的 libfuse 版本号: ```bash ldd $(which ossfs) | grep fuse && ls -l /lib*/libfuse* ``` - **更新至最新稳定版** 若检测到旧版本库存在,请升级到支持更高性能与安全性的新版本: 对于基于 RPM 的发行版可运行 yum/apt-get 更新指令;对于源码编译环境则需下载官方发布包完成替换过程[^1]。 #### 4. SELinux/AppArmor 干扰 有时强制开启的安全模块也会阻止正常的数据读写行为。 - **临时禁用SELinux测试效果** 将 `/etc/selinux/config` 中的 `SELINUX=enforcing` 改成 permissive 后重启服务观察现象变化情况。 - **永久排除特定路径不受保护机制约束** 创建自定义规则文件如 `/etc/apparmor.d/local/usr.sbin.mysqld` ,加入类似下面的内容后再加载生效: ```plaintext /mnt/oss/** rwk, ``` --- ### 示例代码片段 以下是一个完整的脚本用于排查及修复常见的 OSSFS/OssUtil 权限相关问题: ```bash #!/bin/bash # Step A: Verify Mount Point Permissions MOUNT_POINT="/path/to/mount" if [[ ! -w "$MOUNT_POINT" ]]; then echo "Mount point is NOT writable by current user." sudo chmod u+w "$MOUNT_POINT" fi # Step B: Check LibFuse Version Compatibility LIB_FUSE=$(ldd "$(command -v ossfs)" | grep fuse || true) echo "Linked Fuse Library Info: $LIB_FUSE" # Optional C: Remount with Allow Other Option Enabled sudo umount "${MOUNT_POINT}" &>/dev/null; \ sudo mkdir -p "${MOUNT_POINT}"; \ sudo ossfs your-bucket-name "${MOUNT_POINT}" -o allow_other,url=https://endpoint & ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值