johner

Hi, I was dipping the toes into this as I didn't want to open people up to security risks by rushing in, I think this would be useful. I have a few defects to fix, I'll then focus on this idea - thank you!

Hi, I performed a fresh install on Unraid 7.3.2 from the app store, tested claude and codex, chrome and safari (both mac), all seems ok. Let me know if you were able to get more diagnostics. Thanks John

> Thanks > > ENOENT: no such file or directory, mkdir > /tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin > > The current launcher already creates the required parent cache directory before OpenCode starts, so this is unlikely to be a simple missing-directory fix. It suggests either a timing race, a managed-home remount/sync occurring during launch, or an older launcher generation still being used. > > Before trying again, could you please provide: > > 1. The exact plugin and OpenCode versions. > 2. Whether both workspaces use OpenCode, and whether they use different workspace folders. > 3. Your configured agent-home/storage location — default, USB, pool, array, or Unassigned Device. > 4. Whether a backup, home consolidation, plugin upgrade, or storage-location change was happening around the same time. > 5. The relevant timestamp and debug-log lines covering the first workspace launch and the failed second launch. > 6. Whether pressing Enter to retry succeeds after the first workspace is closed. > > Please avoid repeatedly retrying if the server becomes unstable. The report that the host became unreachable after moving storage off USB is being treated as a separate host-stability concern

> Thanks for reporting this > > The confirmed problems are: > > - the Relay listener can survive an upgrade while still running old plugin code; > - Relay currently enables its external listener/key path too eagerly; > - workspace browsing can perform large directory scans through /mnt/user; (which can expose the Unraid shfs fuser hang issue I can't work around on Array style shares) > - agent workspaces also default to /mnt/user, which can put heavy filesystem pressure on Unraid’s user-share layer. > > Those last two are plausible contributors to the host becoming unreachable, although I cannot prove that from the report alone. I am treating them as high-priority stability work. > > To identify the remaining reports, could you please provide: > > 1. Plugin version, Unraid version, browser and browser version. > 2. For onboarding or JavaScript failures: the first browser Dev Tools Console error/stack and any failed Network request. > 3. For the terminal issue: which terminal is affected — the normal Unraid top-bar terminal, the AICliAgents terminal, or creating a new workspace — plus a screenshot/error and whether it works from the Dashboard in the same browser session. > > 4. If the server becomes unreachable again, please do not deliberately repeat it. After recovery, send the approximate time, Unraid Diagnostics, and /boot/logs/syslog-previous if available. > > That will let me separate browser/UI failures from the host-level filesystem issue and add targeted regression coverage

so a couple things, worth noting, if your Unraid host still boots off USB, the default settings are to install both the home and agents to a path on the USB, so any activity to bulk writ will be slow, such as agent upgrades, on home area consolidation. You can move these else where, ideally not on the array if you want it to function with the array offline - try an unassigned drive (see that plugin). I have added more onine feedback of status updates on home/agent activity (better progress tracking), that'll be available once I finish testing this new version. Also, I noticed agents that perform certain hard hitting commands against the \mnt\user paths it can block Unraids merged file system, this is a limitation of Unraid's fs as I understand it, abd so far I have a rule/memory line to tell the agent to use the underlying paths, such as \mnt\cache, or to be less aggressive with the find, grep etc. I might need some further context from you both, but let me see if claude can find anything suspicious in the code given the commentary. Thanks for being patient!

thanks for reporting, would you mind testing in the latest version please?

Hey @Squid , Would you mind checking out this plugin to see if it meets the criteria for the app store please?

I've updated the link, would you mind trying again please?

Sorry, didn’t get the diagnostics, and yes at one point I got it to group a ton of containers it was managing. It was a mix of auto and manual config.

only if you're still having issues with the new version, else skip it.

Hi, I have created a new plugin to allow you to see all the connections to your unraid servers: https://github.com/johnpwhite/unraid-plg-connections It's not yet available in the CA App Store, in the mean time, you may install it manually with this link: https://github.com/johnpwhite/unraid-plg-connections/raw/main/unraid-connections.plg It's been coded with Claude and uses my framework for testing and deployment so is reasonably robust. Shout if any issues. You can find it under Tools > Unraid OS > Connected Clients Screen shot (mac addresses redacted) Let me know your thoughts and asks! Thanks John

Hi, I had an issue, this is what my bot figured out. Thx! Bug: a folder whose id is not pure base64 can never be deleted — and trying freezes the pagePlugin: Folder View 3 (folder.view3) 2026.08.28 Symptom: duplicate folders the UI refuses to remove, and a page that freezes behind a spinner when you try to delete one. What I sawThree folders named "LLM infra" on the Docker page. Two were empty and would not delete. The config held these keys: grp_llm_infra LLM infra containers=[] <- stuck 5xJlQxP162Ql9LjIXLs LLM infra containers=[llamacpp,ollama,LiteLLM,litellm-db] <- the real one yqzdeavmb0bCdsOQ3A LLM infra containers=[] Root causegenerateId() mints ids from base64 with +, / and = stripped, so a folder id the plugin creates is always [A-Za-z0-9]{1,20}: // server/lib.php:1547 function generateId(int $length = 20) : string { return substr(str_replace(['+', '/', '='], '', base64_encode(random_bytes(...))), 0, $length); } But three code paths validate ids against the full base64 alphabet, which allows the three characters generateId() removes and forbids everything else — including _ and -: // server/delete.php:6 if (empty($id) || !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; } // server/update.php:6 if (!empty($id) && !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; } // server/lib.php:785 (updateFolderIds) if (!preg_match('/^[A-Za-z0-9+\/=]+$/', $folderId)) continue; So a folder keyed grp_llm_infra is unreachable by the plugin's own UI: Delete → HTTP 400, nothing happens. Edit / save settings → HTTP 400, nothing happens. Container membership → silently skipped, so the folder can never stop being empty. This is why the stuck folder showed containers: [] while its containerImages still named the containers someone had put in it. It is a permanent, self-inflicted orphan: the one operation that would clear it is the one operation its id forbids. The worse knock-on: deleting one of these freezes the pageThree of the four delete entry points await the POST with no rejection handling, after showing a full-screen spinner overlay: // scripts/shared.js:700 — fv3RmFolder, used by the Docker tab (docker.js:801) // and the VMs tab (vm.js:471) // scripts/dashboard.js:816 — rmDockerFolder, used by the Dashboard (dashboard.js:1074) $('div.spinner.fixed').show('slow'); await $.post('/plugins/folder.view3/server/delete.php', { type: type, id: id }).promise(); setTimeout(loadlist, 500); The 400 rejects the promise, the await throws, and nothing catches it. So: loadlist is never scheduled, the swal stays open with showLoaderOnConfirm: true — buttons disabled, spinner running, and div.spinner.fixed, shown one line earlier, is never hidden. The result is a full-screen overlay plus a locked modal with no way out but a page reload. It reads as "the browser hung when I deleted that folder". The page is not busy — it is covered by two spinners that nothing will ever dismiss. Only scripts/folderview3.js:240 (the Folder View settings page) wraps the POST in try/catch, and that one correctly reports "Failed to delete folder: Bad Request". So whether this bug is a readable error or a frozen page depends purely on which of the four screens you happened to delete from — and the three that freeze are the three people actually use. This is the fix worth taking first, independently of the id validation: every one of these callers needs the try/catch that folderview3.js already has, hiding the spinner in a finally. Then even an unexpected server error leaves a usable page. The knock-on: "Remove ALL folders" deletes nothingscripts/folderview3.js:276 loops every id inside a single try: for (const cid of Object.keys(dockers)) { await $.post('/plugins/folder.view3/server/delete.php', { type: 'docker', id: cid }).promise(); } The first 400 rejects the promise, the loop aborts, and the catch shows a generic "Failed to clear all folders". Object keys are in insertion order, so if the unreachable folder is early — mine was first — a bulk clear removes nothing at all and gives no clue why. That is what makes this look like "the folders cannot be deleted" rather than "one id is bad". Suggested fixWiden the three validators to cover any key that can legitimately be in the file, while still rejecting nothing the plugin needs to reject (the id is a JSON key, never a path): if (!preg_match('#^[A-Za-z0-9+/=_-]{1,128}$#', $id)) { ... } Then three behaviour fixes, the first of which matters most — it makes every failure readable instead of fatal to the page: Handle the rejection in every delete caller (shared.js:700, dashboard.js:816), the way folderview3.js:240 already does, and hide div.spinner.fixed in a finally. This one turns a frozen page into a readable error, whatever the server says. Never let a delete be refused for the id's shape. Deleting is the escape hatch. If any validation must stay, delete should be the one path that always accepts an existing key. Do not abort the bulk clear on one failure. Collect the failures, delete the rest, and report which ids were refused — the current generic error hides the single bad key. ReproAdd a folder to /boot/config/plugins/folder.view3/docker.json under a key containing _ or - (a UUID key does it, which is what automation tends to write). Reload the Docker page. The folder appears. Delete it from the Docker tab, the VMs tab or the Dashboard → the page freezes behind a spinner that never clears (400 in the network tab). Only a reload recovers it. Delete it from the Folder View settings page instead → a readable "Bad Request" error. Try "Remove ALL folders" → nothing is deleted at all, generic error. Workaround until it is fixedEdit /boot/config/plugins/folder.view3/docker.json by hand — back it up first, stop at a valid JSON object, and re-key the folder rather than deleting it, so its settings and membership survive: "grp_llm_infra": { ... } → "VHlVa0Cw7yvX13LPgDVe": { ... } Any key of 20 or fewer letters and digits works. Reload the Docker page and the folder behaves normally again. Note for anyone scripting this fileIf you register folders from a script, mint the key as [A-Za-z0-9]{1,20}. A UUID looks like the safe choice and is exactly the one that gets stuck.

Thanks for the report and the log. I don't have beta running yet, I'll likely give it a couple more releases as I can't risk breaking my dev box. I'll see if i can spin it up on a trial in a VM at somepoint. I, well mainly Claude(!) looked at what changed in 7.4.0-beta.1. The kernel moved from 6.18.38 to 6.18.44 and zramctl is the same util-linux 2.42.2. It found no ZRAM-related change, so I do not think 7.4 broke ZRAM. A flat graph right after an upgrade is usually normal. The upgrade rebooted the server. A reboot empties the ZRAM device and the plugin's graph history. Nothing lands in ZRAM until the kernel is under memory pressure, even with swappiness at 150. The real problem was on my side. The plugin wrote the same "0MB" line whether ZRAM was idle, missing, or broken, so your log could not tell us which one it was. Version 2026.09.06.01 fixes that. It also fixes a separate bug where the dashboard could show 0 bytes used for a busy device. Could you do this for me: 1. Update the plugin. Go to Plugins, click Check for Updates, and update ZRAM Compressed Memory to 2026.09.06.01. 2. Open a terminal on the server and run these two commands. The script is read-only. It changes no settings. wget -qO /tmp/zram-diag.sh https://forgejo.johnpwhite.com/unraid/unraid-plg-zram/raw/branch/master/tests/beta-diagnostics.sh bash /tmp/zram-diag.sh 3. Wait about five minutes and run bash /tmp/zram-diag.sh once more. 4. Paste the complete output of both runs here, and tell me whether the Dashboard tile shows a ZRAM row with a non-zero Size. The output includes your kernel and Unraid version, the plugin version, the raw zramctl and swap state, what the dashboard reads, and the plugin's last diagnostic lines. A line that says status=healthy_idle with a non-zero disksize means ZRAM is fine and simply has nothing to store yet. The graph will move once the server needs swap. A line that says missing_device, inactive_device, or zramctl_command_failure is a real fault, and the output will show me exactly where to look.

Ok great, maybe github had a brainfart? i uninstalled and reinstalled - all fine to. Let me know if it happens again, maybe I can add some better logging

Thx again for the analysis! fixed and released.