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.

If 'sideloading', will it auto-update when added to Community Apps, or is it best to wait until it's added for now?

Thanks to all the information in this thread along with trial and error, I got this working on an Aoostar WTR Pro with a Ryzen 7 5825u. No AMD reset bug. @Dmytro Piddubnyi did you ever find the cause of the failed starts with the CPU core at 100%? Happening to me as well, always occurs on 'even' starts of the VM, but 'odd' starts work with no issue. 1. Create your Windows 11 VM: Choose "Q35-9.1" or later for the machine Use a virtual display adapter to connect with VNC 2. Boot the VM: When prompted to connect to the internet, press shift + F10 and enter OOBE\BYPASSNRO in the cmd window Install NoMachine Server, so you can connect to the machine later and set up the GPU drivers, as changing display to the GPU passthrough will disable VNC but needs to be done so the iGPU drivers can be installed. Install virtio-win-guest-tools.exe Run windows updates and restart 3. Get the AMD Vendor Reset Plugin (This allows the iGPU to be re-initialized for passthrough) 4. Then in Tools > System Devices, search for your iGPU and audio device (AMD/ATI) and tick the checkboxes. After, click "Bind selected to VFIO at boot" 5. Edit /boot/syslinux/syslinux.cfg to add "append initrd=/bzroot earlymodules=vfio-pci video=efifb:off,vesafb:off gfxpayload=text" to disable Unraid using the GPU 6. Reboot Unraid 7. Edit your VM: For the graphics card, select AMD Barcelo, multifunction On and for the vBIOS, use vbios_5825U.bin from https://github.com/isc30/ryzen-gpu-passthrough-proxmox For the sound card, select AMD Renoir Radeon HD Audio Controller Pass through the audio jack (C-Media Electronics Audio Adapter (Unitek Y-247A) (0d8c:0014)) NOTE: Do not pass through any USB controllers, this will either hard crash or reboot Unraid itself. Save the VM config Re-enter the VM config, change to xml mode and edit the xml for the audio to have "<rom file='/mnt/user/domains/Windows 11/AMDGopDriver-5825U.rom'/>" from https://github.com/isc30/ryzen-gpu-passthrough-proxmox after '</source>' for the audio controller (<address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/>) 8. Start the VM and install the offline AMD graphics drivers (online will fail to install, won't recognise the iGPU) from https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-5000-series/amd-ryzen-7-5825u.html Notes: When running the Windows VM, on even runs (2nd, 4th etc) it will fail to run and pummel the lowest allocated CPU core at 100%. If this occurs, force stop the vm, then start it again and it will run. As the USB controller cannot be handed over to the VM, only the USB ports themselves can be handed over. This means that devices connected to a USB port may occasionally fail to connect to the VM. If this happens, try another port. If it still doesn't work, restart the VM.

Fixed my issue below by changing to 1.29.1 per https://community.n8n.io/t/not-able-to-login-to-either-docker-or-npm-version-of-n8n-via-local-network/42120/2 Might work for you as well. Looks like there's a bug with the n8n docker that affects Unraid.

When I log into my container (been using it for a couple of years now, and did the migration a year ago when it was needed) I now receive the following screen (note I did the chown command noted above): Navigating to Settings presents the following error The personal page loads, and I tried to change my password but also get a 401.

I forwarded 5900 to 5901, connecting internal to the network from another machine. TightVNC Settings: Error: For Remote Ripple, I tried it on Windows as well. I wasn't sure whether it was an issue with a custom setting you have for the VNC server on the Docker containers, or whether it's an issue with Remote Ripple. Since RealVNC works I'm not too fussed.

No dice with TightVNC on my end with Windows. "Error in TightVNC Viewer: No security types supported. Server sent security types, but we do not support any of their." Remote Ripple is the successor to TightVNC, TightVNC is now just getting security and bug fixes. No settings for Remote Ripple are available other than IP and Port for connections, and for the application side, setting whether it should automatically check for updates. RealVNC does work though.

Connecting to the JDownloader VNC server (port 5900) with Remote Ripple works, but the connection lasts for less than a second then says "Disconnected". The docker logs don't say anything, and the Remote Ripple logs state the following: Is this something that can be fixed?

Is it possible to disable warnings due to outdated plugins and/or docker containers? I check these manually on a regular basis, but get alerts constantly when an update comes out 12 hours after the check. I'd prefer not to receive the warning, and instead just check manually later. Due to how often I get warnings due to this, I rarely check what the warning notification is for, as I assume it's due to a plugin or docker container, so if there's any actual issues I likely won't notice for quite a while due to thinking it's just something needing an update.

Is it possible to cancel a pending action? I've started a move for a share after changing the Share split level, but then notice some of the folders that will be moved are on the cache drive, which will move them to the desired location with the mover script anyway. Is it possible to cancel these pending moves before they are processed?

Thank you for all your work on the templates. For the Mango template in particular, I'd like to suggest the following changes to make installation a bit easier: Default value for the WebUI (9000, same as is used internally). For the /root/mango mapping: Map to /mnt/user/appdata/Mango/Appdata, as the db, plugins, cache etc are stored here and it is empty and mandatory by default Rename to 'Data', currently it is named 'Config', but this is a mistake, as the name Config is already used for another mapping Change description from 'Mangas' to 'Mango appdata' Change the description on the /root/.config/mango mapping to 'Mango config', as currently it is 'Mango appdata', but this description is inaccurate Add a mapping for the Manga library, possibly empty by default Add a variable mapping for 'library_path', for the Manga library mapping Thank you. Example of the changes