SakabaRihiro

Found a fun little UI bug. \ Turns out I wasn't saying 'Yes' to updating the container after backup, I was saying 'Yes' to saving external volumes, which is 20TB of media. Cache filled and server crashed. Might also be a good idea to have the option to save the log files to a location other than /tmp as since this stores in RAM, they are lost on a reboot.

Yeah, it's a minor bug and only affects old versions, but thought you might want to know. Unlikely many people would be affected by it, most users that are will probably migrate from the original FolderView to this fork in another 3 years 🤣

Minor visual bug: Buttons cut off when using the plugin in Unraid 7.1.4 Updating to Unraid 7.2.4 fixes this.

Apologies, I was mistaken. I set some containers to auto-start, then I installed the plugin. I was using Unraid 7.1.4 with FolderView2, then installed FolderView3 and updated to Unraid 7.2.4, and noticed the inaccuracies in NZB360 with the auto-start labelling (example screenshots attached). Upon further checking (which I should have done before my previous post), this is the case even without FolderView3 installed, even after toggling auto-start on and off with FolderView3 uninstalled and clearing NZB360 cache. For the containers that show in NZB360 as autostart being enabled, disabling autostart and refreshing NZB360 results in the container showing as autostart disabled (correctly), but then toggling autostart back on still results in autostart being shown as disabled. The bug lies with either NZB360 (most likely) or the Unraid API, not with this plugin. Thanks for your work on this plugin. Do you plan to maintain it long term? Also just wondering if you're familiar with coding, or relying on the Claude output and reading over the output, but unsure of how to write the code independently. AI is a tool, and some people speak overly highly of it and other speak overly negatively, but when used appropriately I don't see an issue with it; I doubt you'd cause a Huntarr level situation 🤣.

Thanks for this! Held off on 7.2 until I could use FolderView. Glad to see toggling autostart now actually works consistently, a very nice change! It doesn't appear to be reflecting the autostart state via the Unraid API however. I have set most of my containers to autostart, but when I use NZB360 and look at my containers, most have 'A' greyed out and say autostart is disabled. Is this something you'd be able to fix without too much effort?

Hey @homeRAID Sorry to say I never got to the bottom of it. The hardware and setup was for a friend who I was assisting, as it's their first NAS. They're now using the machine at their home, so I don't have direct access to the machine any more. In the end, they decided using the system as both a NAS and as a VM so they didn't require a separate PC for general usage wouldn't be a good fit for them as we couldn't find how to make it consistently boot the VM successfully, so they bought a separate machine for general usage. If you do ever get to the bottom of it, please let me know.

Only odd starts worked for me, even ones would pummel the lowest core at 100%. Check if it's the same for you, if it is, kill the VM on an odd start then start it again and it should work without requiring the host system to be restarted. Issue noted by me in my comment in April.

Thanks, any idea what caused the bug? Checked my friends server, and it's happening for them as well (also on 2025.06.07 using the same cron schedule), but not my backup server with 2025.05.23.

Apologies, I phrased that poorly. What I meant to ask is if moving on a schedule works for anyone who has 'force move cron schedule' enabled. I know that the force move should run mover.old, but having the force move on a cron schedule enabled is what causes age_mover to fail for me.

Tried starting up a small set of docker containers, the system died again. Tried with another set instead, system died. Tried with another and the system again died. Then tried with some others, system was stable. Started others, system was stable. Eventually re-enabled all containers, system has been up for a couple of weeks now without issues. I have no idea what the cause was, I changed nothing.

Just so you know it's not an isolated case, I have the same issue when I have the following set: Logs show: This impacted standard hourly moves and the 'Move Now' button. I have mover tuning set to run hourly, but runs weren't occurring. /tmp/ca.mover.tuning has no new logs since June 10, there were no changes to my setup other than updating to 2025.06.07, no changes to my mover tuning settings have happened in a month or so until now due to noticing this issue. Disabling force moving on a schedule allows the non-forced hourly moves to occur. Does the force move cron schedule allow standard moving to work for anyone on 2025.06.07?

My apologies, since you stated I thought you didn't want to republish the plugins since you don't have capacity to take on maintenance, and was responding to the comment hoping you would be able to add them back. I wasn't aware you had changed your mind regarding republishing them. No offence was intended.

I had other issues using Docker images, such as containers sometimes failing to start up, sometimes even databases would crash while open, resulting in corruption. Had to restore a container from a backup 3 days in a row once. This hasn't happened since I moved to a directory, so I don't trust the stability of Docker images. Are you aware of anyone having the same issue I am due to a Docker directory? I don't want to risk having my containers becoming corrupted at random again if I can avoid it, I'll seriously consider changing OS if that's the only option. I'll try recreating the Docker directory for now and try to identify the culprit, if it is caused by a specific container starting. The slowdowns don't occur as soon as the containers are spun up though. Any advice for trying to find the needle in the haystack?

Hi, a strange issue started for me a couple of days ago. The Docker daemon has started eating all the system memory, which brings the system to a complete crawl, to the point a shutdown takes 3+ hours and I can't ssh into the server. I have 32GB and usually only about 10GB will be used. None of the containers seem to be using the RAM, it's the Docker daemon itself. Last night I destroyed my Docker directory (/mnt/user/system). I use a directory instead of image, as I have about 70 containers, so prefer not to have a fixed size. Last time this occurred about a year ago, it was due to a corrupt Docker image caused by a hard crash from the Realtek driver plugin, and recreating the Docker image resolved the issue. When re-installing the containers this time, the issue started again. No particular container stands out for high memory usage. Here's some screenshots I took a few minutes ago from Glances, which is still refreshing every now and then since it was already open. I was able to stop the Docker daemon and the system returned to normal: root@Field:~# /etc/rc.d/rc.docker stop rc.docker: Stopping containers... rc.docker: Unraid managed containers stopped. rc.docker: Stopping network... rc.docker: Network stopped. rc.docker: Stopping Docker daemon... Waiting 30 seconds for Docker daemon to die.field-diagnostics-20250514-1931.zip rc.docker: Docker daemon... Stopped. As soon as it showed "rc.docker: Docker daemon... Stopped." in my ssh session, I heard the fans spin down and the system became responsive, allowing me to get the diagnostics report that was run while the system was slowed down.

Republishing would be a simple matter, but if nobody has capacity to maintain the plugins they will slowly die, especially if there's an incompatibility with a future Unraid version.