martinkeat

Feature Request: “Drain” and “Re-Include” Buttons Drain Button Add a checkbox column next to each pool device and array drive. Place a “Drain” button at the bottom of this new column. How It Works When one or more pools or drives are selected and “Drain” is clicked, Unraid identifies which pool(s) or drive(s) you want to clear. It checks which user shares use those pool(s) or drives as either Primary or Secondary storage. The Primary storage for those shares is changed to “Array,” and if it’s an array drive, that drive is excluded from all shares so only the remaining drives are used. The Secondary storage for those shares is set to “None.” Unraid moves all data from the selected pool(s) or drive(s) to the array, thereby emptying them—or, for an array drive, only transferring files to the other array drives. This streamlines the process of clearing a device by bundling all required share setting changes and data transfers into a single action. Re-Include Button Once a new or replacement drive has been properly cleared and formatted, a “Re-Include” button appears next to that drive. Clicking “Re-Include” adds it back to the array with a single click, automatically applying the same configuration and settings used by the other drives. By introducing these two buttons, Unraid would simplify drive maintenance, making it easier to remove and replace drives with minimal manual configuration.

We'll all have it at some point, the dreaded batch of docker containers which refuse to stop - when you tell them to - due to processes running in the background. I wrote a small script for when it happens to myself and thought I would put it up here. WHAT THE SCRIPT DOES This script is designed to handle situations where Docker containers are unresponsive and cannot be stopped using standard Docker commands. The script is particularly useful for recovering from Docker issues where containers remain in a running or hung state due to malfunctioning containerd-shim processes. It avoids data loss by not removing or deleting containers, focusing only on safely stopping them after resolving the shim process issue. Specifically, it: Identifies Running Containers: Uses docker ps -q to list all currently running container IDs. Locates Associated containerd-shim Processes: For each running container, the script searches for its corresponding containerd-shim process, which manages the container's lifecycle. Kills the containerd-shim Processes: If a containerd-shim process is found for a container, it is forcefully terminated using kill -9. Attempts to Stop Containers: After killing the associated containerd-shim, the script runs docker stop to cleanly stop the container. Logs Actions: Outputs messages to the terminal detailing which containers are being processed, the shim processes being terminated, and the success or failure of container stop attempts. Ensures All Containers Are Processed: Loops through all running containers and handles them one by one. THE SCRIPT: #!/bin/bash # Get list of running container IDs running_containers=$(docker ps -q) # Loop through each container ID for container_id in $running_containers; do echo "Processing container: $container_id" # Find the corresponding shim process for the container shim_pid=$(ps aux | grep "containerd-shim-runc-v2" | grep "$container_id" | awk '{print $2}') if [ -n "$shim_pid" ]; then echo "Killing shim process $shim_pid for container $container_id" kill -9 $shim_pid else echo "No shim process found for container $container_id" fi # Attempt to stop the container echo "Stopping container $container_id" docker stop $container_id || echo "Failed to stop container $container_id" done echo "All running containers processed." Instructions to Use the Script on Unraid: Open the Unraid Terminal: Click on "Terminal" from the Unraid Web UI or SSH into your Unraid server. Create the Script File: In the terminal, create a new script file: "nano kill_shims_and_stop_containers.sh" Paste the Script: Copy the script from above and paste it into the terminal. To paste in the terminal, use Ctrl+Shift+V (or right-click and select Paste). Save and exit by pressing Ctrl+O, then Enter, and finally Ctrl+X. Make the Script Executable: Give the script execute permissions: "chmod +x kill_shims_and_stop_containers.sh" Run the Script: Execute the script to process running containers: "./kill_shims_and_stop_containers.sh" Monitor Output: The script will display which containers are being processed, which containerd-shim processes are terminated, and whether containers are successfully stopped. Verify the Containers Are Stopped: After the script completes, check the container status to ensure they are stopped: "docker ps"

Those wanting intel arc support remember to vote:

Steps Tried: 1-6 System Log: Put in a spoiler. Mover Tuning Log: Extra Details: eg. Only stopped working after latest update.

Hi @ich777 Tried installing the plugin tonight and got the following on install: plugin: downloading: i915-sriov.plg ... done plugin: downloading: unraid-i915-sriov-2023.04.06.txz ... done +============================================================================== | Installing new package /boot/config/plugins/i915-sriov/unraid-i915-sriov-2023.04.06.txz +============================================================================== Verifying package unraid-i915-sriov-2023.04.06.txz. Installing package unraid-i915-sriov-2023.04.06.txz: PACKAGE DESCRIPTION: Package unraid-i915-sriov-2023.04.06.txz installed. patching file usr/local/emhttp/plugins/dynamix.vm.manager/include/libvirt.php Hunk #1 succeeded at 816 (offset 36 lines). +============================================================================== | WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING | | Don't close this window with the red 'X' in the top right corner | until the 'DONE' button is displayed! | | WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING +============================================================================== ----------Downloading i915-sriov module Package for kernel v6.1.64---------- ---------This could take some time, please don't close this window!----------- --------Can't download i915-sriov module Package for kernel v6.1.64----------- plugin: run failed: '/bin/bash' returned 1 Executing hook script: post_plugin_checks Any assistance you can offer would be appreciated.

Personally I would like to see the linux community get its shit together and create a set of driver standards and a centralised database for all flavours. That way a manufacturer can submit the appropriate information about a products drivers to said central database and then that driver would be converted autonomously and released all at the same time. Its one of the reasons windows and macos is so dominant and are able to treat customers the way they do, because installing software and drivers in all flavours of linux is a pain in the arse, and I say that as someone who doesn't use windows except for the VMs I need to run drivers I cant get on freakin linux. LOL

I'd agree with this if the discussion was about obscure technology, but when it comes to GPUs..........

Can you use google icons for this? Because if you could that would be awesome. https://fonts.google.com/iconshttps://fonts.google.com/icons

Same issue here. Except for me, the inability to backup my flash just resulted in me having to completely rebuild my entire setup. I am not amused.

I'd like to suggest an enhancement for Unraid. Is it feasible to modify the "docker allocation" section to display pre-allocated fixed IP addresses? Currently, when you are installing a new container, any currently installed container which is turned off displays a "0.0.0.0" IP address in the docker allocation section. Given that not all containers are active simultaneously, this can pose an inconvenience, particularly when you're attempting to establish fixed IP addresses within a specific range for a group of containers. It becomes challenging to identify which IP addresses are already in use, and if you accidentally assign an IP address that's already in use, it will indeed install and launch the container. However, when you subsequently activate the container with the same fixed IP address, conflicts may arise. My request is to have the "docker allocations" section display the fixed IP addresses of other containers which already have a fixed IP address allocated, whether they are currently powered on or not, when you're installing a new container. This would provide clarity when manually setting IP addresses, preventing conflicts and ensuring a smoother experience.

As we all know, using the Nvidia plugin there's great support for NVIDIA GPU's for transcoding et al. However, support for AMD has been, shall we say, rather sketchy. I have been going through all of the announcements from AMD on their new 7000 series CPU's and it transpires that the ENTIRE range are all APU's with onboard graphics. Considering the base range outstrips the 11700K from intel the AMD 7000 series is very shortly going to be popping up with home unraid servers in quick succession, and considering the conference call I listened into for NVIDIA shareholders where they openly admitted to intentionally reducing manufacturing to artificially inflate price due to demand outstripping supply (and a certain company terminating its partnership with Nvidia), I have a feeling that AMD GPUs are also going to be more popular in the coming months and years. For all of this and more, I'd like to formally put it to the community to support, and to the unraid team to move forward with trying to make AMD drivers and integration to docker etc, a standard feature in the next release either by official plugin, or as standard with unraid itself. An AMD 7000 CPU with APU capabilities may well be a very attractive prospect for those building an unraid server particularly when it comes to things like plex or tdarr etc. All the best, Martin

I actually do this for transcoding. I have my unraid server which has a docker instance of Tdarr server running on it. The directories shared across the network. On all the other computers in the house I have Tdarr client running on them (and an instance of Tdarr client on the unraid server). The clients are then pointed at the server directories and at the Tdarr server instance. The Tdarr server then controls farming out jobs to all the clients and itself at night when everyone is in bed, allowing the distributed transcoding of my media library using the other pc's on my home network when everyone is asleep. Come morning tdarr server instructs the pc's to stop transcoding and therefore not sapping system resources from my family members during the day. As most of the household PC's are gaming PC's I can take advantage of their GPU's for transcoding media. I have a thing about putting everything in H265 to save space. With respect to unraid server itself, what would be really really cool (for home users) would be a way to "wakeup" other slave pc's with unraid running on it at times of peak use, or scheduled backups, etc etc. I could easily see a use case (especially considering the cost of electricity at the moment) where you could build a very minimum spec unraid server running on low power, just trundling along minding its own business and not using a lot of electricity, then when the family come home at 5pm after work and want to all watch movies at the same time, or do a raft of other tasks and that server gets bogged down, it wakes up another small server, and another (as it needs extra resources), or indeed shuts them off when not needed to save electricity. The ability to save money by distributing unraid across many small computers vs one large one, and only turning on what it needs, when it needs it. That would be an absolute game changer for pro-sumers. Plus, if you have say 6 small pc's you have 6 network cards, you can then serve 6 movies to 6 people at the same time at 1Gb each. Or, the idea I really like is the ability to transfer a very large file to unraid, and it split it up amongst all 6 machines into a cache pool over the network taking advantage of high bandwidth, and then have a version of mover that would recombine that on one server gradually etc. The possibilities for unraid with distributed computing are just freaking mind blowing. And I mean if you were to build the PC's it was running on to gaming spec? Woof! Can you imagine never needing a bloody tower in any room in the house again, whether it be for your TV or for gaming, or work. A shed load of vm's that can use the system resources of multiple pcs in one central location? Put simply, the possibilities of unraid with distributed computing in a household setting - YES PLEASE! SIGN ME UP! DO IT! LOL

Is there an official list of the extra parameters field on VMS and docker containers?

I noticed recurring questions about Dell R710 servers and unraid over the past few months and I currently have two in operation, one with Perc 6i controller and one with an H700. I just wanted to post the steps I go through in order to turn them into unraid servers for those who were asking, seeing as though I have had a lot of help from the community. Dell R710's running either PERC H700 or 6i controllers should be able to be setup as an unraid server. The first thing you need to do is configure the virtual drives. You want to assign each drive seperately to its own raid-0 virtual drive. 1. Boot the server and enter into the raid configuration utility (usually CTRL+R when prompted). 2. Press F2 on the controller and click create new VD. 3. Select your first drive with an x 4. Give it a name (see note below) 5. Select advanced options and set element size to 64KB, read policy to "adaptive read" and write policy to "write through". Press OK 6 Repeat for each drive. NOTE: Your drives start at 0. If you have an R710 with 6 3.5" drives then your drives will number 0-5. If you have an R710 with 8 2.5" drives (like me) then your drives will be numbered 0-7. I highly suggest giving the VD for drive 0 the name "B", VD for drive 1 the name "C", VD for drive 2 the name "C" etc. The reason for this is quite simple. When unraid lauches the drives are named a, b, c etc. The first one "a" is always the USB stick you have the unraid flashed to. Your SSD's and HDD's are then b, c, d, e etc. The raid controller does not pass the actual drive numbers through to unraid, so if you don't name the drives and assign them in unraid in the same order, it makes fault finding a pigs ear when you have to replace a drive. For instance, my setup has drives 0 and 1 as SSDs. I use these for my cache. Drives 2-7 are hdd's. When configuring unraid from the UI, you would designate them to their slots in the same order. I label them as such: Unraid VD Physical Drive Slot Information (sda) N/A USB Flash (sdb) (b) Drive 0 Cache (sdc) (c) Drive 1 Cache (sdd) (d) Drive 2 HDD (sde) (e) Drive 3 HDD (sdf) (f) Drive 4 HDD (sdg) (g) Drive 5 HDD (sdh) (h) Drive 6 HDD (sdi) (i) Drive 7 HDD If you follow this very simple labelling scheme then if drive sdg on unraid experiences issues, then you know that it is VD G in the raid controller that you are dealing with and that corresponds to drive 5. 7. IMPORTANT: MAKE SURE THAT AFTER YOU HAVE CREATED YOUR VD'S YOU GO OVER EACH OF THEM AND PRESS F2 THEN "START INIT" TO INITIALISE THEM. YOU MUST LET THEM ALL GO THROUGH THE INITIALISATION PROCESS. 8. BOOT INTO UNRAID. You may have to go into the bios and enable USB booting. You can do this by turning UEFI boot off in the bios and that will then let you set the boot order. Make sure the unraid USB is in the machine when you boot up or you wont see it in the bios to select it. Once booted into unraid, it's the usual config you would do with any other unraid server.