I'm creating a .sh bash script in Ubuntu 18.04.1 LTS where I need to create a new user using the "adduser" command:
sudo adduser newuser
After that, I need to perfomr other operations like add some files in the newuser's Desktop or Documents folders. The main problem is that, untill I don't reboot the system, the newuser haven't that folders so I need to create them manually
sudo mkdir -p /home/newuser/Desktop
sudo mkdir -p /home/newuser/Documents
sudo mkdir -p /home/newuser/.local/share/applications
I really don't like this solution. Is there a way to initialize that folders after a user creation?
Thanks
You can try using xdg-user-dirs-update tool which generates all required user directories in the $HOME path.
Don't forget to do su newuser first.
I launch an centos AMI I created, and try to add user data as a file which looks like this:
#!/bin/bash
mkdir /home/centos/testing
cd testing
wget https://validlink
So simply, on launch, the user data creates a folder called testing and downloads this validURL which I will not put as it links to my data - however it is valid and accessible.
When I launch the instance, the folder testing is created successfully, however there is no file inside the directory.
When I ssh into the instance, and run the wget command as a sudo, the file is downloaded successfully inside the testing folder.
Why does the file not get downloaded on the ec2 launch through user data?
You have no way of knowing the current working directory when you execute the cd command. So specify full path:
cd /home/centos/testing
Try this:
#!/bin/bash
mkdir /home/centos/testing
cd /home/centos/testing
wget https://validlink
Run it using the root user.
Try this instead:
#!/bin/bash
sudo su
yum -y install wget
mkdir /home/centos/testing
cd /home/centos/testing
wget https://validlink
I have a Mac that is shared between two engineers. Both have separate user accounts. Both need to run brew update and brew install... occasionally.
How do I set this up without getting errors like:
/usr/local must be writable!?
Yeah, I could have UserA take over the permissions of /usr/local every time he wants to use brew (and same with UserB), but that seems like a lot of unnecessary trouble.
You can also change the group permissions to admin or another group that both of your users are in:
chgrp -R admin /usr/local
chmod -R g+w /usr/local
Original source: https://gist.github.com/jaibeee/9a4ea6aa9d428bc77925
UPDATE:
In macOS High Sierra you can't change the owner, group or permissions of /usr/local. So you have to change the group and permissions of the subfolders:
chgrp -R admin /usr/local/*
chmod -R g+w /usr/local/*
UPDATE September 2018, High Sierra 10.13.6
Determine the path of the brew prefix, ie. the path that will be used to store files related to working with homebrew
Check that all users on the system who need access to brew are in the admin group
Optional Add a user to the admin group if a user needs access to brew
Will require access / privileges to use the sudo command
Set the brew prefix path to be recursively owned by the admin group
Set the brew prefix path to be recursively writable by all users who are in the admin group
Verify the permissions of the brew prefix
brew 🍻
echo $(brew --prefix)
echo $(groups $(whoami))
sudo dseditgroup -o edit -a $(whoami) -t user admin
sudo chgrp -R admin $(brew --prefix)
sudo chmod -R g+rwX $(brew --prefix)
ls -lah $(brew --prefix)
Every answer that tries to hack permissions, or use sudo is wrong.
Do not use sudo and do not share a single brew installation across user accounts.
The correct answer per the Homebrew docs is to use zero or one global brew installation on a machine, and for all other users install a local version of brew.
This is especially important on Mac, but works on Linux too.
This can be done by one of the following approaches
Git approach: doing a git checkout of the source repo
Untar-anywhere approach: expanding a tarball into some directory – owned by your user
Git approach
For the git approach you'll need to clone brew.
Arbitrarily choosing my user home directory for my checkout:
cd $HOME
git clone https://github.com/Homebrew/brew.git
./brew/bin/brew tap homebrew/core
Untar-Anywhere Approach
As documented at docs.brew.sh, run this command in your home directory, which will create ~/brew.
cd $HOME
mkdir brew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C brew
Finishing up
For either installation method, you'll need to change your PATH to prefer the new brew bin directory, adding something like this to your shell's dot file.
export PATH=$HOME/brew/bin:$PATH >> ~/.zshrc # or ~/.bashrc
Then running this to reload and test
exec $SHELL
which brew # see that brew is found in your path
Since this is a new installation, you have to install all your desired brew packages (again).
Install homebrew for each user
According to the brew documentation you can install it inside each User Home folder
That way all packages are going to stay inside your user folder, and will not be visible or affect other users. As a good side effect if you delete that user, no trash is left behind on your system. So system wide pollution is minimised.
This comes at the cost of more storage being used, if you install the same package for multiple users. Just something to be aware if you have a very small SSD.
Instructions
If you currently have brew installed on your system globally, I recommend uninstalling brew first. (You can see where brew is installed running which brew)
If you don't have Command Line Tools installed, you have to run this first:
xcode-select --install
Open terminal and Run:
MacOS Catalina 10.15 or newer:
cd $HOME
mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew
echo 'export PATH="$HOME/homebrew/bin:$PATH"' >> .zprofile
MacOS Mojave 10.14 or older:
cd $HOME
mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew
echo 'export PATH="$HOME/homebrew/bin:$PATH"' >> .bash_profile
Close the Terminal window
Open Terminal again, and run this to ensure your installation is correct:
brew doctor
Done!
Disabling auto update
This is not required
I also find useful to disable brew to update all packages before every time you install something.
MacOS Catalina 10.15 or newer
echo 'HOMEBREW_NO_AUTO_UPDATE=1' >> $HOME/.zprofile
MacOS Mojave 10.14 or older
echo 'HOMEBREW_NO_AUTO_UPDATE=1' >> $HOME/.bash_profile
EDIT: Please use the answer by Vitim, it's the correct one :)
Hacky workaround solution for macOS Mojave 10.14
This is a edited version of user4815162342's answer, which didn't work for me out-of-the-box.
In System Preferences, go to Users & Groups, click the lock symbol in the bottom left corner to unlock user/group creation, then create a new group called brew-usergroup. Add all users who work with brew to the group (like in the attached screenshot from a german macOS).
In terminal, do this:
echo $(brew --prefix)
echo $(groups $(whoami))
sudo dseditgroup -o edit -a $(whoami) -t user brew-usergroup
sudo chgrp -R brew-usergroup $(brew --prefix)/*
sudo chmod -R g+rwX $(brew --prefix)/*
ls -lah $(brew --prefix)
Note that this doesn't change rights of brew folders anymore (like in other answers), it changes subfolders/files of brew folders.
brew install should now work fine without errors.
The above works fine, but if you want new files to automatically inherit those permissions, set an ACL which gets inherited (otherwise only the user that pours a bottle can remove it). Found hints how to do this here: https://gist.github.com/nelstrom/4988643
As root run once (assuming all users of group "admin" should have access):
cd /usr/local
/bin/chmod -R +a "group:admin allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" Homebrew Caskroom Cellar bin
/usr/bin/chgrp -R admin Homebrew Caskroom Cellar bin
/bin/chmod -R g+rwX Homebrew Caskroom Cellar bin
ls -lae .
the -e on ls shows ACLs.
Update: now I use specific directories (see above) as it failed (sth. like out of memory)
Homebrew is not designed to be used by different Unix users. From the FAQ:
If you need to run Homebrew in a multi-user environment, consider creating a separate user account especially for use of Homebrew.
The chmod solution is not viable unless you ensure that every newly created file in the Homebrew prefix also has the group write permission, which is not the case with the default umask – or unless you keep running that chmod command every time a program writes to the Homebrew prefix.
Maintaining separate Homebrew installations for each user do sort the permissions issues but will create a number of other issues, which is why it's not recommended by Homebrew:
However do yourself a favour and use the installer to install to the default prefix. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing here. Pick another prefix at your peril!
To ease the official recommendation of using a dedicated account for Homebrew, you can use sudo to easily impersonate that user account. Assuming you named that user homebrew:
sudo -H -u homebrew brew update
-H makes sure HOME is set to the homebrew user home (e.g. /Users/homebrew) so that Homebrew can do its housekeeping there.
-u homebrew tells sudo to impersonate the homebrew user account instead of the default of root.
Here is the official answer of the Homebrew maintainer.
In addition to it I suggest to do 3 more steps. Suppose you have an admin user niki who owns the /usr/local/* dir and you are logged in as another admin user niki_at_work.
Create ~/brew.sh with these contents:
#!/bin/bash
comm="brew $#"
su niki -c "$comm"
chmod +x ~/brew.sh
Add this alias to .zshrc or equivalent: alias brew="~/brew.sh"
Now you can brew from niki_at_work like always (it will ask for niki's password):
brew update
brew install swiftlint
If you want to use a dedicated admin user for brew ex. brewadmin you should first chown brew dirs:
sudo chown -R brewadmin:admin /usr/local/*
The best solution is to add a sudoers record to allow unprivileged user 'joe' to execute any 'brew' related command as the administrative user.
Create a file at /etc/sudoers.d/joe with following content:
joe ALL=(administrator) NOPASSWD: /usr/local/bin/brew
Then you can run brew like this:
sudo -Hu administrator brew install <smth>
The above solutions didn't work for me. But running the command below worked for me.
sudo chown -R $(whoami) $(brew --prefix)/*
Source: https://github.com/Homebrew/brew/issues/3228#issuecomment-333858695
On OSX Yosemite and the latest version of meteor (1.0.1), no matter how many times I uninstall and reinstall it, I can't seem to get it running without sudo. My user account is an administrator account. But meteor refuses to run without sudo. The errors I'm getting are all:
-bash: meteor: command not found
I've seen a few posts on here with similar problems. I've tried repairing disk permissions with disk utility. I've tried:
sudo chown -R $myUsername /usr/local/bin/meteor
I'm not sure what else I can do, because it seems to be a permissions issue. Does anyone have any suggestions?
Additional info that might help:
$ sudo which meteor
/usr/local/bin/meteor
$ sudo ls -l /usr/local/bin/meteor
-rwxrwxrwx 1 root wheel 3528 Dec 18 23:14 /usr/local/bin/meteor
$ ls -ld /usr/local/bin
drwx------ 6 502 wheel 204 Dec 18 23:14 /usr/local/bin
By the way, ls -l /usr/local/bin/meteor only works with sudo.
After we clarified the permissions of the meteor executable and its base directory,
the problem became quite clear:
The Meteor binary is located in /usr/local/bin/meteor
Your user didn't have permission to the directory /usr/local/bin
The steps to resolve:
Add permission on the base directory: sudo chmod +rx /usr/local/bin
If necessary, add the base directory to PATH: PATH=$PATH:/usr/local/bin
For future reference:
When you get this kind of error: -bash: XYZ: command not found
The first thing to check is find the absolute path of XYZ, for example /path/to/XYZ
Try to run with the absolute path /path/to/XYZ
If running with /path/to/XYZ gives -bash: /path/to/XYZ: Permission denied that means you have a problem with permissions on the file and/or directories:
You need read and exec permission on the file itself: sudo chmod +rx /path/to/XYZ
You need exec permission on all path elements leading up to the file: sudo chmod +x /path /path/to
After fixing permission issues, running with /path/to/XYZ should work
After fixing permission issues, if running with XYZ (without full path) still doesn't work, that means /path/to is not on your PATH. Fix with PATH=$PATH:/path/to
Note: the above sudo chmod commands give permissions (read and exec) to all users: owner + group + other. In the case of the OP (and in most common cases), this is perfectly fine.
In situations with more sophisticated permission setup, you might need to be more specific, and use g+rx instead of +rx.
(for the record)
If it works with sudo, and without sudo you get command not found, that means that meteor is on the PATH for root but not for your user. To make it work for your user, you need to find the path to meteor and add it to your user's PATH. For example:
Become root with sudo su -
Find the path of meteor, run command: which meteor
Logout from root (Control-D) to return to your user
Add the base directory to PATH, for example if earlier which meteor gave you /usr/local/bin/meteor, then do this: PATH=$PATH:/usr/local/bin
After this, it should work with your user. To make it "permanent", add the last step in your ~/.bashrc.
If this still doesn't work, then perhaps your user doesn't have the execute permission on the file. Fix that with this command:
sudo chmod +x /usr/local/bin/meteor
From your comments it also seems your user doesn't have permission on the /usr/local/bin directory itself. Fix that with this command:
sudo chmod +rx /usr/local/bin
Shouldn't need an admin account to run it, standard user account works fine. You can locate the meteor file by typing which meteor. It will tell you what file is being used to execute.
Try removing the .meteor folder in your home directory, something like rm -rf ~/.meteor and the script from the bin folder rm /usr/local/bin/meteor or rm 'which meteor' (speech marks there are the ones above ~)
And then reinstall meteor without sudo using the curl https://install.meteor.com/ | sh command.
Should hopefully install with all the correct permissions...
I'm writing a bash script that creates directories and copy files under Mac OSX. Some of these directories and files need to be placed in folders owned by the system such as /Library/Audio/Plug-Ins, and so I run the script under sudo. Such script might look like:
copy-plugins.sh:
#!/usr/bin/env bash
mkdir -p /Library/Audio/Plug-Ins/My-Plugins
cp plugin-A.dylib /Library/Audio/Plug-Ins/My-Plugins
cp plugin-B.dylib /Library/Audio/Plug-Ins/My-Plugins
and called:
$ sudo ./copy-plugins.sh
However when running under sudo, all created directories and copied files are owned by root.
I would like to be able to run the script under sudo and have the files be owned by my user.
I could call chown after each file/directory is created or copied
copy-plugins-cumbersome.sh:
#!/usr/bin/env bash
mkdir -p /Library/Audio/Plug-Ins/My-Plugins
chown 501:501 /Library/Audio/Plug-Ins/My-Plugins
cp plugin-A.dylib /Library/Audio/Plug-Ins/My-Plugins
chown 501:501 /Library/Audio/Plug-Ins/My-Plugins/plugin-A.dylib
cp plugin-B.dylib /Library/Audio/Plug-Ins/My-Plugins
chown 501:501 /Library/Audio/Plug-Ins/My-Plugins/plugin-B.dylib
but I'm hoping for a more general solution.
As far as I can tell there is no setuid for bash.
Use cp -p option to preserve file attributes.
Note this will preserve user, group permissions and the modification and access times of the files.
As you need sudo to copy to the directories you are copying to in script, it means you need to be root to copy anything in those directories.
When you do sudo you are root for that particular command or script, so whatever will be created or executed will have root permissions. Till the time you specify.
The possible ways to come out of it without changing anything:
The one you are using, and
Other one to use -p or -a with cp
rsync -go <source file> <destination file>
-g for preserving group and
-o for preserving ownership.
Note If you do a chown out of script, you will have to specifically do sudo chown since files you would be touching belong to root.