sudo: no se puede ejecutar ./script.sh: no existe tal archivo o directorio

Estoy perplejo. Tengo un script en mi /homedirectorio que es ejecutable:

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

Sin embargo, cuando intento ejecutarlo sudo, dice que no puede encontrarlo:

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

Esto está en una nueva construcción. No se han realizado cambios que puedan causar problemas. De hecho, el objetivo de la secuencia de comandos es garantizar que se construya realmente de acuerdo con nuestras políticas. ¿Quizás tal vez no lo está y en sudorealidad se está rompiendo durante la construcción?

También debo tener en cuenta que puedo ejecutar sudocon otros comandos en otros directorios.

EDITAR: El guión (no lo escribí, así que no /bin/bashme olvide, por favor;))

#! /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

Esto generalmente ocurre cuando la línea shebang ( #!) en su script está rota.

El shebang es lo que le dice al núcleo que el archivo debe ejecutarse utilizando un intérprete. Cuando se ejecuta sin sudo, el mensaje es un poco más significativo. Pero con sudousted recibe el mensaje que recibió.

Por ejemplo:

$ 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

El bad interpretermensaje indica claramente que es el shebang el que está defectuoso.

Acabo de tener este problema exacto, resultó ser un problema de codificación de archivos de texto. Para solucionarlo mientras ejecutaba Xubuntu 14.04.3 LTS, instalé dos2unix y convertí la codificación del script y luego ejecuté el script nuevamente usando sudo y funcionó bien. Puede encontrar un ejemplo a continuación:

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