mortist

Alright I think I resolved this error after a little research. I feel like I might have been able to complete this process without "Remove Pool", but I'm not sure. Anyway- Upon shrinking the original BTRFS cache pool and removing the four drives, I also created a new ZFS pool at the same time. I guess using "Remove Pool" wipes the UUID from the unraid config, but since I created a new 'cache_zfs' pool- restarting the array triggered some emhttpd bug with multi-pool setups and unRAID was unable to read the original UUID on the BTRFS pool?? I have no clue, but here's the fix: Removed the second ZFS pool that I had created. Run New Config, retain assignments for array & cache pool. REBOOT Start the array, which also triggers a parity sync. Doing this, with only one cache pool- I'm back to normal with a single BTRFS pool and four drives. I'll create the ZFS pool separately now.

Hm - I tried it and I'm now at "Unmountable: unsupported or no file system"

Thanks - Currently starting the removal process. Regarding the future "new" pool- Does "remove pool" destroy any data on the remaining 4 devices? Is this a similar process to "new config" ? Thanks - Learning as I go here.

So I stopped the array and unassigned Disk #8 and restarted the array, but the array did not immediately go into Balance/Delete mode and the "Stop" button is still active. Thoughts? Start a Balance operation?

Alright so my current pool is eight disks, only 30% utilized. What's the safest, non-destructive, way to shrink the pool? I was reading the wiki, and it seems like using the "btrfs device remove" might be the fastest? But I got hung up on the wiki where it says remove all assigned devices and boot the pool, and then boot the pool a second time to reassign all devices? Is there a safer way?

Alright - You're correct, maybe the GUI is just in my mind because Plex is bugging me. Safe Mode- a solid 2 seconds to render any page. Normal Boot- Most pages load in 2 seconds, the dashboard takes 3. The easiest place to notice this lag is on the Plex Collections, I just timed one page at 13 seconds to load the poster thumbnails. Is BTRFS suitable for this type of workload? Hundreds of tiny random files? Thanks again, Alright - You're correct, maybe the GUI is just in my mind because Plex is bugging me. Safe Mode- a solid 2 seconds to render any page. Normal Boot- Most pages load in 2 seconds, the dashboard takes 3. The easiest place to notice this lag is on the Plex Collections, I just timed one page at 13 seconds to load the poster thumbnails. Is BTRFS suitable for this type of workload? Hundreds of tiny random files? Thanks again,

Hardware: Supermicro 846 Chassis, EPYC 7452, 128GB RAM, 10 HDD array, 8 SSD Cache Pool, P2000 GPU Use Case: Plex, *arrs, Home Assistant, Windows 11 (Blue Iris), Frigate, PiAware, etc...etc... Background: My previous configuration had a single XFS SSD cache drive. I never observed any sluggishness with the GUI, Plex or other containers. Current Situation: After a migration, my Cache pool is now eight 1TB SSD configured in BTRFS RAID10. I initially had this pool configured as a RAID1, but the same lag was noted. Whenever loading Plex libraries (On any device, on any network - local or remote) the thumbnails take 5-10 seconds to populate. Whenever navigating the unRAID GUI, the screens take 5-10 seconds to load. All of these mundane tasks seem to take ~5 or more seconds to complete. Plex is obviously the most annoying, because friends and family have also noted the change. Attempted: Started as RAID1 before moving to RAID10. Balanced, scrubbed, defragged........ Ask: Am I insane? Shouldn't this pool absolutely dominate these tasks? Do I attempt to migrate this pool to ZFS? Do I give up and move back to a single XFS drive? Am I really losing performance on small files due to overhead or something? This is new territory for me, so I thank you in advance. tower-diagnostics-20251228-1958.zip

Thanks, The find command took over an hour to return this, seems awfully slow but maybe because parity sync is running. Are these true duplicates or is it showing links? What's up with that user0 endpoint? root@Tower:~# find /mnt -name libvirt.img /mnt/user/backups/libvirtbackup/libvirt.img /mnt/user/backup/libvirt.img /mnt/user/system/libvirt/libvirt.img /mnt/cache/system/libvirt/libvirt.img /mnt/disk4/backups/libvirtbackup/libvirt.img /mnt/disk3/backup/libvirt.img find: ‘/mnt/user0’: Transport endpoint is not connected root@Tower:~#

Hey Guys, Long term user, I've handled most of these things without issue before- I thought I knew what I was doing, but obviously I've made a mess: [Latest Edit] - Restored VMs from backup, used "Previous Apps" to get containers back and I'm not sure if it was necessary but used CA Backup/Restore to restore. Parity check running. I'd still appreciate if anyone would look through the latest logs and outline errors that might bite me in the future. Thanks! Scenario: Had one single 'cache' drive 1TB SSD Have seven new 1TB SSD Wanted to make new BTRFS pool 'cache_pool' using Six disc, reassign all shares, run mover Eventually my plan was to keep 'cache_pool' and remove 'cache' ultimately expanding to Eight 1TB 'cache_pool' Issues: Most of the share reassign and movers went fast, but appdata ground to a halt (I'm guessing Plex metadata).......... After several hours of KB/s mover, I got anxious and stopped mover, resorted to rsync which moved everything in appdata at a much higher speed. First problem: 'vm' share appears to be toast.....I cant find it on any disk Second problem: Dockers are now totally gone Somewhere during this process I also removed 'cache' and renamed 'cache_pool' to 'cache' - hoping that it might resolve some internal sync concern. During this mess I also had a drive start throwing errors- To which I removed the drive and ran New Config- which results in a parity rebuild to complicate my matters. Am I totally hosed here? Next steps: Restore Dockers from Appdata Backup/Restore ? The docker data is present inside \cache\appdata and the docker *.img file is present under \system\ I've got at least one of my VM images saved as backup, so I can rebuild that and the others aren't much of a problem either. There's gotta be something I'm missing......... Thanks! tower-diagnostics-20251123-2358.zip

Joining the thread. Pretty sure this amazing community won't survive a payment plan, but maybe that's intended..... If the Pro license isn't grandfathered, I'm sure most of us will drop. I'm tired of everyone trying to get monthly payments out of their customers.....

[Update] - Gave up troubleshooting and Uninstalled Calibre, Deleted the image and reinstalled the :latest.... Now it works2. Sorry to revive this old thread. I haven't used my calibre docker in awhile and it seems I'm facing this same issue. unRAID 6.11.5 Calibre:Latest Concern: WebGUI launches into an XORG login page that fails with "login failed for display 0". Attempted: I've tried every version from 6.4.0 to 6.5 and 6.7 and 6.8 and now "latest". I've removed the UMASK variable I've tried --security-opt seccomp=unconfined in the Extra Parameters. There are no "GUAC" variables defined. I have tried with and without "PASSWORD" defined I tried the "DISABLE_AUTH" variable. I've read the last ~10 pages of this thread and all the pages on GitHub.....Made no progress. Is there anyway to get this working again? Appreciate any help, thanks.

Crashed again, I was able to grab syslog this time. This may be a side-effect of also adjusting my rclone mount settings the same day. I had increased the cache size and I had not supplied a cache-dir setting. I am assuming it exceeded the RAM and possibly lead to this problem. I've updated my rclone mount scripts and I will continue to monitor. Snip of syslog: eb 9 08:54:16 Tower ipmiseld[7519]: ******6: Error connecting: session timeout Feb 9 08:57:43 Tower kernel: docker0: port 9(veth62b81ae) entered blocking state Feb 9 08:57:43 Tower kernel: docker0: port 9(veth62b81ae) entered disabled state Feb 9 08:57:43 Tower kernel: device veth62b81ae entered promiscuous mode Feb 9 08:57:43 Tower kernel: docker0: port 9(veth62b81ae) entered blocking state Feb 9 08:57:43 Tower kernel: docker0: port 9(veth62b81ae) entered forwarding state Feb 9 08:57:43 Tower kernel: docker0: port 9(veth62b81ae) entered disabled state Feb 9 08:57:44 Tower kernel: eth0: renamed from veth1d85cfc Feb 9 08:57:44 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth62b81ae: link becomes ready Feb 9 08:57:44 Tower kernel: docker0: port 9(veth62b81ae) entered blocking state Feb 9 08:57:44 Tower kernel: docker0: port 9(veth62b81ae) entered forwarding state Feb 9 09:00:07 Tower crond[3070]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Feb 9 09:04:15 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/backgroundScript.sh /tmp/user.scripts/tmpScripts/plex_preloader/script Feb 9 09:04:17 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/showLog.php plex_preloader Feb 9 09:22:38 Tower ipmiseld[7519]:******6: Error connecting: session timeout Feb 9 09:26:09 Tower root: error: /webGui/include/Notify.php: uninitialized csrf_token Feb 9 09:26:09 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:12 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:12 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:12 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:12 Tower root: error: /plugins/preclear.disk/Preclear.php: uninitialized csrf_token Feb 9 09:26:15 Tower root: error: /plugins/dynamix.system.temp/include/SystemTemp.php: uninitialized csrf_token Feb 9 09:26:15 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:19 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:19 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:19 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:19 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:21 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:26 Tower root: error: /plugins/dynamix.system.temp/include/SystemTemp.php: uninitialized csrf_token Feb 9 09:26:27 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:28 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:28 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:28 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:33 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:37 Tower root: error: /plugins/dynamix.system.temp/include/SystemTemp.php: uninitialized csrf_token Feb 9 09:26:39 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:44 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:44 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:44 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:45 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token Feb 9 09:26:45 Tower root: error: /webGui/include/DashUpdate.php: uninitialized csrf_token

Thanks in advance, I was following the IBRACORP guide to installing Authelia, struggling with the configuration.yaml as I could not get Authelia to launch. I had been through several rounds of edits on the confiugration.yaml and attempted to launch Authelia when my array seemed to get kicked offline and the GUI was available but very unstable. The Docker manager and VM manager reported that the array was offline, no dockers were visible or accessible from the GUI. I tried to use the GUI to perform a clean reboot, but it became unresponsive and required a hard cycle. The machine booted back into a parity check, but everything else seemed normal. I deleted the Authelia installation and appdata, figured I would chase that setup at another time. Unfortunately this crashing has continued about every 15-20 hours. I'll attach the diagnostics, I'm no expert but it seems like the Docker.img is corrupt? Is there something else going on? Here's a snippet of the syslog, I received an email around 12:19AM stating that the parity check had finished. In reality it looks like the array just went offline. Thanks again, diagnostics attached. Feb 8 14:55:06 Tower kernel: eth0: renamed from vethea5eb4e Feb 8 14:55:06 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb9f82a8: link becomes ready Feb 8 14:55:06 Tower kernel: docker0: port 6(vethba926a5) entered disabled state Feb 8 14:55:06 Tower kernel: eth0: renamed from veth060af26 Feb 8 14:55:06 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethba926a5: link becomes ready Feb 8 14:55:06 Tower kernel: docker0: port 6(vethba926a5) entered blocking state Feb 8 14:55:06 Tower kernel: docker0: port 6(vethba926a5) entered forwarding state Feb 8 14:55:11 Tower kernel: vethea5eb4e: renamed from eth0 Feb 8 14:55:11 Tower kernel: docker0: port 4(vethb9f82a8) entered disabled state Feb 8 14:55:11 Tower kernel: docker0: port 4(vethb9f82a8) entered disabled state Feb 8 14:55:11 Tower kernel: device vethb9f82a8 left promiscuous mode Feb 8 14:55:11 Tower kernel: docker0: port 4(vethb9f82a8) entered disabled state Feb 8 14:55:11 Tower kernel: docker0: port 4(veth3365f3b) entered blocking state Feb 8 14:55:11 Tower kernel: docker0: port 4(veth3365f3b) entered disabled state Feb 8 14:55:11 Tower kernel: device veth3365f3b entered promiscuous mode Feb 8 14:55:11 Tower kernel: docker0: port 4(veth3365f3b) entered blocking state Feb 8 14:55:11 Tower kernel: docker0: port 4(veth3365f3b) entered forwarding state Feb 8 14:55:11 Tower kernel: eth0: renamed from veth14b8d0f Feb 8 14:55:11 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3365f3b: link becomes ready Feb 8 14:58:03 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 15:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 15:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 15:26:25 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 15:54:48 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 16:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 16:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 16:23:09 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 16:25:16 Tower emhttpd: cmd: /usr/local/emhttp/plugins/community.applications/scripts/pluginInstall.php install https://raw.githubusercontent.com/Squidly271/ca.turbo/master/plugins/ca.turbo.plg Feb 8 16:25:16 Tower ****: plugin: running: anonymous Feb 8 16:25:16 Tower ****: plugin: running: anonymous Feb 8 16:25:16 Tower ****: plugin: creating: /boot/config/plugins/ca.turbo/ca.turbo-2021.03.10-x86_64-1.txz - downloading from URL https://raw.github.com/Squidly271/ca.turbo/master/archive/ca.turbo-2021.03.10-x86_64-1.txz Feb 8 16:25:17 Tower ****: plugin: checking: /boot/config/plugins/ca.turbo/ca.turbo-2021.03.10-x86_64-1.txz - MD5 Feb 8 16:25:17 Tower ****: plugin: running: /boot/config/plugins/ca.turbo/ca.turbo-2021.03.10-x86_64-1.txz Feb 8 16:25:17 Tower ****: plugin: running: anonymous Feb 8 16:25:17 Tower ****: plugin: running: anonymous Feb 8 16:25:38 Tower ****: Starting Auto Turbo Feb 8 16:25:38 Tower kernel: mdcmd (37): set md_write_method 1 Feb 8 16:25:38 Tower kernel: Feb 8 16:26:28 Tower ****: Stopping Auto Turbo Feb 8 16:26:28 Tower ****: Starting Auto Turbo Feb 8 16:26:29 Tower kernel: mdcmd (38): set md_write_method 1 Feb 8 16:26:29 Tower kernel: Feb 8 16:36:58 Tower emhttpd: spinning down /dev/sdh Feb 8 16:36:58 Tower emhttpd: spinning down /dev/sdi Feb 8 16:51:32 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 17:00:02 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 17:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 17:19:53 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 17:46:32 Tower webGUI: Successful login user **** from ****217 Feb 8 17:48:14 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 18:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 18:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 18:11:56 Tower webGUI: Successful login user **** from ****217 Feb 8 18:16:36 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 18:44:58 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 19:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 19:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 19:13:19 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 19:41:42 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 20:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 20:10:02 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 20:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 20:38:23 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 20:58:27 Tower sSMTP[34633]: Creating SSL connection to host Feb 8 20:58:27 Tower sSMTP[34633]: SSL connection using TLS_AES_256_GCM_SHA384 Feb 8 20:58:29 Tower sSMTP[34633]: Sent mail for ********** (221 2.0.0 closing connection y3sm6443052oix.41 - gsmtp) uid=0 username=**** outbytes=707 Feb 8 21:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 21:06:44 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 21:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 21:35:06 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 22:00:07 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 22:03:28 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 22:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 22:31:50 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 23:00:12 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 23:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 8 23:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 8 23:28:34 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 8 23:56:55 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 9 00:00:16 Tower crond[3055]: exit status 1 from user **** /usr/local/sbin/mover &> /dev/null Feb 9 00:08:15 Tower emhttpd: read SMART /dev/sdh Feb 9 00:08:45 Tower emhttpd: read SMART /dev/sdi Feb 9 00:10:08 Tower dhcpcd[2958]: br1: dhcp_sendudp: Network is unreachable Feb 9 00:19:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:19:01 Tower sSMTP[36648]: Creating SSL connection to host Feb 9 00:19:01 Tower sSMTP[36648]: SSL connection using TLS_AES_256_GCM_SHA384 Feb 9 00:19:03 Tower sSMTP[36648]: Sent mail for ********** (221 2.0.0 closing connection h2sm6140912ots.51 - gsmtp) uid=0 username=**** outbytes=715 Feb 9 00:19:15 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:20:00 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:20:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:20:45 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:21:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:21:31 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:22:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:22:17 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:23:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:23:03 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:23:49 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:24:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:24:34 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:25:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:25:17 Tower ipmiseld[7365]: ****6: Error connecting: session timeout Feb 9 00:25:20 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:26:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:26:05 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:26:51 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:27:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:27:37 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:28:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:28:22 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only 4096 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:28:31 Tower winbindd[1400]: [2022/02/09 00:28:31.484103, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:28:31 Tower winbindd[1400]: messaging_reinit() failed: NT_STATUS_DISK_FULL Feb 9 00:28:31 Tower nmbd[1401]: [2022/02/09 00:28:31.494604, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:28:31 Tower nmbd[1401]: messaging_reinit() failed: NT_STATUS_DISK_FULL Feb 9 00:28:37 Tower smbd[1437]: [2022/02/09 00:28:37.208898, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:28:37 Tower smbd[1437]: messaging_reinit() failed: NT_STATUS_DISK_FULL Feb 9 00:29:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:29:09 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:29:54 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:30:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:30:40 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:31:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:31:26 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:32:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:32:11 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:32:57 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:33:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:33:43 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:34:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:34:29 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:35:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:35:15 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:36:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:36:02 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:36:47 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:37:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:37:32 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:38:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:38:19 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:39:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:39:04 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:39:50 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:40:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:40:35 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:41:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:41:22 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:42:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:42:08 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:42:54 Tower rc.diskinfo[12839]: PHP Warning: file_put_contents(): Only -1 of 10928 bytes written, possibly out of free disk space in /etc/rc.d/rc.diskinfo on line 266 Feb 9 00:43:01 Tower crond[3055]: exit status 2 from user **** /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 9 00:43:31 Tower winbindd[36574]: [2022/02/09 00:43:31.492601, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:43:31 Tower winbindd[36574]: messaging_reinit() failed: NT_STATUS_DISK_FULL Feb 9 00:43:31 Tower nmbd[36575]: [2022/02/09 00:43:31.499934, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:43:31 Tower nmbd[36575]: messaging_reinit() failed: NT_STATUS_DISK_FULL Feb 9 00:43:37 Tower smbd[36975]: [2022/02/09 00:43:37.244701, 0] ../../source3/lib/util.c:500(reinit_after_fork) Feb 9 00:43:37 Tower smbd[36975]: messaging_reinit() failed: NT_STATUS_DISK_FULL tower-diagnostics-20220209-0800.zip

Ah man, Solid advice. Yes I was using a Chrome Web browser and it would fail every time. I tried from my phone and boom- worked no issue. I also have another client running right now, a FireTV transcoding with no issues. Well, that's bad news for anyone trying to HW transcode in Chrome! I'm going to leave HW transcoding turned on. Thanks for your advice! I wasn't even thinking to try a different client.

Thanks for your support. I've included more logs as attachments. In the Plex logs around 7:45:40 I started a normal playback without transcoding and the stream is fine. At approximately 7:46:00 I tried to force the client to transcode to a lower quality and the video simply goes black and never starts. You can see that Plex calls Nvidia for 1-2 seconds, but then the GPU goes idle again. I cannot find anything more than "Generic error in an external library". Is there some other log where more GPU details are stored? Transcode throttle buffer is set to 6000 nvidia_Console_output.txt Plex_Media_server_short_11132021.txt nvidia-smi_-l_1.txt nvidia_status.txt

Hi Team, I am looking for some support with Plex Hardware transcoding. In short, I have followed all of the available guides and I think I have everything setup properly, but when Plex begins to transcode I can see the activity start in 'watch nvidia-smi' and then the GPU goes idle again. I do have Plex Pass, I do have the Nvidia driver installed. Using unRAID 6.9.2 Dell R530 Quadro P2000 I have tried the Plex docker, Binhex and Linuxserver, all seem to behave the same. I see them call the GPU and then it goes idle shortly afterwards. I have tried all three Nvidia code branches, but I found no change. I appreciate any support or guidance! The Plex logs are the only clue I have found so far: Nov 11, 2021 06:43:22.715 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice vaapi Nov 11, 2021 06:43:22.716 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: testing API vaapi Nov 11, 2021 06:43:22.716 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: Generic error in an external library Nov 11, 2021 06:43:22.717 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice nvdec Nov 11, 2021 06:43:22.718 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: testing API nvdec Including screenshots and logs: Plex_Media_server_short.txt tower-diagnostics-20211111-0633.zip

Thanks Walter, Apologies my response was poorly worded. I do have '--runtime=nvidia' included in the extra parameters. I seem to remember some of the dockers required 'plexpass' parameters being added, but that does not seem to be the case for Linuxserver. I have tried the official docker as well as the binhex docker and both produce the same result. The GPU becomes active, but the stops shortly afterwards. Do the instructions found on: https://github.com/NVIDIA/nvidia-docker Still apply to unRAID 6.9.2? Extra Parameters: Visible Devices: Capabilities: Nvidia Driver package: Nvidia Statistics Plugin: Nvidia SMI:

Sorry, yes I do have plex pass. I don't think there are any extra parameters to add to the docker template, right?

Hello, Looking for some support on HW transcoding. System: Dell R530 dual E5-2680v4 Quadro P2000 I have followed all of the guides including setting environment variables, the card is visible to unRAID including statistics and 'watch nvidia-smi'. Once I initiate a transcode I can see that the GPU is called for 1-2 seconds, but then it returns to idle. I have tried different versions of Nvidia drivers and different version of Plex docker, with the same results. There has to be something simple I am missing? Here's at least one piece of the Plex logs indicating the failure: Nov 11, 2021 06:43:22.715 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice vaapi Nov 11, 2021 06:43:22.716 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: testing API vaapi Nov 11, 2021 06:43:22.716 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: Generic error in an external library Nov 11, 2021 06:43:22.717 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice nvdec Nov 11, 2021 06:43:22.718 [0x1529ff51eb38] DEBUG - [Transcode] Codecs: hardware transcoding: testing API nvdec Thanks in advance, tower-diagnostics-20211111-0633.zip Plex_Media_server_short.txt