2

I am trying to run a back script that I wrote that I have placed in the /srv directory on my xubuntu machine.

But when I try to run it, it errors with the following...

user@linuxbox:/srv$ sudo ./backup.sh 
sudo: unable to execute ./backup.sh: No such file or directory

The contents of my backup.sh script are as follows...

#!/bin/sh
rsync --update -raz --progress ./git  '/media/user/New Volume/BACKUP'

EDIT: I did flip the executable bit using chmod.

Here is the permissions...

-rwxr-xr-x 1 root root 81 Mar 18 17:16 /srv/backup.sh

EDIT: Apparently another running instance of nano is editing my file. But I did a restart of the PC, so not sure how that persisted. Could this be the problem? This happens when I try to edit in nano.

File backup.sh is being edited (by root with nano 2.5.3, PID 14039); continue?

When I try to kill that process by the PID, it says "No such process"

Scorb
  • 604
  • 3
  • 12
  • 25
  • 1
    Executable bit is missing. – phk Mar 18 '17 at 23:08
  • 1
    ...and that there are no non-printable characters in the filename? Trailing space, maybe? – Jeff Schaller Mar 18 '17 at 23:11
  • Please show us the output of `ls -l /srv/backup.sh` (just so we can have it right the in the question and confirm the obvious: that the file is there and executable). – terdon Mar 18 '17 at 23:27
  • 2
    Also `ls -l /bin/sh` – Jeff Schaller Mar 19 '17 at 01:07
  • 3
    `head -n 1 backup.sh|od -t x1` and look for `0d` – Michael Homer Mar 19 '17 at 04:41
  • You’re not getting any good answers because, from what you’re saying, you’re doing everything right. The results you’re describing don’t make sense. So I’m throwing out a random lifeline in the hope of getting some information that might shed some light on this: Try running your script, both with **`./`** and with a full path, *both with and without*  `sudo`, and post the results. Please do not respond in comments; [edit] your question to include all relevant information.  (P.S. The fact that nano believes that another running instance of it is editing the file should not make any difference.) – G-Man Says 'Reinstate Monica' Mar 20 '17 at 01:45
  • 1
    And, if that doesn’t resolve it, do `cat -A backup.sh`.  (The first two or three lines of output should be enough to clarify some issues.) – G-Man Says 'Reinstate Monica' Mar 20 '17 at 01:46
  • 2
    @G-Man "No such file or directory" when running scripts on UNIX is typical for scripts with Windows newlines. FWIW. – Satō Katsura Mar 20 '17 at 08:54
  • 1
    missing executable bit should give "Permission denied" instead of "No such file or directory" – ilkkachu Mar 20 '17 at 12:18
  • @SatoKatsura: Well, depending on what shell you're running. Bash manages to give better diagnostics. – G-Man Says 'Reinstate Monica' Mar 20 '17 at 23:42
  • `sudo` doesn't use a shell. – Michael Homer Mar 21 '17 at 00:53
  • @MichaelHomer `sudo` indeed doesn't use a shell. Actually running the script does though. – Satō Katsura Mar 21 '17 at 06:47
  • @G-Man It isn't the shell that complains, it's the kernel. Namely, it parses the shebang line, and tries to run `bash\r`. – Satō Katsura Mar 21 '17 at 06:50
  • @SatoKatsura: As I said, it depends.  Running bash 4.1 and 4.3, if I create `foo` with `#!/bar/gain`, do `chmod +x foo`, and run `./foo`, I get `bash: ./foo: /bar/gain: bad interpreter`.  Frankly, I’m not sure how it does that, inasmuch as I believe that I understand how shebangs work, and bash *should* just be getting `ENOENT` for `./foo`, and it shouldn’t even see the `/bar/gain`, and yet somehow it does.  Sorry, but I don’t feel like running `strace` on it right now. – G-Man Says 'Reinstate Monica' Mar 21 '17 at 15:44
  • @G-Man Hmm. It looks like `bash` tries to optimize running scripts and parses the shebang line itself. – Satō Katsura Mar 21 '17 at 18:22
  • 1
    Meanwhile, we’re still waiting for the OP to provide results from `od` and/or `cat -A`.  I give up; I’m voting to close. – G-Man Says 'Reinstate Monica' Mar 21 '17 at 18:30
  • FYI: This is almost always a case of an extra carriage return (CR) getting in the file, or it being in Windows/DOS CRLF format instead of Unix linefeed (LF)-only format. See http://unix.stackexchange.com/questions/27054/bin-bash-no-such-file-or-directory – derobert Mar 22 '17 at 16:54

1 Answers1

0

The first thing I would do is use the full path instead of relative, and check to make sure you have "execute" bit set. If you can't do an ls /srv/backup.sh then you know it's a name/path issue. Likewise if no execute bit set, even root will not be able to execute it.

i.e. sudo /srv/backup.sh

Sending_Grounds
  • 63
  • 7
  • when I did ls command it listed backup.sh in green. Does that mean the execute bit is set correctly? – Scorb Mar 19 '17 at 01:35
  • Per Jeff and Terdon's request, to verify do a long listing `ls -l /srv/backup.sh` so we can see the full permissions. If you don't see an "x" listed in the permissions then that would be a no. – Sending_Grounds Mar 19 '17 at 01:40
  • I updated with new info. – Scorb Mar 19 '17 at 01:42