Zer0Nin3r

Data loss in early 7.x versions? Hard pass. I installed 7.0.x and my custom Docker networks went completely sideways. All the info I found to fix it was as clear as mud, with no quick and easy guides in sight—exactly what I needed on an already chaotic day. The upgrade was supposed to simplify my life, not hand me another problem to juggle. Hence, the retreat back to trusty 6.x. Honestly, I can’t even recall the last time an Unraid upgrade gave me this much grief. On another note, while the new features in v.7 do look promising, migrating my cache pool to ZFS suddenly feels questionable. Can someone reassure me that wasn’t a colossal mistake? How has your experience been on Unraid 7?

Upgraded from the latest version of 6.12.x directly to 7.0.1 last week. Today I observed that the Plex server was offline. Tried different network settings without success. Moved from Host to Cutom Network/Bridge mode. Assigned IP address in bridge mode. Issue persists. Plex server still shows up offline at app.plex.tv. Tried regular Bridge mode. Issue persists. Can boot into the local instance of Plex, but the media library doesn’t show up. In fact, the Plex server doesn’t even show up in the Plex GUI as if there is not a server running whatsoever. Upon further investigation, been experiencing slow Docker dashboard load times. I haven’t been observing excessive or continuous writes to the USB flash drive that Unraid is installed to. Furthermore, Unraid GUI would freeze when trying to load the NVIDIA settings panel. Discovered after a reboot of the server that an RTX GPU was not being seen by the system. I uninstalled the NVIDIA plugin and reinstalled the plugin. RTX GPU is now recognized. Server is not freezing when loading into the Nvidia settings panel. GUI takes forever to load the Docker panel. Out of all of my updates and upgrades, I’ve never had any major issues until now. Frustrated, I’m seriously considering downgrading. tower-diagnostics-20250309-2108.zip

I was able to experience this issue and have posted my logs here. **Update** I think I know what the issue was. I was messing with ZFS and wanted to create a snapshot of a VM (snapshot it's directory + .img file) and in doing so I ran the following: zfs create cache/htb zfs set mountpoint=/mnt/user/domains/htb cache/domains/htb Moral of the story — don't do this. To set the mount point you will want to leave it as: /mnt/cache/domains/htb

Having the Unraid terminal in a web browser window was throwing this error for me. Thank. you for this insight!

Is it me or was the /upscale folder's symlink forgotten for 07 - StableSwarm?

Is this still necessary? It looks like the Linuxserver version has since updated Playwright.

This is clutch! To think that this was all I had to do for all these years. This method resolves any GPU initialization issues with Docker containers utilizing an NVIDIA GPU (GTX 1060) after waking from sleep. What this script command does is free up the GPU before the system goes to sleep. Lastly, I’ve found that you don’t need to include the shebang in the S3 command fields. @testdasi Thank you for your help. **Edit** I forgot to mention, you can enable power savings wherein the GPU will go into a low power state. For the longest time I didn't know that you could do such a thing. You can add the following command to your S3 Sleep plugin under the Wake-up Command field. This way when the GPU isn't being used, it will go into a low power state. nvidia-smi -pm 1

Issue seemed to have resolved itself over time. Thank you for the insights. Have a great week!

I've noticed that in the 6.12.2 & 6.12.3 update — Terminal and Log no longer launch from the GUI while using Safari. Content blockers is off for the GUI I don't have any extensions that would interfere. Or at least they haven't in the past. Testing in private browser mode — you are immediately logged out when you try to launch Terminal. **Update** Issue is not present when logging in via IP address, but is present when logging in via local domain name. Using the local domain name wasn't an issue before.

Yeah, the new notification makeover is taking some getting used to. For instance, you can't check the notification or see the notification after upgrading to 16.12.3 because the "Update Unraid OS" window's button doesn't change from "Done" to "Finished" and it doesn't allow the notifications to shine through. If you don't think to open a new tab and check the GUI, you'd be waiting until the cows came home. 🐄

Been experiencing this issue more and more lately. Server has been up for three days. You can login with the GUI, it then slows down and then you can’t even log out and log back in while on local network or while connecting to WireGuard. All the docker services are still up and running so, you can still access those respective services. issue is even persistent in incognito mode. I have been finding that a reboot of the server resolves the issue.

What you can do is stop the Unmanic container prior to launching your VM and vice versa — stopping your VM prior to launching Unmanic. This way you don't crash anything. If you pause Unmanic during an encoding process and then launch your VM, the GPU may not be released to the VM resulting in issues. Like @Josh.5 said, you don't have to passthrough your GPU to Unmanic; Unmanic can still encode using CPU. @Eddie Seelke It is possible to run a single GPU in Unraid and also pass it through to your VM. You would have to pull the firmware from the GPU card and then load it into your VM. I had very limited success with it a few year ago with a GTX 1060. In the end, I spung for a cheap GT 710 to make Unraid happy even as a headless server.

For clarity, may I ask what you are trying to accomplish? If you are booting Unraid into GUI — the answer would be yes.

Looking to modify the MTU size so the excruciatingly slow download speeds will be fixed due to ISP constraints. (5G Internet) Adjusting the MTU within Unraid's settings to 1350 has resolved the VPN issues on my other clients with regards to this particular ISP. I am able to set the MTU at the Unraid system level by: Settings > Network Settings > Desired MTU > 1350 I tried the following without any luck: Key 5 - Container Variable: VPN_OPTIONS --fragment 1350 --mssfix --fragment 1350 --mssfix 1350 Setting the 'mssfix 1350' parameter in the OpenVPN configuration file. I can see in the logs that @binhex sets the MTU in the script and I tried to find the script to adjust, but am unable to; it's not in the Appdata share...that's for sure. OPTIONS IMPORT: adjusting link_mtu to 1624 DEBG 'start-script' stdout output: TUN/TAP device tun0 opened net_iface_mtu_set: mtu 1500 for tun0 net_iface_up: set tun0 up Any ideas on how I can resolve this issue? Thanks in advance!

I recommend that you don't uninstall @dee31797's Handbrake docker until we can get an answer from @Djoss whether it will be supported in the future. I'm with you though. Handbrake with NVENC support is my secondary docker application. If you are automating your encodes, you may want to check out Unmanic as that will support hevc-nvenc.

Quite the DVR collection you have there! 🏆 I have my server setup to use GPU HEVC encoding (speed at the cost of quality/artifacts). Nothing wrong with libx265; better quality — longer encode times and more power usage as it relies on CPU exclusively. As far as your episode failing it could be a bad h.264 encode or a small portion of the file is corrupted. This has happened to me before. Throwing those problematic videos into Handbrake allowed me to re-encode those videos into H.265. Subtitles. Subtitles would cause video encodes to fail 98% of the time with Unmanic. This is being worked on and improved upon in more recent times. /tmp. Is your transcoding cache using the /tmp directory? I suspect that in my case, either my gaming VM is not releasing the GPU fully and that's what is causing the crashes with Unmanic OR I'm running out of RAM memory when encoding large video files. Either way, a reboot of the server has worked for me — not sure why though. **Update** I don't think RAM is a factor in my case at this point in time as 30 minute video files are failing now. I've seen it before though.

Just noticed this happened when checking for Docker updates today. Should we uninstall this docker then?

Agreed. I've been having issues with all encodes failing. Looking at the portion of your log you posted I decided to take a look at my Unraid system log and found this to be happening over and over in real time: Jul 24 23:30:43 Tower kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Jul 24 23:30:43 Tower kernel: caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs Jul 24 23:30:44 Tower kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Jul 24 23:30:44 Tower kernel: caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs Jul 24 23:30:46 Tower kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] I had a feeling that there was some sort of conflict over the GPU wherein Unmanic is failing. Although, I don't have any issues using the same GPU for my gaming VM. And I always stop Unmanic before launching my gaming VM...so something is happening when I re-launch Unmanic and it cannot interface with the GPU for some reason. I have rebooted the Unraid server in the past and I feel that this clears up the issue when it does occur. I wonder if using the Dynamix S3 Sleep is causing an issue...but I didn't really have these kind of encoding failures until this year. Will edit this post if/when I learn more. **Update** Found this in one of the failed encodes: [hevc_nvenc @ 0x560418cb3d40] dl_fn->cuda_dl->cuInit(0) failed -> CUDA_ERROR_UNKNOWN: unknown error Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height Conversion failed! Also, Unmanic is working again after rebooting the server.

😳 Gadzooks! Now I know why Google is moving away from unlimited cloud storage even for universities. 😜

This feature has been requested many times over and I believe is on the roadmap. 1) Do you have Unmanic set to include closed captions? If so, try turning that off. There were issues with past releases wherein some of the CC embedded in a video file would throw an error in FFMPEG and then Unmanic would continue to keep trying those files. But I see that this has been fixed now: "Removes the subtitle stream from the container. This is useful if you intend to supply your own subtitles for your library WARNING: Unsupported subtitles will always be removed" 2) If you set Unmanic so that it is not including CCs, then there is something wrong with the video file. For this I turn to Handbrake (and there is a docker version of Handbrake that supports GPU encoding.) I have yet to run into a problematic video file that Handbrake couldn't handle. Try that. Also, don't have Unmanic NVENC and Handbrake NVENC trying to access the same GPU at the same time or you're asking for trouble.

It is dependent on your GPU and how many H.265 encoding threads it can handle. Nvidia has a break down in one of their developer sections with a grid that shows all the capabilities of the various GPUs which will show you how many streams your GPU can handle. I have a GTX 1060 that I use with Unmanic and I set it to two workers as I noticed my encodes for a large queue finished faster than with three workers believe it or not.

And I have the opposite problem. 😆 I can back up, but cannot restore from the SMB Unraid Time Machine share.

I'm able to do backups to the Unraid Time Machine share, but now that I want to migrate over to a new system, I can connect to the server in Migration Assistant from a fresh install and that's about it. None of the time machine backups show up in the next screen after connecting to the server via SMB. It's been hit or miss as I remember a couple of months ago when doing a restore, I was able to see the Time Machine backups in the Migration Assistant, but I wasn't able to restore; I had to use the secondary backup drive. I know that this doesn't not really help anyone, but at least it goes to show that Time Machine backups over SMB needs some TLC from the Unraid team.

So, it's never a good idea to be working directly within the /mnt/disk (from what I have gathered on the forums.) What I was referring to in my original post is creating snapshots of my VMs as a means to create lightweight backups without wasting space; the other alternative would be to create an exact copy of a VM image, but you are then wasting space. With the cp --reflink command, you are simply noting the changes in the blocks of data from the original image. So, if I were to make some changes to my gaming rig VM and I messed something up, I can just reverse the cp --reflink command and go back to the state that my VM was in before the changes were made. My understanding with snapshots is that if the master file (disk image in this case) gets corrupted, then the reflinks will then be corrupted too. Another thing to note with the reflink flag is that Unraid will/may show that the full image of the reflink is taking up xx amount of space, when in fact, because it is a snapshot, is not actually taking up all the space. Example: If I have a 100 GB VM image, I do a snapshot after installing let's say a 50 MB program, then the snapshot should only take up about 50 MB since those are the only data blocks that have changed in the VM image. However, Unraid will show that the new reflink snapshot to be taking up 100 MB when it is not really taking up that much space (you should be able to see this inside of Terminal or Midnight Commander). Going back to my original point earlier. In order for me to make snapshots with my VM's and in order to use the --reflink flag for the cp command, I have to be in my /mnt/cache/domains/location_of_my_VM_image in order for the command to work. If I try the --reflink flag in my /mnt/user/domains/location_of_my_VM_image (which like I said earlier, you typically always want to be working out of the /mnt/user directory) then the command will fail because I formated my disks to XFS before the format revision that now supports the --reflink flag (reflink = reference link). Furthermore, I was commenting on the fact that even though the revision to the XFS format allows us to take advantage of snapshots, I would have to reformat all of my XFS partitions if I wanted to take advantage of this new feature to which, it does not seem like a possibility for me now unless I were to have another array capable of receiving a backup of my data so I can make the changes. Why XFS? Because BTRFS was not recommended in the Unraid documentation as being stable enough for the array if you don't want a possible chance of data corruption. However, BTRFS was/is fine for the cache pool. So, that is what I am doing when I am making my VM snapshots. I am working directly in the cache pool when I am making my VM snapshots as my VMs reside on the cache as per the share preferences.

@DaClownie - Have you noticed that some of the encodes, you will end up with an output that is larger than the original input? I've been noticing this phenomenon lately especially with some .ts (MPEG-2) encoded streams. But it's not consistent. For the most part the encodes with hevc_nvenc does save me some space (along with time and energy useage.) I've noticed this with Handbrake, you really have to crank down the quality when doing h.265 to get the speeds of the encode to rival that of h.264, but then the files end up being bloated with degraded picture quality than when you first start out with. I'm kind of torn with hevc_nvenc and libx265. On one hand I save a butt load of time using the GPU to process the encodes, but I risk that some files are in fact bloated/enlarged which negates the entire point of re-encoding to h.265. On the other hand, I know my encodes will always net me anywhere from 60 – 80% in file size savings at the expense of heat, energy draw, and thermal load on the CPU, not to mention the extended time it takes to perform the encodes with CPU. I guess I will have to keep an eye on the outputs and if it keeps happening, I may just switch back to libx265 and drop the number of workers; that and wait until we are able to have access to advanced controls / command input that will guarantee that hevc_nvenc encodes will always be smaller than the source file.