February 7, 20251 yr A soon as I installed the new version I got a red triangle at the top of the UI. Clicking on it gives "Warning: API is offline!". In the settings it says "Disabled until you have signed in" but the Sign in button is disabled. Log is attached. Rebooting didn't help. Uninstall/reinstall Unraid Connect plugin didn't help. Running unraid-api gives "/usr/bin/env: ‘node’: No such file or directory". At some point the settings page said I needed to add my internal IP to my unraid machine as an extra origin. I did that and it didn't help. Trying to register the server through account.unraid.net gives a "Sign in Failed" error. logs.json
February 8, 20251 yr I tried to reload nginx which seemed to be fine. I then did a restart and got this... root@AORUS:~# /etc/rc.d/rc.nginx restart rc.nginx: Restarting Nginx server daemon... rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration... rc.nginx: Stopping Nginx server daemon gracefully... ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐ │ id │ name │ mode │ ↺ │ status │ cpu │ memory │ └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘ rc.nginx: Nginx server daemon... Stopped. rc.nginx: Starting Nginx server daemon... Starting the Unraid API ExecaError: Command failed with exit code 127: /usr/local/unraid-api/node_modules/.bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env /root/.bashrc: line 22: bind: warning: line editing not enabled /root/.hishtory/config.sh: line 9: hishtory: command not found /root/.hishtory/config.sh: line 75: hishtory: command not found /usr/bin/env: 'node': No such file or directoryrc.nginx: Nginx server daemon... Started. root@AORUS:~# The lines regarding .bashrc and .hishtory are probably not related. Then again, my line 22 is: bind -s 'set completion-ignore-case on' Not sure why that's suddenly a problem, but it doesn't give this or the other errors when I login... 🤷♂️
February 10, 20251 yr Hello. Having the same issue with version 2025.02.06.2108. No issues before I upgrade. I wonder if you solved somehow? My server is behind traefik and authentik and I wonder if there is an endpoint that needs to go as unauthenticated or something since I dont use the unraid ssl/subdomain. On 2/8/2025 at 10:21 PM, Gex2501 said: Not sure why that's suddenly a problem, but it doesn't give this or the other errors when I login... 🤷♂️ This was actually a solution that "worked" for me. I have commented out the auth-request.php file from unraid and I bypass the login screen completely since Authentik is handling authentication but if I logout then i can still get to the login screen, after I login then the API error is gone for me too. Edited February 10, 20251 yr by m33ts4k0z
February 10, 20251 yr I modified my .bashrc with this at the top to ensure it only runs things when I'm on an interactive shell. if ! [[ $- == *i* ]]; then exit fi It seems to have taken care of those particular errors but I'm still seeing the API offline warning. I execute this from a terminal to get it going again. /usr/local/unraid-api/node_modules/.bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env But eventually it stops again.
February 10, 20251 yr Just to add more info, the output of the command to get the api going again. root@AORUS:~# /usr/local/unraid-api/node_modules/.bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env [PM2][WARN] Applications unraid-api not running, starting... [PM2][WARN] App unraid-api has option 'wait_ready' set, waiting for app to be ready... [PM2] App [unraid-api] launched (1 instances) ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐ │ id │ name │ mode │ ↺ │ status │ cpu │ memory │ ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤ │ 0 │ unraid-api │ fork │ 0 │ online │ 0% │ 174.5mb │ └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘ root@AORUS:~#
February 10, 20251 yr What I ended up doing is very hackish but works for me since I already have an authentication layer at a higher level: #!/bin/bash # Create a PHP script to make the changes cat > /tmp/modify_login.php << 'EOL' <?php $file = '/usr/local/emhttp/plugins/dynamix/include/.login.php'; $content = file_get_contents($file); // Make the replacements $content = preg_replace( '/\$username = \$_POST\[\'username\'\]\?\?\'\';/', '$username = $_POST[\'username\']??\'root\';', $content ); $content = preg_replace( '/\$password = \$_POST\[\'password\'\]\?\?\'\';/', '$password = $_POST[\'password\']??\'mypass\';', $content ); // Write the changes back file_put_contents($file, $content); EOL # Execute the PHP script php /tmp/modify_login.php # Clean up rm -f /tmp/modify_login.php echo "Update completed" This custom script will essentially autologin the WebUI on each visit and if you put it as "First array start only" then will persist on each reboot too. I know it's terrible but until we finally get some other way to properly authenticate that it's not taken from the 90s that will have to do, given of course that you have some kind of reverse proxy protecting the system if you are exposing it to the Internet. Just replace the mypass with your password. I highly suggest not to try to manipulate the frontend directly since you will find this ahead of you later for sure, plus you will have to perform the hacks again on every plugin update. Trying to use the proper auth flow seems like a better and less hackish approach for now. Edited February 10, 20251 yr by m33ts4k0z
February 10, 20251 yr Strange, I don't see a file called ".login.php" at that path. Maybe because I'm on Unraid 7.0.0? root@AORUS:/var/local/overlay/usr/local/emhttp/plugins/dynamix/include# ls -la total 148K drwxr-xr-x 2 root root 220 Feb 10 12:50 ./ drwxr-xr-x 6 root root 220 Feb 10 12:50 ../ -rw-r--r-- 1 root root 51K Feb 10 12:50 DefaultPageLayout.php -rw-r--r-- 1 root root 53K Feb 10 09:56 DefaultPageLayout.php- -rw-rw-rw- 1 root root 3.4K Feb 10 12:50 DefaultPageLayout.php.patch -rw-r--r-- 1 root root 3.3K Feb 10 09:56 FileTree.php -rw-rw-rw- 1 root root 3.4K Feb 10 09:56 ProvisionCert.php -rw-r--r-- 1 root root 3.1K Feb 10 09:56 ProvisionCert.php- -rw-r--r-- 1 root root 13K Feb 10 09:56 ShareList.php -rw-r--r-- 1 root root 633 Feb 6 13:08 UpdateDNS.php -rw-r--r-- 1 root root 819 Mar 22 2024 UpdateDNS.php- root@AORUS:/var/local/overlay/usr/local/emhttp/plugins/dynamix/include#
February 10, 20251 yr Author When I run that "pm2 start" command from @Gex2501 I get the "/usr/bin/env: ‘node’: No such file or directory" error again. I forgot to mention I'm running unRAID 7.0.0. Also I don't have my server behind any other services.
February 10, 20251 yr 1 hour ago, Gex2501 said: Strange, I don't see a file called ".login.php" at that path. Maybe because I'm on Unraid 7.0.0? root@AORUS:/var/local/overlay/usr/local/emhttp/plugins/dynamix/include# ls -la total 148K drwxr-xr-x 2 root root 220 Feb 10 12:50 ./ drwxr-xr-x 6 root root 220 Feb 10 12:50 ../ -rw-r--r-- 1 root root 51K Feb 10 12:50 DefaultPageLayout.php -rw-r--r-- 1 root root 53K Feb 10 09:56 DefaultPageLayout.php- -rw-rw-rw- 1 root root 3.4K Feb 10 12:50 DefaultPageLayout.php.patch -rw-r--r-- 1 root root 3.3K Feb 10 09:56 FileTree.php -rw-rw-rw- 1 root root 3.4K Feb 10 09:56 ProvisionCert.php -rw-r--r-- 1 root root 3.1K Feb 10 09:56 ProvisionCert.php- -rw-r--r-- 1 root root 13K Feb 10 09:56 ShareList.php -rw-r--r-- 1 root root 633 Feb 6 13:08 UpdateDNS.php -rw-r--r-- 1 root root 819 Mar 22 2024 UpdateDNS.php- root@AORUS:/var/local/overlay/usr/local/emhttp/plugins/dynamix/include# Sorry the original path and script approach was indeed wrong and didn't work after a server reboot. I have updated the post with a new script and a working file. ( I am also on Unraid 7 ) Edited February 10, 20251 yr by m33ts4k0z
February 11, 20251 yr @m33ts4k0z So what is accomplished by having the GUI automatically login? I don't understand the benefit versus just using a password manager/autofill.
February 11, 20251 yr In my case, I used to bypass the login form by commenting out the auth-request.php line in /etc/nginx/nginx.conf. Since the update of the Unraid connect plugin, bypassing the auth caused the issue with the API warning. So performing an autologin solves it for me ( and most probably for everyone using a reverse proxy ) This was one problem solved, but I checked today and saw the triangle again so right now i am also on the same boat as you guys 😅 I saw that there are some reports on Discord about this too so it looks like a general issue. ( API working briefly after login but then shows triangle) i will have a look later to see what the problem is and if there is anything we can do to solve it.
February 12, 20251 yr Author Solution I solved my problem. The 'node' command not being found was the key. I had a typo in my go file that was causing the PATH not to get setup correctly. When I fixed that Connect started working as expected.
February 12, 20251 yr I am having this same problem as well and when I run the above command it did not fix the pm2 start env command from above it did not fix it even temporarily ... I uninstalled and re-installed it as well ... guess I might have to just leave it uninstalled for awhile
February 14, 20251 yr On 2/12/2025 at 9:30 PM, brentdog said: I solved my problem. The 'node' command not being found was the key. I had a typo in my go file that was causing the PATH not to get setup correctly. When I fixed that Connect started working as expected. Can you show your GO file? I have the same issue i think
February 14, 20251 yr If it helps... This is my /boot/config/go file: root@AORUS:~# cat /boot/config/go #!/bin/bash runlevel=$(runlevel | awk '{print $2}') uptime=$(awk '{print $1}' /proc/uptime) if [ "${uptime%.*}" -gt 600 ]; then echo "Uptime greater than 10 minutes. Exiting..." exit fi cd /root echo "$runlevel" > go_runlevel echo "$uptime" > go_uptime env > go_env # Start the Management Utility /usr/local/sbin/emhttp # Heatbeat Monitor heartbeat_monitor() { while true; do curl -s https://cronitor.link/p/d87c0160848f49899bf7be1433b692a5/AORUS sleep 60 done } heartbeat_monitor & # Needed for ElasticSearch sysctl -w vm.max_map_count=262144 # Needed for Redis sysctl vm.overcommit_memory=1 # Force iptable mangle module to load (required for *vpn dockers) /sbin/modprobe iptable_mangle # Restore customizations tar xzf /boot/config/root_env.tgz -C / # Themepark css for WebUI ln -sf /boot/themepark/css /usr/local/emhttp/ cat << 'EOF' >> /root/.bash_profile ################################################# ### Custom .bash_profile by Gex2501 ### ################################################# if [[ -f ~/.bashrc && $- == *i* ]]; then source ~/.bashrc fi EOF #TODO: Create .go_complete file to signal that the go file ran successfully. touch .go_complete # Create a RAMDisk #mkdir /tmp/ramdisk && chmod 777 /tmp/ramdisk && chown 99:100 /tmp/ramdisk #mount -t tmpfs -o size=128G myramdisk /tmp/ramdisk root@AORUS:~# Also, my PATH: root@AORUS:~# echo $PATH /root/bin:/usr/local/node/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/root/.hishtory root@AORUS:~# And my /boot/config/stop file for anyone intersted: root@AORUS:~# cat /boot/config/stop #!/bin/bash #TODO: check for .go_complete file and do not process if not present get_status() { case "$1" in 0) echo "SHUTDOWN" ;; 6) echo "REBOOT" ;; *) echo "UNKNOWN" ;; esac } echo "Backing up environment to /boot/config/root_env.tgz" # Backup customizations tar czf /boot/config/root_env.tgz \ --sort=name \ /root/.bash_history \ /root/.bashrc \ /root/.config \ /root/.ctop \ /root/.easyclip \ /root/.gitconfig \ /root/.hishtory \ /root/.local \ /root/.tmux \ /root/.tmux.conf \ /root/.vim \ /root/.vimrc \ /root/.zshrc \ /root/bin \ /usr/local/bin/croc \ /usr/local/bin/ctop \ /usr/share/terminfo/t/tmux-256color \ /etc/rsyslog.d/99-filter.conf \ /etc/logrotate.d/boot_syslog &> /dev/null echo "Done." runlevel=$(runlevel | awk '{print $2}') if [[ ! "$runlevel" =~ ^(0|6)$ ]]; then echo "Script is not running at shutdown or reboot. Exiting." exit 0 fi msg="Server going down. STOP script running. RUNLEVEL: $(get_status $runlevel)" curl -s -F "token=au3nm7dhfaokxxeshiqdpbswykafr8" \ -F "user=EgU49ajaQwmw46S7ad5h0D7gFrXtTg" \ -F "title=$(hostname)" \ -F "message=$msg" https://api.pushover.net/1/messages.json &> /dev/null root@AORUS:~#
February 14, 20251 yr Author 49 minutes ago, Croontje said: Can you show your GO file? I have the same issue i think The part that was causing my problem was this: echo "export PATH=$PATH:/tmp/bin:/usr/local/emhttp/plugins/tailscale/bin" >> /root/.bash_profile Not escaping the dollar sign was causing the PATH to just be hardcoded to whatever it was when the go file ran. The corrected version is this: echo "export PATH=\$PATH:/tmp/bin:/usr/local/emhttp/plugins/tailscale/bin" >> /root/.bash_profile
February 16, 20251 yr On 2/14/2025 at 4:19 PM, brentdog said: The part that was causing my problem was this: echo "export PATH=$PATH:/tmp/bin:/usr/local/emhttp/plugins/tailscale/bin" >> /root/.bash_profile Not escaping the dollar sign was causing the PATH to just be hardcoded to whatever it was when the go file ran. The corrected version is this: echo "export PATH=\$PATH:/tmp/bin:/usr/local/emhttp/plugins/tailscale/bin" >> /root/.bash_profile FYI -- adding /usr/local/emhttp/plugins/tailscale/bin to the system PATH is unnecessary... tailscale and tailscaled get linked into /usr/local/sbin/ during the plugin installation.
February 16, 20251 yr Author 59 minutes ago, EDACerton said: FYI -- adding /usr/local/emhttp/plugins/tailscale/bin to the system PATH is unnecessary... tailscale and tailscaled get linked into /usr/local/sbin/ during the plugin installation. Good to know. I have removed the tailscale part from the path. I'm not sure why I had that in there. I guess at some point it was necessary.
February 17, 20251 yr I'm surprised we have seen any temporary fix or solution for this problem yet. Seems like a significant issue the devs need to address. Also still getting this sent to me every day: warning: Potentially dangerous mode on unraid-api: 0666 error: Ignoring unraid-api because it is writable by group or others. error: found error in file unraid-api, skipping warning: Potentially dangerous mode on unraid-api.patch: 0666 error: Ignoring unraid-api.patch because it is writable by group or others. error: found error in file unraid-api.patch, skippin I know it's harmless, but it's a bug and it's annoying. I think this will fix it until the next reboot at least. root@AORUS:~# chmod 644 /etc/logrotate.d/unraid-api* Edited February 17, 20251 yr by Gex2501 temporary fix
March 4, 20251 yr With unraid 7.0.0 most of the above worked, and I could manually get unraid connect to run. But with 7.0.1, something has gone horribly wrong. After uninstalling and reinstalling the plugin, everything in /usr/local/unraid-api/node_modules/.bin/ points to something under /home/runner which doesn't exist. I'm not sure how to proceed, though I'll try to dig as soon as I have time.
March 4, 20251 yr Maybe try this path for pm2. I haven't tried 7.0.1 yet but maybe this will work... /usr/local/unraid-api/node_modules/pm2/bin/pm2
March 4, 20251 yr oh man. @rbroberts let me check with the team. We caught this issue during testing--sorry that it actually made it out, especially without an immediate fix/update. funnily enough @Gex2501, changing the path we used for pm2 was part of the fix. const PM2_PATH = join(import.meta.dirname, '../../', 'node_modules', 'pm2', 'bin', 'pm2');
March 4, 20251 yr 33 minutes ago, pujitm said: oh man. @rbroberts let me check with the team. We caught this issue during testing--sorry that it actually made it out, especially without an immediate fix/update. funnily enough @Gex2501, changing the path we used for pm2 was part of the fix. const PM2_PATH = join(import.meta.dirname, '../../', 'node_modules', 'pm2', 'bin', 'pm2'); i'm also seeing this issue, but on only 1 of my servers.. what should i change to get this fixed and where do i change this
March 5, 20251 yr On 3/4/2025 at 10:35 AM, pujitm said: oh man. @rbroberts let me check with the team. We caught this issue during testing--sorry that it actually made it out, especially without an immediate fix/update. funnily enough @Gex2501, changing the path we used for pm2 was part of the fix. Well, there's a couple of pm2 files to be found root@Tower:/boot/config# find /usr/local -type f -name pm2 /usr/local/unraid-api/node_modules/pm2/pm2 /usr/local/unraid-api/node_modules/pm2/lib/templates/logrotate.d/pm2 /usr/local/unraid-api/node_modules/pm2/bin/pm2 of which the first looks most promising based on it's content as a bash script. But this looks wrong since node doesn't live where this script wants to find it. root@Tower:/boot/config# cat /usr/local/unraid-api/node_modules/pm2/pm2 #!/bin/bash DIR="$(dirname "$(readlink -f "$0")")" $DIR/node/bin/node $DIR/bin/pm2 $@ Based on root@Tower:/boot/config# find /usr/local -type f -name node /usr/local/node/bin/node I suspect the problem is the readlink. There is a symlink from /usr/local/bin/pm2, but trying to use that to start things root@Tower:/usr/local/bin# /usr/local/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env /usr/bin/env: ‘node’: No such file or directory but that can be fixed by adding /usr/local/node to PATH export PATH=$PATH:/usr/local/node After which /usr/local/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env will get things started. Note that this is not the same as the original attempt as /usr/local/bin/pm2 is a node script and it bypasses any funkiness with readlink. I'm not sure what the canonical way to get unraid-connect started is, but this seems to work. Edited March 5, 20251 yr by rbroberts
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.