jimbobulator

Hello, thank you for the response. I checked and re-set the drive connectors and did a hard reboot to see if it would come back. I could hear a drive doing a click / click / click routine, and now it's showing disk2 as not installed. I'm thinking it's completely toast? I'm going to start moving the data off that drive in preparation for removal.

Hello, Woke up to a disabled disk today, having trouble deciphering exactly what's going wrong. Diagnostics attached. I had some read errors a few months ago on both older drives (disk2 and disk4, both 6TB drives, both older 4-5 yrs old) but smart looked fine on both, so I continued running. Server is getting older, built in 2014. Parity check started yesterday but didn't finish due to disk2 failure. disk2 failure happened late in the parity check and this drive likely wasn't doing anything at that point, as it's 1/2 the size of parity. I'm seeing recurring out of memory errors happening between 3-4am each day, along with Plex being killed each time. I can't really make sense of what's going on, clearly more than just a failed drive. Maybe someone can help? Should I run memtest? I don't have a spare disk at the moment, but I can copy the data to another disk in the array and remove the failed disk, or copy it off the array if that's safer. Thanks!

Check your vpn container env. variables. I had to add the VPN_INPUT_PORTS variable per the FAQ recently to fix this.

edit: I figured it out. The %T part seems to be the issue, I'm guessing because it uses colons. Replaced with more specific values to get HH.MM.SS rather than HH:MM:SS and it's okay now. Cheers. Hello. Weird issue. My script is writing to a logfile in my appdata share (works fine). I'm trying to move the file to a unique, dated file for each run of the script (daily). I'm using $(date) to append the date to the log file. Works fine in a shell session, but when I run it from my script, the resulting filename is something like BEZTLJ~Z.LOG. mv /path/to/logs/logfile /path/to/logs/logfile.$(date "+%F.%T").log Normal logfile is named correctly. Dated logfiles have garbled filenames. Any ideas what I'm doing wrong?

Hi, right ... dry-run shouldn't move anything. You can find the log file at /boot/logs/unbalance.log I'll take a look at the logs tonight and see if I can see anything weird.

I tried a dry-run (1.3.7) moving the contents of a old disk (disk2) onto an empty disk (disk3). I selected all the shares in settings. I was expecting nothing to change, being a dry-run, but to my surprise this morning, 700GB out about 2.1GB of data was moved from disk2 to disk3 during the dry run. Shouldn't the dry-run leave everything where it is? And weirder still, if it didn't do a dry-run, why only move some of the files? Where can I find the log files for unbalance?

As an aside I lost my webui links from the drop downs for all my containers back in the late betas for v6. Never got around to troubleshooting after my comment in the beta thread got lost. New containers have the correct links but old ones don't. Deleting and recreating from local templates didn't fix it, if I recall.

Using needo-plex. I was able to reduce and possibly completely remove the ballooning docker utilization by mapping the Plex transcoding outside of the docker.img file. I haven't watched it closely to see if it is completely stable or not but I've stopped seeing it go up GB at a time. I can see the transcode temporary files being generated in my external folder. I did not make any settings in the Plex WebUI related to transcode location - the temporary transcode location setting is blank. To me this was a smoking gun for my problem. I thought that Plex was not transcoding anything, but as it turns out it's occasionally transcoding audio and often transcoding between contains (direct stream vs. direct play), which generates the same large temporary files. I'm surprised more people aren't seeing this issue since even using direct stream with container transcoding can easily generate many GB of temporary files and none of the Plex containers have any instructions on how to map transcode directories, or why it should be done.

Could be Plex - that seems plausible. My Plex streaming is local and video usually isn't transcoded except for some x265 stuff recently. Audio is sometimes (only DTS, I think). Assuming this is the problem, I have no interest in dedicating RAM to transcoding; I think it's a waste when I have a perfectly good SSD with lots of space. If/when I get some time I'll dig in and see if I can track the disk usage inside the docker...

I'm confident in my docker mapping configuration. None of my dockers (only 5 running) have any constant updating beyond the way needo-plex and needo-plexwatch update on restart. I basically never restart them. So I don't think this explains it. The last two times I noticed a rapidly ballooning docker.img I happened to be using streaming locally from Plex. Both times were direct play with audio transcode, relatively high bitrate files. I'm not sure it's linked to Plex, just a casual observation. These are the dockers I'm actually running: binhex-sonarr binhex-delugevpn needo-plex needo-plexwatch hurricane-ubooquity As per my understanding of docker, the images are static, and when we start a container, it's basically an running instance of said container. With btfrs and qcow2, the incremental size on disk of this instance shouldn't be significant, unless it changes significantly from the image. That shouldn't be happening though. Is there a way to check the size on disk of a running container instance vs. the image sizes found by running "docker images"?

I have the same problem. Before updating to 6.1.2 (from 6.0.1), I ran out of space in docker.img, so I increased the size from 10 to 15GB. After a couple weeks, without adding any new dockers or doing anything, really, I saw that I was well over 10GB according to the unRAID settings page. I updated to 6.1.2, and I immediately got a notification saying docker.img was 80% full. The next day I get 5 messages, showing 81%, 82%, 83%, 84% and 85%, all within a few hours. No changes for the last few days. On top of this, different places report different utilization: Docker settings shows 9.98/14 or 71% (I think): Label: none uuid: c9b4118d-8c62-40ee-8291-827e79ededcb Total devices 1 FS bytes used 9.98GiB devid 1 size 15.00GiB used 14.00GiB path /dev/loop0 btrfs-progs v4.1.2 The notification I got said 85%: Event: Docker high image disk utilization Subject: Warning [bARAD-DUR] - Docker image disk utilization of 85% Description: Docker utilization of image file /mnt/appdisk/docker.img Importance: warning From the command line, I see that the sum of all the docker images I have is around 4.7GB, which would be 31%. I've monitored the sizes returned by "docker images" over a few days and the sizes aren't increasing at all. root@barad-dur:~# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-couchpotato latest bda16517d8d1 3 weeks ago 614.2 MB aptalca/docker-plexrequests latest 7eca88a70c04 5 weeks ago 643.8 MB google/cadvisor latest 175221acbf89 11 weeks ago 19.92 MB binhex/arch-sonarr latest b2a57e24dddf 3 months ago 1.013 GB xamindar/syncthing latest 70b7d6227388 3 months ago 371.2 MB binhex/arch-delugevpn latest 5be1c02a894c 3 months ago 930.9 MB needo/plexwatch latest 4052a2f57e29 4 months ago 374 MB needo/plex latest 8906416ebf13 4 months ago 603.9 MB hurricane/ubooquity latest a598b1e14e5d 10 months ago 528.1 MB yujiod/minecraft-mineos latest ff8c61f22de6 11 months ago 604.5 MB Finally, CAdvisor has a different sizes, but same % as calculated above from the docker settings UI: 11.50 GB / 16.11 GB (71%)

I have this problem with the same microsoft keyboard, so I have opted to try passing the entire USB controller through, which I'm fine with. The VM boots up, but I still am losing the keyboard after a few seconds after it (the keyboard) powers up. I'd like to try the suggested fix below from Jude, but in 6.1 things are a bit different and the go file entry isnt apparently needed, so I'm not sure exactly how to do this. Here's the relevant section of my XML at the moment: <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=00:1d.0,bus=root.1,addr=00.2'/> </qemu:commandline> Any thoughts? 00:1d.0 is the USB controller in question.

Fair enough, I missed this when I read the thread backwards (facepalm). Based on my experience testing it seems that the WebUI does not get the same prioritization, and it's not clear if jonp's term unRAID OS covers the WebUI. If a docker is going crazy and using 100% of all cores, and I can't access the WebUI, I can't stop the docker. Well I can, but not without going to the command line, which it seems LT is trying to avoid users having to do. Not much more than an annoyance for me, but it's an opportunity for improvement. To clarify, my experience is that high CPU load from a docker container makes the WebUI extremely slow, bordering on unusable. I haven't seen it completely crash, but it gets slow enough that it's nearly unusable. I admit I have a low tolerance for this sort of UI behavior...

I have been planning to play with CPU pinning with my containers, because I'm running into problems where my CPU is pinned by a docker and I lose the ability to do anything else with the server. Clearly pinning CPUs intelligently will sort this out. That said, in the name of user friendliness, I think this setting this parameter needs to be improved in the Webui and ideally there should a way that unraid to maintain priority for NAS/Webui functionality, whether through default CPU pinning or process prioritization. In my opinion, add-on applications like dockers should be able to take over to the point where you can't interact with it anymore.