strike

it's a permanent change as it gets written to the config file on the flash drive

Did you try what's mentioned in the 6.12.0 release notes? Crashes related to i915 driver We are aware that some 11th gen Intel Rocket Lake systems are experiencing crashes related to the i915 iGPU. If your Rocket Lake system crashes under Unraid 6.12.0, open a web terminal and type this, then reboot: echo "options i915 enable_dc=0" >> /boot/config/modprobe.d/i915.conf Setting this option may result in higher power use but it may resolve this issue for these GPUs.

You could use tailscale or zerotier, but personally I would do this just for the ease of use and access: https://www.youtube.com/watch?v=RQ-6dActAr8&t=2s

Sure, it's pretty straight forward. You just have to do some manual moving of your files to the new share. If you do it right the move should be instantaneous. Since all you want to do is to move your files to a new share and not to a new disks. If you're familiar with midnight commander you can use that,it's included in unraid. Just type mc in the terminal. I think the best way would be to enable disk shares and move the files disk by disk to ensure they don't move to another disk. Depending on your file structure it shouldn't take to much time. Just set up the new share and all the folders, then move your files to the appropriate folder in the new share. As I said the move will be instantaneous, if you do it right. Just make sure you DON'T (!!!) move from a disk share to a user share or vice versa. If you do that you can have data loss.

The benefit with one share is that you can use hardlinks. That won't work with multiple shares as hardlinks only works within the same share. https://trash-guides.info/Hardlinks/Hardlinks-and-Instant-Moves/ One benefit I can see with multiple shares is you can set up different split levels, if you care about that sort of thing. But I think the ability to use hardlinks is much more useful.

Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md Also what network type do you use? And are you using VLAN?

Have nothing to do with the delugevpn version. https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=1277577

Yeah, the speed is going to be affected and you probably won't be able to seed.

I use airvpn with openvpn and have no issues. I always get the dedicated dns servers when I check https://ipleak.net/ Edit: But I don't have the name server variable in my template. Never needed it.

That looks good. Not sure what's causing your issue. But you should close the port on your router. When using a vpn you have to open up the port on the vpn side and not your router. You have to check with your vpn provider if they allow port forwarding and if so set that up. When you have set that up you put that port as the incoming port in deluge.

Can you post a screenshot of your container volume mappings and a screenshot of the downloads settings in deluge?

Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md Also post what network type you're using.

And you have checked that your output/input ports are set up correct according to the FAQ? If you have, I'm out of ideas.

Do you by any chance use the vpn container of qbittorrent on a custom network? I've had a weird issue for some time where radarr/Sonarr are unable to connect to deluge unless I connect over privoxy which is enabled in DelugeVPN. I'm on a custom network tho which isn't officially supported.

Did you change the dns servers in the container template? Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Then we have to agree to disagree. I'm talking about how the parity in the unraid array works today. If you want to discuss what you want the parity to be then I agree with you. It would be nice to be able to recover a corrupted file from parity. But I don't see this changing for the unraid array in the foreseeable future. And to achieve what you want you can just set up a zfs redundant pool. Unraid now have the best from both worlds. You can back up your unraid array to a zfs pool if you want. Then all your files are protected from bitrot, even if the unraid array parity can't fix it. But this would just be a backup like any other backup, which is a must for important files anyway.

It looks that way yeah. The parity is there in case of disk failure as I mentioned earlier. It can't recover a corrupt file any more than it can recover a deleted file.

No it doesn't make sense. Why do you assume the emulated disk holds a healthy file? Where does it magically pull this healthy file from when it doesn't exist anywhere else? In a rebuild unraid can recover all the data from the emulated disk, that includes all the bits of a corrupted file as well. So if disk 1 has a corrupted file and you pull that disk, replace it with a new one an rebuild, the new disk will still have the corrupted file.

I feel like I'm only repeating myself. There is no spot where the file start or ends on the parity drive. The parity drive only holds the answer to the parity calculations for all the disk. And in order to get the answer you must first ask the question which represents all the other disk. So if one disk dies we can ask the question with all the drives and get the answer from the parity drive to calculate the correct data to rebuild. But when a file is corrupt so is the answer/question and it can't be answered. I don't think I can explain it in more ways than I already have, so I give up What the future holds no one knows, but I doubt it.

I think you answered your own question here. The unraid array consist of multiple disks, but each disk has it's own filesystem. The array just pools all the disks together so you're able to access them all in a pool. So the data only exists on that single disk. Disk 1 has no idea of the data on disk 2 because they are both a single disk with it's own filesystem. And the parity disk has no idea about the data on disk 1 or 2 either unless it checks all the blocks of all the other 8 disks in the array, only then can it recover a drive. And if one file on disk 1 is corrupted, that data does not exist anywhere else. It's not in the parity disk, it could be on disk 2 (theoretically) if you have a copy there as well, but that doesn't matter because disk 1 doesn't know about the data on disk 2 so it can't recover the data on disk 1 with the data from disk 2 anyway other than copying it back to disk 1 that is. So if the data from disk 1 doesn't exists anywhere else, even in the parity drive. where do you recover from? You can't, other then a backup. But yeah, watch spaceinvader one's video about the array and parity, he explains it much better then I do.

No, since you mentioned spaceinvader one's videos you should watch the video about parity. The parity is for recovery from a failed disk not for recovery of corrupted data. As I said the parity drive does not hold any data so it's not possible for it to recover any corrupt data. IF it in fact DID hold any data your theory would be possible. In order to be able to use the healing capabilities of zfs your will need to have a redundant pool like raidz/2/3 etc. Or you'll need multiple copies of the data on the same disk if using a single pool disk. But the parity disk would not be able to help you at all like I already mentioned. The unraid parity disk is not like regular raid/zfs parity.

Did you just update from 6.9.2 to 6.12.x? If so you should be following this thread: https://forums.unraid.net/bug-reports/stable-releases/no-webui-link-on-docker-containers-6121-r2505/ You could probably reach the webui by typing the IP:PORT manually in the web browser tho.

No, not for the array. The parity drive does not hold any data. You would be able to detect bitrot, but only way to recover from it is to restore from backup (which you should have anyway :)). In a zpool tho it would self heal automatically when the data is read (or via scrub), if it detects corruption.

Yeah, that would do it. You could try to change back to your other vlan and run the command you see in your log on your unraid server and restart the container. If it works after that just set up a user script with that command and set it to run at array start.

Yeah, that's not the same issue as the rest is having. The rest is having a successful start as far I can see. If your log states that you have possible DNS issues you should change your nameservers in the container template to something else, like maybe 1.1.1.1,8.8.8.8. PIA users have had this issue on/off for some time. So if you're a PIA user changing your nameservers is worth a shot. For you other guys/future posters reading this it will probably take some time to debug. So please enable debug logs and post them along with your diagnostics as well. Also write if your're using zerotier/Tailscale as that maybe could be a factor.