rb2k

I found something over here on /mnt/disk1. A bit confused since it's a regular XFS drive and not my SSD where this used to be? /dev/md1p1 is on /mnt/disk1 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota) root@server:/# ls -lash /mnt/disk1/system/docker/ total 51G 0 drwxrwxrwx 2 root root 24 Mar 14 2021 ./ 0 drwxrwxrwx 4 nobody users 47 Mar 14 2021 ../ 51G -rw-rw-rw- 1 nobody users 50G May 19 14:10 docker.img root@TheSilence:/mnt/applications# ls -lash /mnt/disk1/system/libvirt/ total 1.1G 0 drwxrwxrwx 2 root root 33 Mar 14 2021 ./ 0 drwxrwxrwx 4 nobody users 47 Mar 14 2021 ../ 1.1G -rw-rw-rw- 1 nobody users 1.0G May 19 14:09 libvirt.img EDIT: "cp -R /mnt/disk1/system /mnt/applications/" fixed it. I had to manually start the docker and VM service, but they're up and running now. I am not 100% sure if I had some non standard setup somehow previously, but I do recall trying to move things to SSDs at some point. Maybe that caused the issue.

I upgraded from RC5 to RC6. Neither the docker service nor VMs are starting up. Docker service complains about /mnt/user/system/docker/docker.img VMs complain about /mnt/user/system/libvirt/libvirt.img Seems like the symlink is dead root@server:/mnt/user# ls -lash /mnt/user/system 0 lrwxrwxrwx 4 nobody users 47 Mar 14 2021 /mnt/user/system -> /mnt/applications/system This is the content. root@TheSilence:/mnt/applications# ls -lash /mnt/applications/ total 24G 16K drwxrwxrwx 1 nobody users 98 Jul 17 2022 ./ 0 drwxr-xr-x 9 root root 180 May 19 14:14 ../ 0 drwxrwxrwx 1 nobody users 442 Apr 23 09:00 appdata/ 0 drwx--x--x 1 1000 users 14 Nov 25 2020 docker/ 0 drwxrwxrwx 1 nobody users 38 Jan 14 19:21 domains/ 24G -rw-r--r-- 1 root root 24G Mar 14 2021 hassio.qcow2 0 drwxrwxrwx 1 nobody users 264 Jan 14 19:17 isos/ 0 drwxrwxrwx 1 nobody users 124 Jun 21 2022 sync/ And it's on a mount:

I browed the thread and tried to figure out the significance of /tmp. I couldn't really find anythning obvious, so just as a quick recap for the technically inclined On my unraid setup, /tmp is not obviously backed by a ramdisk or anything too fancy: root@nasbox:~# mountpoint /tmp/ /tmp/ is not a mountpoint It's just a regular old folder on the 'root' filesystem. On unraid however, the root filesystem is running in RAM itself: root@nasbox:~# df -h | egrep "/$" rootfs 16G 887M 15G 6% / That would indeed help a bit with performance. In this case, mounting /tmp would basically do the same as mounting /dev/shm to /transcode I prefer /dev/shm/ since /tmp has a bunch of other things that I don't think Plex needs to have access to