0

I have the following bash script (which is saved as ~/fix-perms.sh):

#!/usr/bin/env bash
inotifywait -d -r -e close_write -o /dev/stdout ~/testdir |
while read path event file; do
    sudo chown user:group "$path$file"
    if [ -d "$file" ]; then
        sudo chmod 750 "$path"
        echo "Created directory '$path' with 750 permissions"
    else
        sudo chmod 640 "$path$file"
        echo "Created file '$path$file' with 640 permissions"
    fi
done

I think the intended purpose of this script is obvious, but running it in my .bashrc fails to set the group permissions properly, as demonstrated below:

# In .bashrc
~/fix-perms.sh &

# In bash session
user@CentOS8:~/testdir$ ls -lha
drwxr-x---   8 user group 4.0K Jun 18 13:06 .
drwxr-x---   8 user group 4.0K Jun 18 11:45 ..
drwxr-x---  12 user group 4.0K Jun 15 21:23 somedir
-rw-r-----   1 user group  316 Jun 15 23:23 somefile
-rw-r-----   1 user group 1.1K Jun 15 21:24 someotherfile
user@CentOS8:~/testdir$ mkdir subdir
user@CentOS8:~/testdir$ ls -lha
drwxr-x---   8 user group 4.0K Jun 18 13:06 .
drwxr-x---   8 user group 4.0K Jun 18 11:45 ..
drwxr-x---  12 user group 4.0K Jun 15 21:23 somedir
-rw-r-----   1 user group  316 Jun 15 23:23 somefile
-rw-r-----   1 user group 1.1K Jun 15 21:24 someotherfile
drwx------  12 user group 4.0K Jun 15 21:23 subdir

As you can see, the subdir directory is created and given the correct ownership, but the chmod command is failing without error for some reason. So what am I doing wrong? MTIA! :-)

EDIT: I have confirmed that inotifywait is watching the directory by adding some echo statements to the script, the output of which is now shown in the terminal whenever I add a file or folder to ~/testdir. I have also changed the event from create to close_write in the hope that this may better handle my use case.

  • ~user/testdir is probably not below /var/www/medicnet, is it? Furthermore you don't have the option --monitor. Is inotifywait running at all yet when you execute mkdir? – Hauke Laging Jun 18 at 3:40
  • Sorry that was a typo on my part.../var/www/medicnet is the name of the "real" folder that I'm watching, but when copying output from my terminal and pasting it into the post, I replaced all instances of that string with ~/testdir for illustration purposes. This would have been fine if I had simply remembered to do the same with the ~/fix-perms.sh script! I will edit the question accordingly. – Kenny83 Jun 18 at 3:57
  • 1
    Why would you use "$path$file" with chown/chmod, but not inside the [ -d ... ] test? Also, who or what is a MTIA? – muru Jun 18 at 4:10
  • @muru The whole point of the [ -d ... ] test is to determine whether the thing created is a file or directory. If you can suggest a better way to do so, I'm all ears. And MTIA stands for Many Thanks In Advance :-) – Kenny83 Jun 18 at 4:18
  • Presumably the whole point of using "$path$file" was to refer to the file where it is, not wherever your script runs – muru Jun 18 at 10:36
1

@muru's comment above got me thinking about how I was testing what's being created, and made me realise that I was being very silly. The following code in ~/fix-perms.sh works nicely:

#!/usr/bin/env bash

inotifywait -dr -e create -o /dev/stdout ~/testdir |
while read path event file; do
    sudo chown user:group "$path$file"
    if [[ $event == *"ISDIR" ]]; then
        sudo chmod 750 "$path$file"
    else
        sudo chmod 640 "$path$file"
    fi
done
| improve this answer | |
  • --monitor is still missing so that this will work for the first created object only. – Hauke Laging Jun 18 at 9:16
  • @HaukeLaging According to the manpage, -d does the same thing as -m but in the background...or am I reading that wrong? – Kenny83 Jun 19 at 6:20
  • Indeed, sorry for that. – Hauke Laging Jun 19 at 8:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.