mccray

I’m not sure yet how to get it added to the official repository. I’ve already published a plugin support thread, and I probably need to look into the official submission process next.

I’d also like to isolate whether the CPU spike is caused by this Storage GraphQL query itself, or by some other app-side behavior. If you’re willing, could you try one “cold query” test? Before testing, please make sure the Storage tab in the app has not been opened for about 30 minutes. Also avoid manually running the Storage GraphQL curl query during that same period. While on your local LAN, run the curl command directly against the internal LAN IP. While the curl command is running, keep the Unraid WebUI Dashboard open and watch the CPU usage. Please check whether one or two CPU cores spike to 100%, similar to what you saw when opening the Storage tab in the app. Even if curl returns quickly, please keep watching CPU usage for another 1-2 minutes to see whether it stays elevated. The goal is to separate two cases: If the manual curl query also causes the CPU spike, then the issue is likely inside the Unraid API’s storage/share/device enumeration path. If the manual curl query does not cause the CPU spike, but the app still does, then I’ll focus more on app-side behavior such as extra requests, retries, connection routing, or request cancellation.

Thanks, this is very helpful. One thing I’d like to confirm about the last result: was the LAN test HTTP 200 total=0.022652s) run immediately after the first two timed-out requests? I’m asking because once Unraid has already completed or partially warmed up the storage query, a second request can be much faster. I just want to make sure I’m reading the timing correctly. On the app side, I’m going to review the Storage tab query path again and make whatever optimizations I can safely cover. I don’t personally have a setup with that many devices and shares, so it’s difficult for me to reproduce this exact case locally. Would you be open to joining a TestFlight build to help verify targeted fixes? If so, please send me the email address you’d like to use for the invite. I’ll make some focused changes around the Storage tab and would really appreciate being able to validate them against your setup.

Thanks, that helps. One more useful detail: roughly how many storage devices do you have attached? For example: number of ZFS pool devices, cache/pool devices, unassigned devices, and user shares. The Storage tab currently asks the Unraid GraphQL API for array/storage, user shares, and physical disks in one request. Since you mentioned it can take 30-60 seconds before shares and unassigned devices appear, I’d like to check whether the delay is coming from the Unraid API response itself. If you’re comfortable running a local test on your Unraid server, could you try this from a machine that can reach your Unraid server? Please do not share your API key. I only need the timing result and maybe the count of returned disks/shares. UNRAID_URL="https://YOUR_UNRAID_HOST:PORT/graphql" API_KEY="YOUR_API_KEY" curl -sS -o storage-response.json \ -w "\nHTTP %{http_code} total=%{time_total}s\n" \ "$UNRAID_URL" \ -H "content-type: application/json" \ -H "x-api-key: $API_KEY" \ --data '{"query":"query GetStorageData { array { state capacity { kilobytes { total used free } } parityCheckStatus { status progress speed duration date correcting paused running } parities { id name device status temp size type numReads numWrites numErrors isSpinning fsType color } disks { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } caches { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } boot { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } } shares { id name comment used free size cache color include exclude allocator splitLevel } disks { id name device serialNum size temperature isSpinning type smartStatus } }"}'If you’re using HTTPS with a self-signed certificate, add -k to the curl command temporarily. UNRAID_URL="https://YOUR_UNRAID_HOST:PORT/graphql" API_KEY="YOUR_API_KEY" curl -k -sS -o storage-response.json \ -w "\nHTTP %{http_code} total=%{time_total}s\n" \ "$UNRAID_URL" \ -H "content-type: application/json" \ -H "x-api-key: $API_KEY" \ --data '{"query":"query GetStorageData { array { state capacity { kilobytes { total used free } } parityCheckStatus { status progress speed duration date correcting paused running } parities { id name device status temp size type numReads numWrites numErrors isSpinning fsType color } disks { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } caches { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } boot { id name device status temp size fsSize fsUsed type numReads numWrites numErrors isSpinning fsType color transport rotational } } shares { id name comment used free size cache color include exclude allocator splitLevel } disks { id name device serialNum size temperature isSpinning type smartStatus } }"}' If the curl request also takes 30-60 seconds, the slowdown is likely in the Unraid API/storage enumeration path rather than the app UI. If curl returns quickly but the app still stalls, that points me back to app-side parsing/rendering and I’ll investigate that path. For the crash itself: I found a few issues while investigating and have made some adjustments. will be included in the next app update.

Thanks for trying it out, and thanks for the report! Could you help me understand how to reproduce the crash? For example: - Which page were you opening when it happened? Shares or Storage? - Does it hang immediately after entering that page, or only after tapping something? - Does it happen every time? - Which version of the app are you using? - If possible, could you share a screenshot or short screen recording of the steps before it crashes? Also, just to clarify: pool display is not supported at the moment, so ZFS pools may not show up in the app yet. That should be separate from the crash though — the app should not hang or crash, and I’ll look into adding a proper fallback once I can reproduce it.

Unraid Deck Notification Agent is a simple Unraid notification agent plugin for the Unraid Deck iOS app. It forwards Unraid system alerts and notices directly to your iPhone. The plugin converts Unraid events into a JSON payload and sends it securely via the Unraid Deck push relay. It integrates directly with Unraid's built-in notification system: Settings -> Notifications -> Agents Features Native Integration: Works directly in Unraid's Settings -> Notifications -> Agents. Zero Dependencies: Pure Bash script, no Python or other heavy dependencies required. Privacy First: Direct pass-through of notifications; no data is logged or tracked by our servers. Manual Installation: Open your Unraid Web UI and go to: Plugins -> Install Plugin Paste the following URL: https://raw.githubusercontent.com/mccray-s/unraid-deck-agent/main/UnraidDeck.plg Repository: https://github.com/mccray-s/unraid-deck-agent Support: Please include your Unraid version, plugin version, and a brief description of the issue when reporting problems.

Hi there, First off, what version of Unraid are you currently running? That specific message is a GraphQL API query error. To be completely honest, I'm not exactly sure what triggered it on your end yet, but I'm glad it resolved itself after a while. Regarding the missing server controls, you aren't doing anything wrong. Right now, a full "server reboot" is explicitly something that cannot be done via the API. As for other array and server functions, I am still exploring the API capabilities and actively iterating on the app. Up until now, my development focus has primarily been on getting Docker and VM management dialed in. I will keep exploring and adding more server-level controls in future updates!

Hey everyone, I’ve been working on adapting Unraid Deck to the Docker API changes introduced in Unraid 7.3.0 Beta-1, and the main compatibility work is now basically done. The app now fully supports the new Docker API features added in the 7.3 beta, while still maintaining backward compatibility with older Unraid versions. Here’s what’s been completed so far: 1. Native Docker Logs in the App You can now view container logs directly inside the app through the new API, so there’s no longer a need to create symlinks manually from the terminal like before. One thing I’ve noticed is that the current API implementation still seems a little inconsistent in some cases, and the log output may not always match the Unraid WebUI exactly. I’ll keep watching this as Unraid continues refining the API. 2. Container Update and Batch Actions Support has also been added for updating individual containers directly from the app. On top of that, batch actions are now available for Docker containers, including: Batch Update Batch Pause Batch Resume This makes it a lot easier to manage multiple containers from your phone without having to switch back to the WebUI. 3. Better Docker Query PerformanceAnother big improvement in the new API is support for querying a single container directly. This makes Docker-related requests much more efficient on the app side, especially when loading container details. For users running a larger number of containers, the difference should be pretty noticeable in day-to-day use. At this point, most of the major Docker API changes introduced in the 7.3 beta have already been handled in Unraid Deck. Development is wrapping up now, and if everything goes smoothly, I’m planning to push the update sometime next week. If you’re already running the 7.3 beta, keep an eye out for the next release. And as always, if you have suggestions or feedback, feel free to leave a review on the App Store. I do read them, and they genuinely help me improve the app. Thanks for the support, and happy self-hosting. Download Link: Unraid Deck Official Site: unraid.mccray.app

Hi, First of all, thank you so much for the kind words about the app! I really appreciate it. I completely understand your caution. Handing over credentials to your home server is a big deal, and it's smart to be careful. To be completely transparent: I do not have plans to make the app open-source. As an independent developer, my goal is to generate some income from this project to justify the countless hours I put into it and to sustain my passion for continuous development and updates. Keeping it closed-source is a necessary part of that model. That being said, I want to give you absolute peace of mind regarding your data: 100% Direct Connection: The app communicates directly from your device to your Unraid server. There is no middleman, no proxy, and no telemetry on my end. Local Storage Only: Your credentials are saved securely and exclusively in your device's native Apple Keychain. I have zero access to them. Verify it yourself: I highly encourage you to use network monitoring tools (like Pi-hole, AdGuard, or a packet sniffer). You will see that the app only ever makes requests to the exact IP/hostname you enter. I know closed-source might still be a dealbreaker for some, and I totally respect that. But I hope this helps explain my position and alleviates your security concerns! Thanks again for reaching out.

Hi, Thank you for the great feedback and support! For Docker/Plugin updates: Unfortunately, Unraid currently lacks an official API to trigger these updates. I'll definitely add it once Unraid supports it officially. In the meantime, I'm considering adding a lightweight Terminal (SSH) feature to the app, which might solve some of these maintenance needs, though it will require SSH permissions. For the File Explorer: I've been considering adding SMB file management! My only concern is that it requires users to set up extra credentials and permissions. However, I prefer to prioritize my roadmap based on real user feedback—so knowing that this is something you'd find highly valuable is incredibly helpful. I'll start looking into how to implement this smoothly. Thanks again for helping me improve the app!

The default port for HTTPS should be 443.

Whether HTTPS is enabled depends on your Unraid settings. In your Unraid menu, go to Settings -> Management Access -> Use SSL/TLS. If it's set to "Strict," try changing it to "Yes" or "No." Also, if you choose "Yes," remember to enable insecure connections.

I'm using Tailscale for the connection. Have you enabled HTTPS? Perhaps you should check the advanced settings in ServerConfig?

It seems you're a little late.

Glad to hear that you like it. Please feel free to share any feedback with me anytime—your input is very important, and I'm always ready to make improvements.