On Mac Os-X linux shell I can create a script “atest” which might have one line:
echo “this test is ok”
if I now execute it like this
./atest
it works perfectly and writes to stdout:
this test is ok
but if I try the same on ORIN AGX, Ubuntu 20.04
./atest returns “Permission Denied”
This is a serious problem where I have an executable that is called from another script (which I can’t access) such as in building from source…
Any idea? (please try)
@hg1 does it have executable permissions? Try chmod +x atest
This is a standard Linux thing… if it’s a bash script, the first line should be#!/usr/bin/env bash
Yes, of course I tried it. It has executable permission even with chmod 777 it won’t work, and neither using shabang. Is it working for you when you test it? @dusty_nv
Yes, this works for me:
echo '#!/usr/bin/env bash' >> atest
echo 'echo "this test is ok"' >> atest
chmod +x atest
./atest
this test is ok
Are you using an ext3/ext4 partition?
Hi @dusty_nv
following line by line your exact process, it worked on normal shell (ext4) on Orin AGX, but not in a docker container from NGC. (Even I’m executing atest from /bin/bash shell)
@dusty_nv I thought it had something to do with running out of space in the docker container, but I tested it (‘docker cp’ worked after I freed some space) and that wasn’t the case. in my case, what I narrowed down so far,
bash atest works
bash ./atest works
./atest seems to work on the local disk (such as /tmp) but not on the external disk where docker is
so I worked around this for now by moving the executing script to the local disk
Create a file in the same manner which fails, but add only this command after the shebang:
which bash
Also, on command line (not in the script), run:
ls -l `which bash`
(compare to the shebang)
It seems likely that the docker environment is lacking access to something. Sometimes the shell itself is incorrect as there will sometimes be two versions of bash: One for restricted access used by system accounts, and another used by normal end users. Along with that there may be things linked in which also change. The behavior of a script can depend on the name used for accessing the script, e.g., there is an argument presented to the program which would respond differently if the program is accessed directly, versus if the program is accessed through a symbolic link alias. That difference might be in some function called and not the bash script itself.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.