sudo: impossible d'exécuter ./script.sh: aucun fichier ou répertoire de ce type

Je suis perplexe. J'ai un script dans mon /homerépertoire qui est exécutable:

[user@server ~]$ ll
total 4
-rwx------ 1 user user 2608 Jul 15 18:23 qa.sh

Cependant, lorsque j'essaie de l'exécuter avec, sudoil dit qu'il ne le trouve pas:

[user@server ~]$ sudo ./qa.sh 
[sudo] password for user: 
sudo: unable to execute ./qa.sh: No such file or directory

C'est sur une nouvelle construction. Aucune modification n'a été apportée, ce qui entraînerait des problèmes. En fait, le but du script est de s'assurer qu'il est réellement construit selon nos politiques. Peut-être que ce n'est pas le cas et sudoest en fait cassé pendant la construction?

Je dois également noter que je peux exécuter sudod'autres commandes dans d'autres répertoires.

EDIT: Le script (je ne l'ai pas écrit, alors ne /bin/bashme faites pas dessus, s'il vous plaît;))

#! /bin/bash

. /root/.bash_profile

customer=$1

if [ -z "$customer" ]; then

        echo "Customer not provided. Exiting..."
        exit 1

fi

space ()
{
echo
echo '###########################################################################'
echo '###########################################################################'
echo '###########################################################################'
echo
}

g=/bin/egrep

$g ^Listen /etc/ssh/sshd_config
$g ^PermitR /etc/ssh/sshd_config
$g ^LogL /etc/ssh/sshd_config
$g ^PubkeyA /etc/ssh/sshd_config
$g ^HostbasedA /etc/ssh/sshd_config
$g ^IgnoreR /etc/ssh/sshd_config
$g ^PermitE /etc/ssh/sshd_config
$g ^ClientA /etc/ssh/sshd_config

space

$g 'snyder|rsch|bream|shud|mweb|dam|kng|cdu|dpr|aro|pvya' /etc/passwd ; echo ; echo ; $g 'snyder|rsch|bream|shud|mweb|dam|kng|cdu|dpr|aro|pvya' /etc/shadow

space

$g 'dsu|scan' /etc/passwd ; echo ; echo ; $g 'dsu|scan' /etc/shadow

space

$g ${customer}admin /etc/passwd

space

chage -l ${customer}admin

space

$g 'urs|cust|dsu' /etc/sudoers

space

$g dsu /etc/security/access.conf

space

$g account /etc/pam.d/login

space

/sbin/ifconfig -a | $g addr | $g -v inet6

space

echo "10.153.156.0|10.153.174.160|10.120.80.0|10.152.80.0|10.153.193.0|172.18.1.0|10.153.173.0"
echo
$g '10.153.156.0|10.153.174.160|10.120.80.0|10.152.80.0|10.153.193.0|172.18.1.0|10.153.173.0' /etc/sysconfig/network-scripts/route-eth1

space

cat /etc/sysconfig/network-scripts/route-eth2

space

netstat -rn | tail -1

space

cat /etc/sysconfig/iptables

space

cat /etc/hosts

space

##file /usr/local/groundwork ; echo ; echo ; /sbin/service gdma status

##space

cat /etc/resolv.conf

space

HOSTNAME=`echo $HOSTNAME | awk -F. '{ print $1 }'`

nslookup ${HOSTNAME}

echo
echo

nslookup ${HOSTNAME}-mgt

echo
echo

nslookup ${HOSTNAME}-bkp

space

/sbin/service rhnsd status ; echo ; echo ; /sbin/chkconfig --list rhnsd ; echo ; echo ; yum update --security

space

/sbin/service osad status ; echo ; echo ; /sbin/chkconfig --list osad

space

/sbin/service sshd status ; echo ; echo ; /sbin/chkconfig --list sshd

space

/sbin/service snmpd status ; echo ; echo ; /sbin/chkconfig --list snmpd ; echo ; echo ; echo ; cat /etc/snmp/snmpd.conf

space

df -h

space

cat /proc/cpuinfo | $g ^processor

space

free -g

space

if [ -f /etc/rsyslog.conf ]; then

        tail -3 /etc/rsyslog.conf

else

        echo "This system is not running rsyslog."

fi

rm -f $0

Cela se produit généralement lorsque la ligne shebang ( #!) de votre script est rompue.

Le shebang est ce qui indique au noyau que le fichier doit être exécuté à l'aide d'un interpréteur. Lorsqu'il est exécuté sans sudo, le message est un peu plus significatif. Mais avec sudovous obtenez le message que vous avez reçu.

Par exemple:

$ cat test.sh
#!/bin/foo
echo bar

$ ./test.sh
bash: ./test.sh: /bin/foo: bad interpreter: No such file or directory

$ bash test.sh
bar

$ sudo ./test.sh
sudo: unable to execute ./test.sh: No such file or directory

$ sudo bash ./test.sh
bar

Le bad interpretermessage indique clairement que c'est le shebang qui est défectueux.

Je viens d'avoir ce problème exact, il s'est avéré être un problème d'encodage de fichier texte. Pour que je le corrige lors de l'exécution de Xubuntu 14.04.3 LTS, j'ai installé dos2unix et converti l'encodage du script, puis exécuté à nouveau le script à l'aide de sudo et cela a bien fonctionné. Vous pouvez trouver un exemple ci-dessous:

sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh && sudo ./test.sh