• Cannot Execute Scripts from Flash Drive [6.8.0 RC1]


    BBoYTuRBo
    • Solved Annoyance

    So I just updated to 6.8.0 RC1.

    I have a bunch of scripts stored at /boot/scripts

    After booting up, I tried to run a script, and it said permission denied. I looked, and all my scripts are set to -rw------- permissions, and I cannot change them. When I try executing chmod, it doesn't give an error, but it doesn't do anything either. Chown throws an "operation not permitted" error.




    User Feedback

    Recommended Comments

    In summary, copy any scripts to /tmp, set permissions, and execute them from there. The "go" file is executed in the same way (not from flash) since day one. Another option is to use the User Scripts plugin.

    Link to comment
    1 hour ago, dee31797 said:

    Just curious, can you change the permissions of the flash files in the go file?

    No. Global permissions are set at mount time.

    Link to comment
    1 minute ago, JoeUnraidUser said:

    You are incorrect about CA User Scripts.  A script cannot be scheduled to run at boot.  Also, you can only run Bash scripts.

    My bad. I was repeating information read in other threads.

    Link to comment
    1 hour ago, JoeUnraidUser said:

    You are incorrect about CA User Scripts.  A script cannot be scheduled to run at boot.  Also, you can only run Bash scripts.

    You can set them to run "at first array start only". I'd prefer if you could run them prior to starting the array, but most of the time it is a close approximation to "at boot"

     

    Also, it will run php scripts as well.

    Link to comment
    7 hours ago, jbartlett said:

    No. Global permissions are set at mount time.

    Thank you.

     

    Just curious, if the mount time is after the go file, can you remount with different permissions? or if mount time is before go file can you remount with user scripts with different permissions? thanks

    Link to comment
    15 minutes ago, dee31797 said:

    Just curious, if the mount time is after the go file, can you remount with different permissions? or if mount time is before go file can you remount with user scripts with different permissions? thanks

    Why bother?   You can always use the 'go' file to copy the scripts to a location from which they CAN be executed.

    Link to comment
    1 minute ago, itimpi said:

    Why bother?   You can always use the 'go' file to copy the scripts to a location from which they CAN be executed.

    Yes I know, there's no use case outside of what we think there should be.

     

    Just out of curiosity though, what would would happen if you remounted the flash, and when does the mount happen in relation to the go file?

    Link to comment
    13 minutes ago, dee31797 said:

    Just out of curiosity though, what would would happen if you remounted the flash, and when does the mount happen in relation to the go file?

    If you think about it the mount must happen before the 'go' file executes as otherwise the 'go' file would not be found in the first place :)   In fact the mount must happen very early in the boot sequence as the flash needs to be mounted to enable Unraid to read all its configuration information.

    Edited by itimpi
    Link to comment
    8 minutes ago, itimpi said:

    If you think about it the mount must happen before the 'go' file executes as otherwise the 'go' file would not be found in the first place :)

    ok awesome! thanks!

    Link to comment
    2 hours ago, itimpi said:

    In fact the mount must happen very early in the boot sequence as the flash needs to be mounted to enable Unraid to read all its configuration information.

    Correct

    Link to comment
    20 minutes ago, JoeUnraidUser said:

    The one thing I am worried about

    If that's all you worry about I'd say you're doing pretty well 😎

    Link to comment
    3 hours ago, JoeUnraidUser said:

    The one thing I am worried about is at some point in the future are they going to make it so the go file doesn't run as root.  That will cause problems for people who have to put commands in the go file to make their hardware work properly.

    You can circumvent that with the SETUID bit.

    2 hours ago, JoeUnraidUser said:

    I created a script to run from the go file that copies the user's scripts from the flash drive to /root/bin then sets there permissions to 700.  That way the files can be executed at anytime.  Should I post the script in this thread or in a different one?

     

    Edit: I also set the root's PATH to include /root/bin

    I've been using an overlayfs for my /root/ folder so that any changes I make are automatically on the flash drive, and support full *nix permissions. The go file is only used to mount that overlay and kick off any scripts if needed.

    I can share the steps here to recreate the overlayfs. It also enables things like preference persistence for htop, tmux, etc.

    Link to comment
    6 hours ago, JoeUnraidUser said:

    That would be great if you can share the instructions.

    Apparently it doesn't like me that much; instead:

    In the particular usage case for this thread:

    • Remove the scripts folder from /boot/config
    • Remove the copy from /boot/config/go
    • Create the overlay
    • Add the overlay to /boot/config/go
    • Copy the scripts to the root directory and set permissions
    • Call the scripts from /boot/config/go or however you normally do.
    • Thanks 1
    Link to comment
    43 minutes ago, JoeUnraidUser said:

    I created a script, "setup_scripts", which allows you to run scripts from "/root/bin":

    Why do all this?  Just use 'bash' command to run your script.

    Link to comment

    I only do the overlay as I like persistent settings and bash history. 4GB is massive overkill for that. I also know adding just a couple of lines to the "go" file works but then I have to add lines every time I customize something new. Overlay "just works"

    I do wholely agree though - for a handful of scripts being added to the 'go' file calling them with their interpreter is sufficient.

    Edited by Xaero
    Link to comment
    On 10/14/2019 at 10:59 PM, JoeUnraidUser said:

    You are incorrect about CA User Scripts.  A script cannot be scheduled to run at boot.  Also, you can only run Bash scripts.

    So wait.

    I was copying the borg executable from one place to /usr/local/bin on startup so that it's available to a backup script.

    Not sure that was the right way to do it, but it seemed to be a way to add utilities to the system.

    Right now, I'm copying this file to /tmp, then chmod +x, then deleting the file after the script is done.

    Is this the recommended way to do this now?

    Link to comment

    None of the solutions shown worked as far as I could tell to get a program I wrote as a Linux terminal program to run in my FAT32 partition, but changing the filename of the program to include .exe extension did work (thanks for the tip), all I did was rename filename to filename.exe for the terminal program I was trying to execute on a FAT32 partition, and then un-mount it, re-mount it and set the disk permissions to allow execution, then go to filename.exe and set its permissions and then the check mark would stick rather than turn back to a minus, and when I set the path and entered ./filename.exe at the terminal prompt the program ran as it should and shows the command line including filename.exe as entered, although the Ubuntu file directory shows the file as MSDOS/Windows it does run as a Linux program.

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.