-
[Plugin] FolderView3
Hi @chodeus, thank you so much for your work! The plugin is amazing. Wanna report a minor cosmetic issue: On firefox, the docker containers table horizontally overflows a bit, causing a scroll bar displaying at the bottom. This happens both in basic view and advanced view. Seems like chrome is not affected tho, just firefox. Here's a screenshot: As you can see there's a horizontal scroll bar on the bottom, and I can scroll it to the right: And devtool indicates that it's the docker_containers table overflowing.
-
Plugin update didn't restart unraid api
Weirdly, my system also doesn't have this file, but my graphql-api.log doesn't have the same warning, only an info: $> cat graphql-api.log | grep "Activation directory" [16:09:17 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.18.1+0d1d270","logger":"api","context":"CustomizationService"} [17:09:39 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.18.2+5d89682","logger":"api","context":"CustomizationService"} [18:09:36 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.18.2+5d89682","logger":"api","context":"CustomizationService"} [17:09:30 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.19.1+16905dd","logger":"api","context":"CustomizationService"} [18:09:20 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.20.4+abc22bd","logger":"api","context":"CustomizationService"} [09:09:29 INFO CustomizationService]: Activation directory /boot/config/activation not found. Skipping activation setup. {"apiVersion":"4.21.0+88a924c","logger":"api","context":"CustomizationService"}Maybe a difference between UnRAID 6 and 7? Also, my update from 4.19.1 to 4.20.4 went smoothly, but from 4.20.4 to 4.21.0 it gets stuck again.
-
Plugin update didn't restart unraid api
Since 4.18.1 the plugin update is able to start unraid-api in the update process, however since 4.18.2 the update process doesn't quit, and is stuck at Starting the Unraid API forever. log: plugin: updating: dynamix.unraid.net.plg Executing hook script: pre_plugin_checks plugin: downloading: dynamix.unraid.net-4.19.1-x86_64-1.txz ... done Running on supported version 7.1.4 plugin: skipping: unraid_connect_cleanup_for_unsupported_os_versions.sh - Unraid version too high, requires at most version 6.12.0 Backing up original files... Backup complete. Patching header logo if necessary... Installing package... Removing old package file: /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.18.2-x86_64-1.txz Cleaning up existing node_modules directory... Removing: /usr/local/unraid-api/node_modules Cleaning up existing unraid-components directory... Clearing contents of: /usr/local/emhttp/plugins/dynamix.my.servers/unraid-components +============================================================================== | Upgrading dynamix.unraid.net-4.18.2-x86_64-1 package using /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.19.1-x86_64-1.txz +============================================================================== Pre-installing package dynamix.unraid.net-4.19.1-x86_64-1... Removing package: dynamix.unraid.net-4.18.2-x86_64-1-upgraded-2025-09-06,01:07:11 Verifying package dynamix.unraid.net-4.19.1-x86_64-1.txz. Installing package dynamix.unraid.net-4.19.1-x86_64-1.txz: PACKAGE DESCRIPTION: # dynamix.unraid.net (Unraid API) # # Provides the Unraid API and Connect services for Unraid OS. # This package enables remote management, monitoring, and access # to Unraid servers through the Unraid Connect platform. # # Features include system monitoring, notifications, remote access, # and integration with the Unraid Connect dashboard. # # Homepage: https://unraid.net/ Executing install script for dynamix.unraid.net-4.19.1-x86_64-1.txz. Package dynamix.unraid.net-4.19.1-x86_64-1.txz installed. Package dynamix.unraid.net-4.18.2-x86_64-1 upgraded with new package /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.19.1-x86_64-1.txz. Starting Unraid Connect installation... Setting up Unraid API... Running setup_api.sh Starting API setup script Environment: CONFIG_DIR=/boot/config/plugins/dynamix.my.servers, API_BASE_DIR=/usr/local/unraid-api UNRAID_BINARY_PATH=/usr/local/bin/unraid-api Env file already exists API setup completed at Sat Sep 6 01:07:22 CST 2025 Running post-installation verification... Running verify_install.sh Performing comprehensive installation verification... Checking executable files... ✓ Executable file /usr/local/bin/unraid-api exists and is executable ✓ Executable file /etc/rc.d/rc.unraid-api exists and is executable ✓ Executable file /usr/local/emhttp/plugins/dynamix.my.servers/scripts/gitflash_log exists and is executable Checking directories... ✓ Directory /usr/local/unraid-api exists ✓ Directory /var/log/unraid-api exists ✓ Directory /usr/local/emhttp/plugins/dynamix.my.servers exists ✓ Directory /usr/local/emhttp/plugins/dynamix.unraid.net exists ✓ Directory /etc/rc.d/rc6.d exists ✓ Directory /etc/rc.d/rc0.d exists Checking symlinks... ✓ Symlink /usr/local/bin/unraid-api exists -> ../unraid-api/dist/cli.js ✓ Symlink /usr/local/sbin/unraid-api exists -> ../bin/unraid-api ✓ Symlink /usr/bin/unraid-api exists -> ../local/bin/unraid-api Checking configuration files... ✓ Environment file /boot/config/plugins/dynamix.my.servers/env exists Checking shutdown configuration... Checking for shutdown scripts in rc6.d... ✓ Shutdown script for flash-backup exists and is executable ✓ Shutdown script for unraid-api exists and is executable ✓ rc0.d symlink exists ✓ unraid-api is in PATH Installation log file not found Verification summary: - Executable files errors: 0 - Directory errors: 0 - Symlink errors: 0 - Configuration errors: 0 - Shutdown configuration errors: 0 - Total errors: 0 All checks passed successfully. Installation verification completed successfully. Installation completed at Sat Sep 6 01:07:22 CST 2025 Cleaning up node_modules archives that don't match current API version: 4.19.1 Current archive to keep: node_modules-for-v4.19.1.tar.xz Cleanup completed. Starting Unraid API service DEBUG: Checking PATH: .:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin DEBUG: Checking if unraid-api files exist: total 16 drwxr-xr-x 3 root root 100 Sep 5 08:21 . drwxr-xr-x 5 root root 320 Sep 6 01:07 .. drwxr-xr-x 2 root root 540 Sep 6 01:07 assets -rwxr-xr-x 1 root root 1437 Sep 5 08:21 cli.js -rwxr-xr-x 1 root root 8227 Sep 5 08:21 main.js DEBUG: Checking symlink: lrwxrwxrwx 1 root root 25 Sep 6 01:07 /usr/local/bin/unraid-api -> ../unraid-api/dist/cli.js DEBUG: Checking Node.js version: v22.18.0 DEBUG: Checking if cli.js is executable: -rwxr-xr-x 1 root root 1437 Sep 5 08:21 /usr/local/unraid-api/dist/cli.js DEBUG: Attempting to run unraid-api directly: Unraid API v4.19.1+16905dd If no additional messages appear within 30 seconds, it is safe to refresh the page. Added bundled plugin unraid-api-plugin-connect Starting Unraid API service... Starting flash backup service... Starting the Unraid APIAnnnd it never reaches the finishing line, even though unraid-api is already started. (unraid-api status shows online and latest version) Only 4.18.1 can start and properly exit, 4.18.2 and 4.19.1 both stuck on starting forever but correctly starts unraid-api.
-
Plugin update didn't restart unraid api
Hmm, after the last update (4.18.1 / 2025.09.03.1353), unraid-api start command is working correctly. And the update process also starts it correctly.
-
Plugin update didn't restart unraid api
No, it IS starting. start does not start unraid-api, but restart does. Regardless, here's the content of ecosystem.config.json: { "$schema": "https://json.schemastore.org/pm2-ecosystem", "apps": [ { "name": "unraid-api", "script": "./dist/main.js", "cwd": "/usr/local/unraid-api", "exec_mode": "fork", "wait_ready": true, "listen_timeout": 15000, "max_restarts": 10, "min_uptime": 10000, "watch": false, "interpreter": "/usr/local/bin/node", "ignore_watch": ["node_modules", "src", ".env.*", "myservers.cfg"], "log_file": "/var/log/graphql-api.log", "kill_timeout": 10000 } ] }
-
Plugin update didn't restart unraid api
Here it is: root@Tower ~# ls -al /usr/local/unraid-api/ total 492 drwxr-xr-x 5 root root 320 Aug 29 00:21 ./ drwxr-xr-x 1 root root 240 Aug 28 04:43 ../ -rw-r--r-- 1 root root 209 Aug 29 00:21 .env -rw-r--r-- 1 root root 1526 Aug 28 04:40 .env.development -rw-r--r-- 1 root root 209 Aug 23 22:07 .env.old -rw-r--r-- 1 root root 209 Aug 28 04:40 .env.production -rw-r--r-- 1 root root 214 Aug 28 04:40 .env.staging -rw-r--r-- 1 root root 1029 Aug 28 04:40 .env.test -rw-r--r-- 1 root root 0 Aug 28 04:43 .gitkeep -rw-r--r-- 1 root root 1856 Aug 28 04:40 README.md drwxr-xr-x 3 root root 100 Aug 28 04:40 dist/ -rw-r--r-- 1 root root 634 Aug 28 04:40 ecosystem.config.json drwxr-xr-x 615 root root 12320 Aug 28 04:42 node_modules/ -rw-r--r-- 1 root root 460640 Aug 28 04:42 package-lock.json -rw-r--r-- 1 root root 6025 Aug 28 04:42 package.json drwxr-xr-x 2 root root 80 Aug 28 04:41 packages/ root@Tower ~# ls -al /usr/local/unraid-api/node_modules/pm2/bin/pm2 -rwxr-xr-x 1 root root 56 Aug 28 04:41 /usr/local/unraid-api/node_modules/pm2/bin/pm2* Nope. They are both normal files, before and after. And I just find out today, that unraid-api start always shows this error, regardless of whether an instance is running or not. Like this: root@Tower ~# unraid-api status ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐ │ id │ name │ mode │ ↺ │ status │ cpu │ memory │ ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤ │ 0 │ unraid-api │ fork │ 0 │ online │ 0% │ 202.3mb │ └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘ root@Tower ~# unraid-api start Starting the Unraid API ExecaError: Command failed with exit code 127: /usr/local/unraid-api/node_modules/pm2/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env error: Unable to read input file: Is a directory⏎ root@Tower ~# unraid-api restart Restarting the Unraid API... [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 │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │ ├────┼───────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤ │ 0 │ unraid-api │ default │ 4.17.0… │ fork │ 40087 │ 13s │ 0 │ online │ 0% │ 217.6mb │ root │ disabled │ └────┴───────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘ root@Tower ~# unraid-api stop [PM2] [unraid-api](0) ✓ ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐ │ id │ name │ mode │ ↺ │ status │ cpu │ memory │ └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘ root@Tower ~# unraid-api start Starting the Unraid API ExecaError: Command failed with exit code 127: /usr/local/unraid-api/node_modules/pm2/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env error: Unable to read input file: Is a directory⏎ root@Tower ~# unraid-api restart Restarting the Unraid API... [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 │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │ ├────┼───────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤ │ 0 │ unraid-api │ default │ 4.17.0… │ fork │ 41125 │ 13s │ 0 │ online │ 0% │ 222.8mb │ root │ disabled │ └────┴───────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘ Not sure why it's doing this though.
-
IPv6 DNS is unreachable inside docker container
Docker daemon copies /etc/resolv.conf from host into containers on bridge network, which contains an ipv6 address which the container cannot access. (I have enabled IPv6 of course) For example my resolv.conf in a container: (they look the same in all containers) # Generated by Docker Engine. # This file can be edited; Docker Engine will not make further changes once it # has been modified. nameserver 192.168.31.1 nameserver fe80::46df:65ff:fe93:2ab%br0 # Based on host file: '/etc/resolv.conf' (legacy) # Overrides: []The br0 interface doesn't exist in the container, which makes this address unreachable. Which in turn breaks some tools like nslookup. Some version of nslookup reports: nslookup: parse of /etc/resolv.conf failed, and busybox version of nslookup reports: nslookup: bad address 'fe80::46df:65ff:fe93:2ab%br0'. Manual deleting the ipv6 line temporarily fixes the issue, which confirms this is the cause. One of my container depends on nslookup internally, and is broken because of this issue. The container is able to access IPv6 though, other tools like curl is able to resolve and connect to ipv6 websites just fine.
-
Plugin update didn't restart unraid api
After the latest plugin update (2025.08.20.2129, 4.15.1), unraid-api still didn't start itself. However I tried to start it using unraid-api start instead of unraid-api restart this time, and this error appears: Starting the Unraid API ExecaError: Command failed with exit code 127: /usr/local/unraid-api/node_modules/pm2/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env error: Unable to read input file: Is a directory⏎unraid-api restart is still able to start it correctly.
-
Plugin update didn't restart unraid api
After updating unraid connect plugin, even though it says Unraid API service started, it was never actually started. Update log: plugin: updating: dynamix.unraid.net.plg Executing hook script: pre_plugin_checks plugin: downloading: dynamix.unraid.net-4.14.0-x86_64-1.txz ... done Running on supported version 7.1.4 Backing up original files... Backed up: /usr/local/emhttp/plugins/dynamix.my.servers/Connect.page Backup complete. Patching header logo if necessary... Installing package... Removing old package file: /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.13.1-x86_64-1.txz Cleaning up existing node_modules directory... Removing: /usr/local/unraid-api/node_modules +============================================================================== | Upgrading dynamix.unraid.net-4.13.1-x86_64-1 package using /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.14.0-x86_64-1.txz +============================================================================== Pre-installing package dynamix.unraid.net-4.14.0-x86_64-1... Removing package: dynamix.unraid.net-4.13.1-x86_64-1-upgraded-2025-08-21,00:55:23 Verifying package dynamix.unraid.net-4.14.0-x86_64-1.txz. Installing package dynamix.unraid.net-4.14.0-x86_64-1.txz: PACKAGE DESCRIPTION: # dynamix.unraid.net (Unraid API) # # Provides the Unraid API and Connect services for Unraid OS. # This package enables remote management, monitoring, and access # to Unraid servers through the Unraid Connect platform. # # Features include system monitoring, notifications, remote access, # and integration with the Unraid Connect dashboard. # # Homepage: https://unraid.net/ Executing install script for dynamix.unraid.net-4.14.0-x86_64-1.txz. Package dynamix.unraid.net-4.14.0-x86_64-1.txz installed. Package dynamix.unraid.net-4.13.1-x86_64-1 upgraded with new package /boot/config/plugins/dynamix.my.servers/dynamix.unraid.net-4.14.0-x86_64-1.txz. Starting Unraid Connect installation... Setting up Unraid API... Running setup_api.sh Starting API setup script Environment: CONFIG_DIR=/boot/config/plugins/dynamix.my.servers, API_BASE_DIR=/usr/local/unraid-api UNRAID_BINARY_PATH=/usr/local/bin/unraid-api Env file already exists API setup completed at Thu Aug 21 00:55:36 CST 2025 Running post-installation verification... Running verify_install.sh Performing comprehensive installation verification... Checking executable files... ✓ Executable file /usr/local/bin/unraid-api exists and is executable ✓ Executable file /etc/rc.d/rc.unraid-api exists and is executable ✓ Executable file /usr/local/emhttp/plugins/dynamix.my.servers/scripts/gitflash_log exists and is executable Checking directories... ✓ Directory /usr/local/unraid-api exists ✓ Directory /var/log/unraid-api exists ✓ Directory /usr/local/emhttp/plugins/dynamix.my.servers exists ✓ Directory /usr/local/emhttp/plugins/dynamix.unraid.net exists ✓ Directory /etc/rc.d/rc6.d exists ✓ Directory /etc/rc.d/rc0.d exists Checking symlinks... ✓ Symlink /usr/local/bin/unraid-api exists -> ../unraid-api/dist/cli.js ✓ Symlink /usr/local/sbin/unraid-api exists -> ../bin/unraid-api ✓ Symlink /usr/bin/unraid-api exists -> ../local/bin/unraid-api Checking configuration files... ✓ Environment file /boot/config/plugins/dynamix.my.servers/env exists Checking shutdown configuration... Checking for shutdown scripts in rc6.d... ✓ Shutdown script for flash-backup exists and is executable ✓ Shutdown script for unraid-api exists and is executable ✓ rc0.d symlink exists ✓ unraid-api is in PATH Installation log file not found Verification summary: - Executable files errors: 0 - Directory errors: 0 - Symlink errors: 0 - Configuration errors: 0 - Shutdown configuration errors: 0 - Total errors: 0 All checks passed successfully. Installation verification completed successfully. Installation completed at Thu Aug 21 00:55:36 CST 2025 Cleaning up node_modules archives that don't match current API version: 4.14.0 Current archive to keep: node_modules-for-v4.14.0.tar.xz Cleanup completed. Starting Unraid API service DEBUG: Checking PATH: .:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin DEBUG: Checking if unraid-api files exist: total 12 drwxr-xr-x 3 root root 100 Aug 20 02:47 . drwxr-xr-x 5 root root 320 Aug 21 00:55 .. drwxr-xr-x 2 root root 540 Aug 21 00:55 assets -rwxr-xr-x 1 root root 1437 Aug 20 02:47 cli.js -rwxr-xr-x 1 root root 8189 Aug 20 02:47 main.js DEBUG: Checking symlink: lrwxrwxrwx 1 root root 25 Aug 21 00:55 /usr/local/bin/unraid-api -> ../unraid-api/dist/cli.js DEBUG: Checking Node.js version: v22.18.0 DEBUG: Checking if cli.js is executable: -rwxr-xr-x 1 root root 1437 Aug 20 02:47 /usr/local/unraid-api/dist/cli.js DEBUG: Attempting to run unraid-api directly: Unraid API v4.14.0+26aeca3 If no additional messages appear within 30 seconds, it is safe to refresh the page. Added bundled plugin unraid-api-plugin-connect Starting Unraid API service... Starting flash backup service... Starting the Unraid API Unraid API service started Installation is complete, it is safe to close this window plugin: dynamix.unraid.net.plg updated Executing hook script: post_plugin_checks When checking unraid-api status in CLI, it states no unraid-api instances is running. When checking unraid-api logs, there's no log in between the stopping and manual starting later. (Plugin was updated at 00:55, I manually started unraid-api 5 min later) [00:55:40.427] INFO: Exiting with signal 130 {"apiVersion":"4.13.1+58b5544"} [00:55:40.577] INFO: Rolling back all modifications... {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.577] INFO: Rolling back modification: set-password-modal {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.578] INFO: Successfully rolled back modification: set-password-modal {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.579] INFO: Rolling back modification: rc-nginx {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.579] INFO: Successfully rolled back modification: rc-nginx {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.579] INFO: Rolling back modification: notifications-page {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.580] INFO: Successfully rolled back modification: notifications-page {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.580] INFO: Rolling back modification: default-page-layout {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.581] INFO: Successfully rolled back modification: default-page-layout {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.581] INFO: Rolling back modification: auth-request {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.582] INFO: Successfully rolled back modification: auth-request {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UnraidFileModificationService"} [00:55:40.582] INFO: RClone process not running or already stopped. {"apiVersion":"4.13.1+58b5544","logger":"api","context":"RCloneApiService"} [00:55:40.582] INFO: RCloneApiService module destroyed {"apiVersion":"4.13.1+58b5544","logger":"api","context":"RCloneApiService"} [00:55:40.582] WARN: UPNP Mapping removal failed. Missing ports: {} {"apiVersion":"4.13.1+58b5544","logger":"api","context":"UpnpService"} [01:00:33.612] INFO: ENV {"API_VERSION":"4.14.0+26aeca3","BYPASS_CORS_CHECKS":false,"BYPASS_PERMISSION_CHECKS":false,"CHOKIDAR_USEPOLLING":false,"DEBUG":false,"ECOSYSTEM_PATH":"/usr/local/unraid-api/ecosystem.config.json","ENVIRONMENT":"production","GRAPHQL_INTROSPECTION":false,"INTROSPECTION":false,"IS_DOCKER":false,"LOG_CORS":false,"LOG_LEVEL":"INFO","LOG_TYPE":"pretty","MOTHERSHIP_GRAPHQL_LINK":"https://mothership.unraid.net/ws","NODE_ENV":"production","PATHS_CONFIG_MODULES":"/boot/config/plugins/dynamix.my.servers/configs","PATHS_LOGS_DIR":"/var/log/unraid-api","PATHS_LOGS_FILE":"/var/log/graphql-api.log","PM2_HOME":"/root/.pm2","PM2_PATH":"/usr/local/unraid-api/node_modules/pm2/bin/pm2","PORT":"/var/run/unraid-api.sock","SUPPRESS_LOGS":false,"environment":{"IS_MAIN_PROCESS":true}} {"apiVersion":"4.14.0+26aeca3"} [01:00:33.615] INFO: PATHS {"core":"/usr/local/unraid-api/dist/assets","unraid-api-base":"/usr/local/unraid-api/","unraid-data":"/boot/config/plugins/dynamix.my.servers/data","docker-autostart":"/var/lib/docker/unraid-autostart","docker-socket":"/var/run/docker.sock","rclone-socket":"/var/run/rclone.socket","parity-checks":"/boot/config/parity-checks.log","htpasswd":"/etc/nginx/htpasswd","emhttpd-socket":"/var/run/emhttpd.socket","states":"/usr/local/emhttp/state","dynamix-base":"/boot/config/plugins/dynamix","dynamix-config":["/usr/local/emhttp/plugins/dynamix/default.cfg","/boot/config/plugins/dynamix/dynamix.cfg"],"myservers-base":"/boot/config/plugins/dynamix.my.servers/","myservers-config":"/boot/config/plugins/dynamix.my.servers/myservers.cfg","myservers-config-states":"/usr/local/emhttp/state/myservers.cfg","myservers-keepalive":"/boot/config/plugins/dynamix.my.servers/fb_keepalive","keyfile-base":"/boot/config","machine-id":"/var/lib/dbus/machine-id","log-base":"/var/log/unraid-api","unraid-log-base":"/var/log","var-run":"/var/run","auth-sessions":"/var/lib/php","auth-keys":"/boot/config/plugins/dynamix.my.servers/keys","passwd":"/boot/config/passwd","libvirt-pid":"/var/run/libvirt/libvirtd.pid","activationBase":"/boot/config/activation","webGuiBase":"/usr/local/emhttp/webGui","identConfig":"/boot/config/ident.cfg","activation":{"assets":"/boot/config/activation/assets","logo":"/boot/config/activation/assets/logo.svg","caseModel":"/boot/config/activation/assets/case-model.png","banner":"/boot/config/activation/assets/banner.png"},"boot":{"caseModel":"/boot/config/plugins/dynamix/case-model.png","caseModelConfig":"/boot/config/plugins/dynamix/case-model.cfg"},"webgui":{"imagesBase":"/usr/local/emhttp/webGui/images","logo":{"fullPath":"/usr/local/emhttp/webGui/images/UN-logotype-gradient.svg","assetPath":"/webGui/images/UN-logotype-gradient.svg"},"caseModel":{"fullPath":"/usr/local/emhttp/webGui/images/case-model.png","assetPath":"/webGui/images/case-model.png"},"banner":{"fullPath":"/usr/local/emhttp/webGui/images/banner.png","assetPath":"/webGui/images/banner.png"}}} {"apiVersion":"4.14.0+26aeca3"} [01:00:34.331] INFO: Starting Nest Server on Port / Path: /var/run/unraid-api.sock {"apiVersion":"4.14.0+26aeca3","logger":"api"}
-
[Plugin] FolderView2
About the autostart feature, I think it might be related to a race condition on the unraid-autostart config file. I have a more detailed bug report here: https://forums.unraid.net/bug-reports/stable-releases/unraid-autostart-file-edit-race-condition-r3964/ Apparently unraid guys don't want to implement a lock on their side, so folder view plugin maybe need to add a little delay in between the underlying toggling commands instead of executing them all at once. One workaround right now is to expand the folder and manually click on unraid's native autostart toggles.
-
SteveHawk started following unraid-autostart file edit race condition
-
unraid-autostart file edit race condition
When toggling autostart options at docker page, changes are saved to /var/lib/docker/unraid-autostart. However, if multiple switches are toggled at the same time, for example toggling the autostart switch of a folder created by folderview plugin, the unraid-autostart file appears to be edited at the same time, leaving it in a somewhat broken state. For example I have a unraid-autostart file like this in the first place: (I think it's already kind of broken, nginx-proxy-manager only has a "manager" here) Manager cloudflared FileBrowser homepageafter toggling off autostart at the same time, here's what the file looks like: Manager er FileBrowser homepageafter several toggles, it looks like this: Manager er erSo we most likely have a race condition here. Maybe consider adding a lock to the file edits?
-
Persist node package download
Hi, in the last two version of unraid connect (2025.03.18.1557, 2025.03.18.2027), I noticed that during installation, a node package is downloaded to the flash drive, installed, then deleted from the flash drive. This also happens during boot, but because I have set up an outgoing proxy, and that proxy server is in a docker container on this unraid server, it means plugins do not have an internet connection available before array startup. This causes the node package failing to download, and unraid connect plugin failing to install during boot. Here's the relevant boot log: Mar 19 17:14:55 Tower plugin-manager: running: 'anonymous' Mar 19 17:14:55 Tower plugin-manager: running: 'anonymous' Mar 19 17:14:55 Tower plugin-manager: creating: /boot/config/plugins/dynamix.my.servers/node-v22.14.0-linux-x64.tar.xz - downloading from URL https://nodejs.org/download/release/v22.14.0/node-v22.14.0-linux-x64.tar.xz Mar 19 17:14:58 Tower rc.local: plugin: installing: dynamix.unraid.net.plg Mar 19 17:14:58 Tower rc.local: Executing hook script: pre_plugin_checks Mar 19 17:14:58 Tower rc.local: Installing dynamix.unraid.net.plg 2025.03.18.2027 Mar 19 17:14:58 Tower rc.local: Checking disk space on /usr... ok. (14635MB free) Mar 19 17:14:58 Tower rc.local: Checking DNS... Mar 19 17:14:58 Tower rc.local: ⚠️ Do not close this window yet Mar 19 17:14:58 Tower rc.local: plugin: downloading: node-v22.14.0-linux-x64.tar.xz ...#015plugin: node-v22.14.0-linux-x64.tar.xz download failure: Network failure Mar 19 17:14:58 Tower rc.local: Executing hook script: post_plugin_checks A workaround is to manually download the node package and place it under /boot/config/plugins/dynamix.my.servers/ prior to reboot, then plugin-manager will be like: Mar 19 17:36:44 Tower plugin-manager: checking: /boot/config/plugins/dynamix.my.servers/node-v22.14.0-linux-x64.tar.xz - SHA256 Mar 19 17:36:45 Tower plugin-manager: skipping: /boot/config/plugins/dynamix.my.servers/node-v22.14.0-linux-x64.tar.xz already exists and proceed to success installation. But it's annoying needing to download this manually every time the server needs a reboot, and it seems unnecessary to download the same package every time (which also increases the wear on the flash), so maybe please consider persisting this node package download on the flash drive?
-
Question about notification settings
Thanks a lot! Looking forward to the update. Annnd just to check, is this the intended behavior of the notification settings? If so, I would like to suggest updating the help text of these settings, as they are sort of ambiguous at the moment. For example, I think it would be really helpful to mention that "Notification entity" is for controlling notifications OTHER THAN the five ones above in "Available notifications", so that we would know these two areas are independent. Would you please also consider this? Thanks!
-
Question about notification settings
Thanks for your reply. Your idea sounds quite reasonable, but here's the part that doesn't line up: As shown above, I have enabled both `Docker update` and `Array status` email notifications, but only array status notification is sent to my inbox, not docker update. Here's my diagnostics file: [redacted] Hope it can help troubleshooting. Thanks!
-
Question about notification settings
And here's the notification I received, notice that docker version update notification is only sent to ntfy, but array status notification is sent to both email and ntfy:
SteveHawk
Members
-
Joined
-
Last visited