NFS share bash script issue

[opethdisciple]

I'm working on a backup script for my satellite server.

Red Hat provide a script which I have modified.

My issue is the following.

The script will run as root (I suppose)

I need to mount and unmount an nfs share.

Then sudo su to a user that has write permissions (nfsuser) on the share then run the satellite-backup command then exit as nfsuser back to root and umount the nfs share.

The problem is the satellite-backup command seems to need to run as root, but at this point I am currently in as nfsuser:

#!/bin/bash -e
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
DESTINATION=/backups/satellite_backup
YEAR=$(date +%Y)
WEEK=$(date +%-V)

mount nfsshareserver:/backup /backups
sudo su nfsuser

if [[ $(date +%w) == 0 ]]; then
satellite-backup $DESTINATION/$YEAR-$((WEEK + 1)) --assumeyes
else
LAST=$(ls -td -- $DESTINATION/$YEAR-$WEEK/*/ | head -n 1)
satellite-backup $DESTINATION/$YEAR-$WEEK --incremental "$LAST" --assumeyes
fi
exit 0

exit
umount /backups

How do I make the satellte-backup command run as root. The issue is only the nfsuser can write to the nfs share.

 

[the-evaluator]

I think this would work:

sudo su root -c 'satellite-backup $DESTINATION/$YEAR-$((WEEK + 1)) --assumeyes'

That'd run that command as root and then drop back to the nfsuser. You'd need to edit the second satellite-backup command too of course.

 

[opethdisciple]

I think this would work:

sudo su root -c 'satellite-backup $DESTINATION/$YEAR-$((WEEK + 1)) --assumeyes'

That'd run that command as root and then drop back to the nfsuser. You'd need to edit the second satellite-backup command too of course.

I'll try it tomorrow.

However isn't the problem that the nfsuser doesn't have privileges to sudo su root?

 

[the-evaluator]

However isn't the problem that the nfsuser doesn't have privileges to sudo su root?

Possibly, but that's easiy fixed by editing /etc/sudoers.

 

[PaulCa]

The problem is root_squash.

When root attempts to access an NFS share, by default they are demoted to "nobody" or "anon user". Usually "nobody" can not write to any files, except those set to 777 file mode.

DO NOT DISABLE THIS FEATURE UNLESS YOU REALLY, REALLY trust yourself. I have learnt this the hard way when I was building a new test system and decided to abandon it. Thinking there was nothing worth keeping I did an rm -fr /* However when I started seeing the path /mnt/shared/ going up the screen I realised I had network drives mounted with root_squash disabled. Luckily I stopped it before I lost all my bulk storage. Since then I find other ways to do things rather than disable root squash.

What I would do is execute the backup on the server as root. You can then just execute it over ssh:

ssh root@server /some/path/satelite-backup ......

Note, however you can run a command remotely and consume it's output locally, so this actually works:

ssh root@server tar -cvzf - /some/important/path > local-tar-file.tar.gz

or even tar on the remote and zip on the local:

ssh root@server tar -cvf - /some/important/path | gzip > local-tar-file.tar.gz

Note that setting up passphraseless ssh keys in ~/.ssh/authorized_keys will help with this approach as no password is required to login.

EDIT: If you have heeded my warning and are happy enough to go ahead, you can disable root_squash by adding no_root_squash to the NFS export options in /etc/exports