tbgoose

Ok cool, simple enough. I made a bit of space by clearing some VMs I wasn't using (including a 30gb vdisk). It looked like it started, and it did stuff and then errored again. Jan 16 19:49:46 tbgoose kernel: BTRFS info (device nvme1n1p1): relocating block group 30408704 flags metadata|dup Jan 16 19:49:46 tbgoose kernel: BTRFS info (device nvme1n1p1): found 2400 extents, stage: move data extents Jan 16 19:49:46 tbgoose kernel: BTRFS info (device nvme1n1p1): relocating block group 22020096 flags system|dup Jan 16 19:49:46 tbgoose kernel: BTRFS info (device nvme1n1p1): relocating block group 13631488 flags data Jan 16 19:49:47 tbgoose kernel: BTRFS info (device nvme1n1p1): found 48 extents, stage: move data extents Jan 16 19:49:47 tbgoose kernel: BTRFS info (device nvme1n1p1): found 48 extents, stage: update data pointers Jan 16 19:49:47 tbgoose kernel: BTRFS info (device nvme1n1p1): 35 enospc errors during balance Jan 16 19:49:47 tbgoose kernel: BTRFS info (device nvme1n1p1): balance: ended with status: -28 This i what the balance looks like now, did it complete? Still says 33gb is single, and 197GB is raid1. I don't get how it can now be both. I don't think I can reclaim much more space easily unless I copy off the docker.img. That kind of scares me as I would have to use the built in file explorer to move it (no krusader) and that seems to hand for large transfers. Edit: Managed to claw back a few more gbs, and it has now completed successfully. Thanks for your help. There could perhaps be a note about enospc error in the pool documentation, as from the outside there doesn't seem to be any reason why the space would be needed (as should be converting the second new device, not touching the first one). But likely more going on behind the scenes than I understand? Jan 16 20:50:31 tbgoose kernel: BTRFS info (device nvme1n1p1): found 1739 extents, stage: update data pointers Jan 16 20:50:32 tbgoose kernel: BTRFS info (device nvme1n1p1): balance: ended with status: 0 Jan 16 20:50:32 tbgoose emhttpd: cache_nvme: btrfs restore profile: raid1 Jan 16 20:50:32 tbgoose emhttpd: update_pool_cfg: 31 cache_nvme 0 Now it is working, do I need to set a balance schedule or I can ignore that?

Hi all Yesterday I added a second nvme to my main cache pool, which was one disk but set up as a two disk btrfs pool in anticipation of adding the new disk. For some reason when I added the second drive, it expanded the pool with the disks listed in single mode, not raid1. When I try to use the balance feature under the first disk I get the following errors. Jan 16 10:27:38 tbgoose ool www[533140]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_balance 'start' '/mnt/cache_nvme' '-dconvert=raid1,soft -mconvert=raid1,soft' Jan 16 10:27:38 tbgoose kernel: BTRFS info (device nvme1n1p1): balance: start -dconvert=raid1,soft -mconvert=raid1,soft -sconvert=raid1,soft Jan 16 10:27:38 tbgoose kernel: BTRFS info (device nvme1n1p1): 241 enospc errors during balance Jan 16 10:27:38 tbgoose kernel: BTRFS info (device nvme1n1p1): balance: ended with status: -28 Googling around suggest this is due to not enough space on the cache disks, but I had ~70GB spare on the original drive (out of 256GB) and as far as my research shows converting to RAID1 shouldn't need lots of extra space or anything. Not really sure how to progress at this point. I have turned off docker, have turned off vms. Regardless of whether the array is started I get the same error. This is my main cache pool which contains docker.img, libvert as well as appdata. I am not really comfortable using manual btrfs commands without someone holding my hand... Disk info showing it is btrfs

Thanks this helped me, all working on TS453-pro!

Any info on using the homepage widget Synthing Relay Server alongside this container? Docs for homepage don't explain much and reference a port I am not familiar with widget: type: strelaysrv url: http://syncthing.host.or.ip:22070 Looks like we need to set up another container for this specifically, docker compose below from here services: strelaysrv: image: syncthing/relaysrv:latest network_mode: "host" entrypoint: ["/bin/entrypoint.sh", "/bin/strelaysrv", "-listen=0.0.0.0:22067", "-ext-address=syncthing.librelabucm.org:22067", "-status-srv=syncthing.librelabucm.org:22070"] volumes: - ./volumes/strelaysrv:/var/strelaysrv ports: - 22067:22067 - 22070:22070 Can anyone help get this working with Unraid?

Hi all I have just re-spun up an instance of deluge-vpn on my QNAP using docker. Hopefully you can still offer support even though I am not on unRAID. I used to use your docker but had a few issues getting it started again after a hiatus and have only just got it back up. The issue I am having, is that even though I have specified umask=000 as a variable, I am getting file permission issues in both Radarr and Sonarr. I am using PUID=0 and PGID=0. I like keeping it simple as its just media files, not that important. The errors I am seeing make it seem like the umask env variable is not being acknowledge (redacted file name). Import failed, path does not exist or is not accessible by Radarr: /data/complete/Movies/xxxx Import failed, path does not exist or is not accessible by Sonarr: /data/complete/Series/xxxx My full docker run command is as follows. docker run -d --cap-add=NET_ADMIN -p xxx:8112 -p xxx:8118 -p 58846:58846 -p 58946:58946 --name=delugevpn -v /share/Downloads:/data -v /share/Container/container-config/delugevpn:/config -e TZ=xxx -e VPN_ENABLED=yes -e VPN_USER=xxx -e VPN_PASS=xxx -e VPN_REMOTE=xxx -e VPN_PORT=1198 -e VPN_PROTOCOL=udp -e VPN_DEVICE_TYPE=tun -e VPN_PROV=pia -e STRONG_CERTS=no -e STRICT_PORT_FORWARD=yes -e ENABLE_PRIVOXY=yes -e LAN_NETWORK=192.168.1.0/24 -e NAME_SERVERS=8.8.8.8,8.8.4.4 -e DEBUG=no -e UMASK=000 -e PUID=0 -e PGID=0 binhex/arch-delugevpn Any idea what I can do to fix this, other than monitoring downloads and manually changing permissions...