I am trying to change permissions on a user's folder that is not an administrator. I was told to run this script:
{
sudo chflags -R nouchg,nouappnd ~ $TMPDIR..
sudo chown -R $UID:staff ~ $_
sudo chmod -R u+rwX ~ $_
chmod -R -N ~ $_
} 2> /dev/null
But I am afraid that it will chown my user folder, instead of the user I am trying to fix.
Related
I am writing a bash script to do a account restore. The contents of the home dir is zipped up using this command.
sudo sh -c "cd /home/$username; zip -0 -FS -r -b /tmp /home/0-backup/users/$username.zip ."
This works as expected.
If the user requests a restore of their data, I am doing the following
sudo sh -c "cd /home/$username; rm -rf *"
Then
sudo -u $username unzip /home/0-backup/users/$username.zip -d /home/$username/
This works as expected.
However you can see the flaw in the delete statement, if the username is not set. We delete all users home dir. I have if statements that do the checking to make sure the username is there. I am looking for some advice on a better way to handle resetting the users account data that isn't so dangerous.
One thought I had was to delete the user account and then recreate it. Then do the restore. I think that this would be less risky. I am open to any suggestions.
Check the parameters first.
Then use && after cd so that it won't execute rm if the cd fails.
if [ -n "$username" ] && [ -d "/home/$username" ]
then
sudo sh -c "cd '/home/$username' && rm -rf * .[^.]*"
fi
I added .[^.]* in the rm command so it will delete dot-files as well. [^.] is needed to prevent it from deleting . (the user's directory) and .. (the /home directory).
I want to ask when I move the Laravel project to VPS an error like this appears.
https://i.postimg.cc/mr4bB9WX/Screenshot-18.jpg
What I have done is:
$ sudo chown -R $USER:www-data storage
$ sudo chown -R $USER:www-data bootstrap/cache
$ chmod -R 775 storage
$ chmod -R 775 bootstrap/cache
# composer update
go to your project folder and open terminal.
run this command
sudo chmod -R 777 theme/gallery
You may do it like like so.
sudo chmod -R 755 theme/gallery
I have the following script which changes a password using a password file that I have piped the password to in the correct format. However, the next command needs a password file with a revised format. At the moment i just delete and re-create the file, but it would be nice to just edit it instead, im just not sure how:
sudo touch /tmp/password.txt
sudo chmod 600 /tmp/password.txt
sudo echo "AS_ADMIN_PASSWORD=" > /tmp/password.txt
sudo echo "AS_ADMIN_NEWPASSWORD=Pa55w0rd2" >> /tmp/password.txt
sudo /opt/glassfish3/bin/asadmin --user admin --passwordfile /tmp/password.txt change-admin-password \
--domain_name domain1
sudo rm /tmp/password.txt
sudo touch /tmp/password.txt
sudo chmod 600 /tmp/password.txt
sudo echo "AS_ADMIN_PASSWORD=Pa55w0rd2" > /tmp/password.txt
sudo /opt/glassfish3/bin/asadmin --user admin --passwordfile /tmp/password.txt enable-secure-admin
Perfect job for sed:
sed -i '/^AS_ADMIN_PASSWORD=/d' /tmp/password.txt
This deletes the line matching the given regex, in-place.
I am trying to run the command
chown -R "$USER" /mnt/namenode
from a bash script to change the ownership of the namenode folder and its sub-folders. When I type the command manually
sudo chown -R ubuntu /mnt/namenode
it works, but not when I do it from the script. From the script, only the ownership of the namenode is changing, not its subfolders. Does anyone know how I might fix this?
OK, I got it. My script was formatting the namenode after the ownership had been set. Before the format, the subfolders has the correct ownership recursively. After the format, the sub-folders' ownership was changing to root. So I made the following change:
echo 'Y' | /home/$USER/hadoop-2.2.0/bin/hadoop namenode -format
sudo chown -R $USER:$USER /mnt/namenode
sudo chown -R $USER:$USER /mnt/datanode
In other words, I set the ownership after I did the formatting.
Try this:
chown -R $USER:$USER /mnt/namenode
If you run the script with sudo (as you are doing), inside the script $USER will be root not the normal user.
So use sudo inside the script:
sudo chown -R "$USER" /mnt/namenode
and run the script without sudo.
I just have the same problem.
Try to add the slash at the end of folder as:
chown -R "$USER" /mnt/namenode/
I have a script that needs to be ran as root. In this script I create directories and files. The files and directories cannot be modified by the user who ran the script (unless there root of course).
I have tried several solutions found here and other sites, first I tried to mkdir -m 777 the directories as so:
#!/bin/bash
...
#Check execution location
CDIR=$(pwd)
#File setup
DATE=$(date +"%m-%d_%H:%M:%S")
LFIL="$CDIR/android-tools/logcat/logcat_$DATE.txt"
BFIL="$CDIR/android-tools/backup/backup_$DATE"
mkdir -m 777 -p "$CDIR/android-tools/logcat/"
mkdir -m 777 -p "$CDIR/android-tools/backup/"
...
I have also tried touching every created file and directory with the $USER as root, like so:
#!/bin/bash
...
#Check execution location
CDIR=$(pwd)
#File setup
DATE=$(date +"%m-%d_%H:%M:%S")
LFIL="$CDIR/android-tools/logcat/logcat_$DATE.txt"
BFIL="$CDIR/android-tools/backup/backup_$DATE"
mkdir -p "$CDIR/android-tools/logcat/"
mkdir -p "$CDIR/android-tools/backup/"
sudo -u $USER touch "$CDIR/"
sudo -u $USER touch "$CDIR/android-tools/"
sudo -u $USER touch "$CDIR/android-tools/logcat/"
sudo -u $USER touch "$CDIR/android-tools/backup/"
sudo -u $USER touch "$CDIR/android-tools/logcat/logcat_*.txt"
sudo -u $USER touch "$CDIR/android-tools/logcat/Backup_*"
...
I have also tried manually running sudo chmod 777 /android-tools/*, and sudo chmod 777 /* from the script directory, gave no errors, but I still cannot delete the files without root permission.
Heres the full script, It's not done yet. Don't run it with an android device connected to your computer.
http://pastebin.com/F20rLJQ4
touch doesn't change ownership. I think you want chown.
If you're using sudo to run your script, $USER is root, but $SUDO_USER is the user who ran sudo, so you can use that.
If you're not using sudo, you can't trust $USER to be anything in particular. The caller can set it to anything (like "root cat /etc/shadow", which would make your above script do surprising things you didn't want it to do because you said $USER instead of "$USER").
If you're running this script using setuid, you need something safer, like id -u, to get the calling process's legitimate UID regardless of what arbitrary string happens to be in $USER.
If you cover both possibilities by making makestuff.sh like this:
# $SUDO_USER if set, otherwise the current user
caller="${SUDO_USER:-$(id -u)}"
mkdir -p foo/bar/baz
chown -R "$caller" foo
Then you can use it this way:
sudo chown root makestuff.sh
sudo chmod 755 makestuff.sh
# User runs it with sudo
sudo ./makestuff.sh
# User can remove the files
rm -r foo
Or this way (if you want to use setuid so regular users can run the script without having sudo access -- which you probably don't, because you're not being careful enough for that):
sudo chown root makestuff.sh
sudo chmod 4755 makestuff.sh # Danger! I told you not to do this.
# User runs it without sudo
./makestuff.sh
# User can remove the files
rm -r foo