0

I've tried at least 15 different solutions at this point, and none have worked. I'm using a Mint 18.1 live boot drive, and trying to run a shell script on a separate drive. It simply says "permission denied" so I tried sudo chmod 777 /path/to/file.sh but to no avail. It looks like it completes, but a quick run of stat /path/to/file.sh says otherwise. I tried making a file /etc/udev/rules.d/90-usb-disks.rules with the data:

# UDEV Rules to change the permission of USB disks
#

KERNEL=="sd*[0-9]", ATTR{removable}=="1", ENV{ID_BUS}=="usb", MODE="0022"

which also didn't do anything. I tried remounting the drive with rwx permissions, but NOPE! Is there anything that will let this work?!

Side note: this script may be starting other scripts in the same folder, I don't know, so that's something to consider. Also, sorry for being a Linux noob - we all start somewhere.

  • As a side note, it's better to use chmod +x file if you want it to be executable. – Chai T. Rex Mar 12 '17 at 5:05
  • @ChaiT.Rex tried that. Same outcome as chmod 777 – wundrweapon Mar 12 '17 at 5:06
  • Can we see what your script does? Sounds like executing it, produces that output. – SYN Mar 12 '17 at 5:57
0

Most likely your external drive's filesystem doesn't support Linux/UNIX style permissions (FAT32, etc.), unfortunately chmod and friends will not return an error in this situation, they will simply be unable to set/change permissions.

Also, the MODE option in your udev rule affects the permissions of the device node (in /dev) for the filesystem itself: e.g. /dev/sdc1, not for the filesystem's contents..

That being said, there are a couple of possibilities - first, and easiest, would simply be to pass the script as an argument to the appropriate shell, e.g. bash /path/to/file.sh

This will have issues, however, if file.sh happens to call, for example, otherfile.sh inside of it.. you could, of course, modify the script to call bash as above, else you will need to ensure the filesystem is actually mounted with executable bit set for files.

In my experience, "automatic" mounts usually err on the side of caution and do not enable execute by default, but if you mount the filesystem manually from the command line as root it defaults to having all files executable... so, you could unmount the drive (remove safely, etc) from the GUI, then open a terminal and enter something like

sudo mount /dev/sdc1 /mnt

replacing /dev/sdc1 with your filesystem location (if in doubt, run dmesg and it should give you a clue the device name you'll need here.

If for some reason that still mounts without the execute bit set for files the options are filesystem specific for umask, fmask, dmask, mode, etc. man mount and check options for your_filesystem_type

  • This worked perfectly! I did need to use sudo fsck -t fat /dev/sdc1 and remove a dirty bit, but other than that, this was golden. Thank you! – wundrweapon Mar 12 '17 at 22:53

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.