The issue (if it isn't obvious) is that the user you are running the command as does not have the permissions to execute it. As @CharlesDuffy noted in the comment's:
If it's just direct output from curl -o
, there won't be any x
bits at all, so I'd expect rw-r--r--
or rw-rw-r--
, depending on the active umask
What do the permissions look like for the executable? You can find that by running:
ls -l /usr/local/bin/calicoctl
The results of the above command will output something similar to:
-rw-r--r-- 1 root root 1680446 Jul 16 11:56 /usr/local/bin/calicoctl
Where the rw-r--r--
portion refers to the allowed permissions of the Owner, Group, and World/Global respectively in three letter chunks. You can read more about how permissions work here.
I have a feeling you're results look similar to rw-r--r--
which would mean no one has the ability to execute. It's common that all binary located in /usr/local/bin
are owned by root
, are in the root
group, and have permissions set to either rwxrwxrwx
(where everyone can Read/Write/Execute) or rwxr-xr-x
(where the Owner can Read/Write/Execute but Group members and Global can only Read/Execute.)
To can try to adjust you're permissions to rwxrwxr-x
with
sudo chmod 775 /usr/local/bin/calicoctl
and see if that works. chmod
is the tool used to change permissions. Again, see this link for more info on permissions in Ubuntu/GNU+Linux.
For reference, here is a numeric breakdown of user permissions:
7 - full (rwx)
6 - read and write (rw-)
5 - read and execute (r-x)
4 - read only (r--)
3 - write and execute (-wx)
2 - write only (-w-)
1 - execute only (--x)
0 - none (---)
You can also probably just run your initial command with sudo
but that's not a solution, just a workaround