Can't copy file to /usr/bin, even when logged in as root
Trying to follow the instructions here:
https://github.com/SmingHub/Sming/wiki/MacOS-Quickstart
And even as the root user I can't seem to be able to write to /usr/bin:
sh-3.2# whoami
root
sh-3.2# ls -alF build/spiffy
-rwxr-xr-x+ 1 admin staff 97780 Oct 23 07:51 build/spiffy*
sh-3.2# cp build/spiffy /usr/bin
cp: /usr/bin/spiffy: Operation not permitted
Any ideas about how I could get around this?
Comments
Try typing:
sudo cp build/spiffy /usr/bin
and enter the password after hitting return or try typing:
open /usr/bin
then drag the file over and the Finder will popup a dialog to put the password in. Being logged in as root should work though.
Try typing:
sudo cp build/spiffy /usr/bin
and enter the password after hitting return or try typing:
open /usr/bin
then drag the file over and the Finder will popup a dialog to put the password in. Being logged in as root should work though.
With the sudo command I get "Operation not permitted", and when I drag the file over it refuses (with a big circle with a slash through it).
With /usr/bin open in the Finder, when you open the 'get info' box, what does the sharing and permissions box say? Also, in system prefs > security > general, do you have the system set to something other than allow applications from anywhere? I'm not sure if that locks down certain folders but it makes sense that it would.
If you are on El Capitan, they were supposed to be locking down some system locations so that might be what's blocking the install:
https://en.wikipedia.org/wiki/System_Integrity_Protection
The spiffy binary might not need to be moved to /usr/bin. You can put binaries anywhere and modify your bash preferences to allow them to be executed in the terminal. You can create a bash profile if you don't have one in the home folder called .bash_profile.
If it already exists, just type:
open ~/.bash_profile
if not, type:
touch ~/.bash_profile and then open it.
You'd then put the spiffy binary somewhere e.g /Applications/spiffy/spiffy. If you make a folder it will let you put multiple versions in it without updating the path. Then inside the bash profile, you'd write:
export PATH=/Applications/spiffy:$PATH
save the file and open a new terminal window. The spiffy command should be able to be run directly in the terminal. If you make a new version and want to keep two versions, you just put both binaries in the same folder and they will be accessible in the terminal.
Yeah - I think that the /usr/bin directory is only writable by "system". I ended up putting it in /usr/local/bin instead. Thanks!
Yeah - I think that the /usr/bin directory is only writable by "system". I ended up putting it in /usr/local/bin instead. Thanks!
You would have to set permissions. If you log into an account with administrative permission on OSX, you should be able to use sudo after entering your password. I don't think you need to configure sudoers on OSX. So sudo may not grant you permissions to write to a write protect directory, but it will allow you to run chmod. Alternatively just go to that folder in your finder. Click get info. Click the lock symbol to make changes. Enter your password. Restore the permissions to their previous state once you finish.
El Capitan has a suck permissions list now. Only users on the list can use sudo. "man sudo" should explain.
@original poster, /usr/local/bin is a more appropriate place to put binaries you've downloaded. "Local" implies your local machine, or your local customization. "/usr/bin" really should only be what comes with OSX. These are conventions not enforced by anything, however permissions are guiding you to follow the convention.
In the original post when you did the 'whoami', did you do a su - root. In some instances an su is insufficient to do certain actions albeit the last time I hit this issue was setting up a netinfo server and hit some nicl quirk years ago.
As Marvin and others have pointed out just put the file in another directory and add that to your $PATH.
El Capitan has a suck permissions list now. Only users on the list can use sudo. "man sudo" should explain.
Linux has always used a specific sudoers file, so it's not surprising. I haven't installed El Capitan yet, so I was unaware of that.