Opawesome

You may want to double check this 😀. I really only see instructions referring to "cache only" and "cache prefer" (i.e. versions before 6.12 if I am not mistaken) on this page : https://docs.unraid.net/unraid-os/manual/storage-management/#backing-up-the-pool-to-the-array

Tutorial was updated with the openvpn-2.5.5-x86_64-1.txz package for Slackware.

You can do it with the array started. Just click on the relevant shares (i.e. appadata, apps, cachetmp and downloads in your case) to change the setting. I think that with the newer versions of unraid, the guide is a bit outdated and the setting "use disk cache" has been changed a bit. You must set the primary storage to "cache" and the secondary storage to "array". The effect of these new settings will occur next time the mover is called, whether manually or upon schedule, meaning that all the data from these shares (currently stores only on your cache drive) will be moved to your array.

You are over thinking it 😀 (see the image)

You are in the right place 😀. I just think your syntax is wrong. You should probably set the value to: {"writedescription": true} to respect the JSON format requirement (I assumed you had already some options set up with the right format). See https://github.com/alexta69/metube?tab=readme-ov-file#configuration-via-environment-variables for the details. It says:

I indeed see "br-fccdcfbfa4d2 UP 192.168.1.1/8" in the ifconfig file of your diagnostics, which is overlapping with your 192.168.1.0/24 LAN. That could be the issue. I would try deleting this custom docker network.

Can you try maybe deleting the 192.168.2.0/8 custom docker network ? This /8 CIDR seems very wrong to me on the 192.168.X.X range, as it may overlap with the 192.168.1.0/24 network.

If the VPN tunnel is already setup and if you can ping the remote machine from your local machine via that tunnel, then you just need to connect to your remote server via its local IP address. You should be aware however that the speed of a large backup through a VPN tunnel is likely to be significantly slower than through a direct SSH tunnel.

I concur, I did this a year ago and worked flawlessly. Just make sure that all files were indeed moved to the array before replacing your cache drive.

All the available options are described here : https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/YoutubeDL.py#L183 There is indeed this option: The format to use in the docker container template would be to add the following in the "options" field (i.e.: the "Container Variable: YTDL_OPTIONS" variable): "writedescription": true

Have you tried stopping the array before enabling bridging, and then starting back the array ? Also, are your other settings the same as mine ?

You can see my hardware config in my signature below. It has been running well with Unraid for 4-5 years now. This 4U Logic Case SC-4316S case uses standard ATX power supplies, and I replaced the fans with Noctua fans to reduce the noise level even further.

Yes, it was said in the latest podcast. During the show Ed says he is just using one "4 GB" USB stick for his array on his server in order to circumvent this "limitation".

If, for example, the starter Licence is like 25 USD / year but the Lifetime licence is 250 USD.

Hi, Here are my (i) pihole docker container settings; (ii) Unraid network setting; and (iii) docker settings. They work on my system. My router is set to use 192.168.92.2 as primary DNS server address.

After updating my test server, the 'Hide "dot" files:' parameter in settings > SMB settings remained set to "no". I could not find a 'Show "dot" files:' parameter however.

I saw that from limetech:

Yes I saw a couple of questions regarding the activation codes. But none of the answers stated clearly whether their validity would be kept "indefinitely", or whether "only for a certain time frame".

I bought an extra pro licence that I activated on a test Unraid VM, but I also bought an extra basic license. Do I have to use this "basic" activation code within a certain time frame, or will it stay valid "forever" ? I sincerely apologize to @limetech for not joining the new "periodic payment" model, but I understand that the pre-announcement was also made to give the current users the opportunity to stack up a couple of extra licenses if they want to.

Well, it will depend on whether the price of the lifetime license will stay around 130 USD or increase to 250 USD or more. I am not saying that limetech would do it, but if you give the choice between a 20 USD/year subscription or a 500 USD lifetime licence, you are not really offering lifetime licences anymore. I think people fear this kind of business model shift because of that.

I have been using Unraid for 4-5 years now, and I have just bought an extra pro licence just in case I would want to build another Unraid machine in the future. Although @limetech did stated that "pro/lifetime" licences would still be offered, it might be at a significant price increase. So I'd rather be safe than sorry. As a user I obviously would have preferred that the pricing/lifetime license model stayed the same, but I also understand that Limetech is not a charity. And the least I can say, is that I don't feel having been robbed paying 129 USD for my Unraid licence.

Hi, I was wondering if adding OpenVPN would be interesting ? For those interested, here is how to do it manually yourself via the /boot/extra folder:

Oh man, I spent so much time searching for that in vain. Thank you very much !

I am bumping up this because I need an answer to complete my LUKS header restore command/script. That would be useful for the community (not only me). See here:

The script to backup works fine. It is just the automated restore command that might have issues. It just means that you will have to run the restore command manually, ie. identifying the right HD/nvme device and the right backed up header file with a command like: cryptsetup luksHeaderRestore --header-backup-file <path to relevant LUKS header backup> <device / device partition> IMPORTANT NOTE: If the disk is part of an array protected by parity, the <device / device partition> should be the managed partition device created upon starting the array in maintenance mode, i.e. "/dev/mdXp1", and not "/dev/sdY1". or else you will void the parity. For disk not protected by parity (e.g.: cache disk), pointing to the device partition (i.e.: "/dev/sdY1") seems to work better than pointing to the device itself (i.e.: "/dev/sdY") see: https://forums.unraid.net/topic/133972-backup-and-restore-of-luks-headers-on-array-data-drives/#comment-1217840 and https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md#6-backup-and-data-recovery