failed to execute /bin/bash: Resource temporarily unavailable的问题处理

本文介绍了一种因FTP连接数过多导致登录失败的问题,并详细记录了排查过程及解决方案。通过调整系统配置文件,成功将连接数上限从1024提高到50000,恢复正常登录。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

[admin@localhost ~]$ sudo su - scloan
Last login: Tue Jun 12 14:06:31 CST 2018 on pts/3
su: failed to execute /bin/bash: Resource temporarily unavailable

提示资源不足,查看系统内存和磁盘空间使用情况,未发现明细异常
其他账号都可正常切换登录,只有kkloan(ftp账号)存在问题

查看其提供的ftp服务连接数情况
[kkloan@localhost ~]$ netstat -antlp|grep -v tcp6|grep 10.156.43.39:22|grep ESTABLISHED|wc -l
(No info could be read for "-p": geteuid()=1001 but you should be root.)
5074

由此可见连接数已达5074,而系统默认设置ulimit -a最大仅为1024

解决如下:

[admin@localhost ~]$ egrep -v "^$|^#" /etc/security/limits.d/20-nproc.conf
* soft nproc 1024
root soft nproc unlimited


vim /etc/security/limits.d/20-nproc.conf
* soft nproc 50000 #将默认值1024改为50000
root soft nproc unlimited

再次ssh登录账户,ok,回复正常。


注:单独修改/etc/security/limits.conf 未可用!

转载于:https://www.cnblogs.com/hsia2017/p/9173543.html

<think>好的,我现在需要帮助用户解决在root用户下执行/bin/bash时出现“Permission denied”的问题。首先,我需要回忆一下相关的系统权限知识以及之前处理类似问题的经验。 根据用户提供的引用内容,比如引用[3]中提到,root用户切换到普通用户时遇到了同样的问题,通过修改/usr/sbin和/usr/lib64的权限解决了问题。这可能意味着/bin/bash或其依赖的目录权限有问题。 首先,我应该检查/bin/bash文件的权限是否正确。正常情况下,root用户应该对/bin/bash有执行权限。如果权限被错误地修改过,比如去除了执行权限,那么root用户也无法执行。所以,第一步是检查/bin/bash的权限,使用ls -l /bin/bash命令查看,权限应该是-rwxr-xr-x。如果发现权限不对,需要用chmod +x /bin/bash修复。 接下来,考虑可能的SELinux或AppArmor安全模块的问题。这些安全工具可能会限制进程的执行。用户可以使用getenforce命令查看SELinux的状态,如果是Enforcing模式,可以尝试暂时关闭SELinux(setenforce 0)来测试是否是这个问题导致的。如果是,就需要调整策略或添加规则。 另外,引用[2]中提到了修改/etc/sudoers文件来允许普通用户获得权限,但这里用户是root本身,所以这可能不适用。不过,可能需要检查sudoers文件是否有异常配置,或者是否有其他安全策略限制了root的执行权限。 还有可能是文件系统挂载选项的问题。如果/bin所在的文件系统被挂载为noexec,那么任何用户都无法执行其中的文件。检查/etc/fstab中的挂载选项,确保没有noexec标志。如果有,需要重新挂载并修改选项。 此外,检查/bin/bash的完整性也很重要,比如是否被损坏或替换。可以通过rpm -Vf /bin/bash(对于RPM系统)或dpkg -S /bin/bash(对于Debian系统)来验证文件是否被修改过。 最后,如果所有步骤都检查过但问题依旧,可能需要查看系统日志(如/var/log/messages或journalctl)寻找更详细的错误信息,帮助进一步诊断。 总结可能的解决步骤:检查/bin/bash权限,检查SELinux/AppArmor,检查文件系统挂载选项,验证bash文件完整性,检查系统日志。需要逐步排查这些可能性,找到具体原因并对应解决。</think>### 解决root用户执行/bin/bash时出现"Permission denied"的步骤 #### 1. 检查/bin/bash文件权限 **操作命令**: ```bash ls -l /bin/bash ``` - **正常权限应为**:`-rwxr-xr-x`(权限值755) - **若权限异常**,使用以下命令修复: ```bash chmod 755 /bin/bash ``` 若文件权限被错误配置为不可执行(例如缺少`x`标志),会导致所有用户无法执行该文件[^3]。 --- #### 2. 验证SELinux安全模块状态 **步骤**: 1. 查看SELinux当前模式: ```bash getenforce ``` 2. **若结果为`Enforcing`**,临时关闭SELinux测试: ```bash setenforce 0 ``` 3. 再次尝试执行`su - <用户名>`或`/bin/bash`,若问题解决,需调整SELinux策略: ```bash restorecon -v /bin/bash # 恢复文件安全上下文 ``` 或永久关闭SELinux(需谨慎): ```bash sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config ``` --- #### 3. 检查文件系统挂载选项 **操作**: 1. 查看`/bin`目录所在分区的挂载选项: ```bash mount | grep "/bin" ``` 2. **若挂载参数包含`noexec`**(禁止执行),需修改`/etc/fstab`文件: - 找到对应分区的行,移除`noexec`选项 - 重新挂载分区: ```bash mount -o remount,exec /bin ``` --- #### 4. 验证/bin/bash文件完整性 **适用系统**: - **RPM系(CentOS/RHEL)**: ```bash rpm -Vf /bin/bash ``` - **Debian/Ubuntu**: ```bash dpkg -S /bin/bash && debsums -s /bin/bash ``` 若输出显示文件被篡改,需重新安装bash: ```bash yum reinstall bash # CentOS/RHEL apt install --reinstall bash # Debian/Ubuntu ``` --- #### 5. 检查依赖库目录权限(较少见) **操作**: ```bash chmod go+x /usr/sbin /usr/lib64 # 参考引用[3] ``` 某些情况下,bash依赖的动态库路径(如`/usr/lib64`)或系统工具路径(如`/usr/sbin`)权限错误可能导致间接权限问题[^3]。 --- #### 6. 查看系统日志定位问题 **命令**: ```bash journalctl -xe | grep "bash" # systemd系统 tail -50 /var/log/messages # 非systemd系统 ``` 日志可能包含更具体的错误原因(如安全策略拦截记录)。 --- ### 最终验证 修复后尝试切换用户: ```bash su - <目标用户名> ``` 或直接执行: ```bash /bin/bash -c "echo test" ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值