-1

Please actually read my post instead of just the title. This is a larger system issue, not a typo or a file permissions issue.

I am attempting to run my script without having to type in 'python3' before every test run, and potentially to make scheduling a cron job easier. No matter what I've tried, I always get the error -bash: ./main.py: Permission denied. I've tried the following:

  • Using every version of python in /usr/bin/ with or without a space after '#!'
  • Using every version of python with /usr/bin/env [python version].
  • Running chmod 777 on every python file in /usr/bin
  • Running chmod 777 on every file and folder in my script directory.
  • The user running the script is in both the root and wheel groups.
  • Running the script as root gives the same results.
  • Adding the shebang to every python file in my script directory.

I'm at a loss here. Every other post I've seen about this is just saying to do chmod +x, which doesn't apply in my case.

Edit 1: I've now tried reinstalling both bash and python, as well as running dos2unix on all of my script files to make sure the EOL characters weren't the problem. No luck.

Binsky734
  • 11
  • 5
  • 1
    Does `/usr/bin/python3 main.py` work on the script without any modifications? Posting an example script and your invocation of it would also be helpful. – tjm3772 Jul 03 '23 at 19:39
  • Have you run `chmod +x main.py` ? What is the output of `ls -l main.py` ? – pjh Jul 03 '23 at 20:23
  • @tjm3772 Running `/usr/bin/python3 main.py` does work, but I'm also unable to run the bash script I wrote for cron which is just the previous command but with the absolute path for main.py (copied and pasted from `pwd` to avoid typos) – Binsky734 Jul 03 '23 at 22:18
  • 1
    You did not post the shebang line of your script (do a `head -n 1 SCRIPT`). You should also show us the exact way how you call your script, and the output of `stat SCRIPTNAME` or `ls -l SCRIPT`. – user1934428 Jul 04 '23 at 05:58
  • @user1934428 I did provide that information in my post. I tried every permutation of the shebang line, so I didn't think it was necessary to post all 25. But, you asked for them, so here you go: `#!/usr/bin/python`, `#! /usr/bin/python`, `#!/usr/bin/env python`, `#! /usr/bin/env python`, `#!/usr/bin/python2`, `#! /usr/bin/python2`, `#!/usr/bin/env python2`, `#! /usr/bin/env python2`, `#!/usr/bin/python2.7`, `#! /usr/bin/python2.7`, `#!/usr/bin/env python2.7`, `#! /usr/bin/env python2.7`, `#!/usr/bin/python3`, `#! /usr/bin/python3`, `#!/usr/bin/env python3`, -continued- – Binsky734 Jul 05 '23 at 15:19
  • -continued- `#! /usr/bin/env python3`, `#!/usr/bin/python3.6`, `#! /usr/bin/python3.6`, `#!/usr/bin/env python3.6`, `#! /usr/bin/env python3.6`, `#!/usr/bin/python3.6m`, `#! /usr/bin/python3.6m`, `#!/usr/bin/env python3.6m`, `#! /usr/bin/env python3.6m` – Binsky734 Jul 05 '23 at 15:19
  • BTW, running `chmod 777` on _anything_ in `/usr/bin` is an incredibly bad idea -- it lets any malware in any user account on the system (including accounts like `nobody`, which is frequently used to sandbox code handling unauthenticated network connections) rewrite critical executables. You should consider your computer compromised and reinstall the OS. – Charles Duffy Jul 05 '23 at 15:51
  • That said, what directory is your `main.py` in, and what are the mount flags on the filesystem? If there's a `noexec` flag set at the filesystem level, then `chmod +x` is ignored. – Charles Duffy Jul 05 '23 at 15:51
  • (In general, it's a good idea to look at your system's security precautions before you start trashing it and them; if there's not a `noexec` flag, the next place to start investigating is things like SELinux). – Charles Duffy Jul 05 '23 at 15:52
  • (You might also, say, copy `/usr/bin/ls` into the same directory as the `main.py` and see if you can run `./ls` _when it's in that directory_; if you can't, that tells us a lot about what's going on). – Charles Duffy Jul 05 '23 at 15:56
  • (And in the future, consider [unix.se] for questions that are more about system administration than software development; the problem is with the security settings on your system not letting the program be run, not with anything about how the program is written -- and only the latter subject is topical here). – Charles Duffy Jul 05 '23 at 15:56
  • (if you _can_ run `./ls` or another known-good executable copied there when in the directory but still can't run your script, that puts us more in the direction of xacls, xattrs, SELinux security labels, etc). – Charles Duffy Jul 05 '23 at 16:03
  • ...I see you're back online, but it still looks like you haven't checked the mount flags. I didn't tell you to reinstall anything (except for security reasons, unrelated to fixing the immediate problem and rather on avoiding potential side effects caused by thrashing around at the issue). I didn't tell you to run dos2unix on anything. I **did** tell you to check for the `noexec` flag in `/proc/mounts`, and various other items besides. – Charles Duffy Jul 05 '23 at 21:27
  • (BTW, `chmod 777 /usr/bin/*` does other damage besides just making executables writable by otherwise-unprivileged malware; it also, for example, clears setuid and setgid bits, so it can break tools like `sudo` and `su`). – Charles Duffy Jul 05 '23 at 21:30
  • If this is from `cron`, I don't see then where _bash_ comes into play, unless you have a `SHELL=/usr/bin/bash` in your crontab (do you?). Could you paste - for the safe side - the relevant part of the crontab as well? – user1934428 Jul 06 '23 at 05:24
  • Also, make sure the user cron is running your scripts with has `+x` permission on the parent directories to where those scripts are located. (Or better, moot that issue by installing them in `/usr/local/bin`, which will _also_ avoid any `noexec`-related problems) – Charles Duffy Jul 06 '23 at 15:36
  • 1
    @CharlesDuffy I was just throwing up a quick edit, but I was dealing with another issue yesterday that took priority over this project. I ended up doing something that broke SSH and Session Manager on the original server, but the new one I spun up does the same thing. I checked, and you were right. The home directory is mounted with the noexec flag, so I just need to stick it in /usr/local or something. – Binsky734 Jul 06 '23 at 17:29
  • Good deal. If that (and SELinux security labels, and +x/traversal permissions on parent directories) hadn't been the problem we might have needed to get into obscurer things like whether your cron daemon was being run with a private mount table or such, and I might have doubled down on the take-it-to-[unix.se] position. – Charles Duffy Jul 06 '23 at 17:32
  • BTW, think about moving away from cron jobs these days -- the modern replacement is systemd timers; you have a lot more control over the execution environment that way and can completely eliminate any shell use from the invocation process. – Charles Duffy Jul 06 '23 at 17:35

1 Answers1

0

The problem ended up being that the directory the scripts were in had the noexec flag set.

Binsky734
  • 11
  • 5