JonathanM

You know you are supposed to take your hand OUT of the door jamb before you shut the door, right? :'( Actually went to scoot my wheeled chair forward a bit and my bum lost traction and I wound up on the floor. (After all these many years I've still got a baby smooth bum ) Nekkid coding? That explains a lot!

You know you are supposed to take your hand OUT of the door jamb before you shut the door, right? :'(

Check the reported size in bytes and see if it matches the normal 8TB size. If it's smaller, it could be either HPA, or the USB interface doing some funky translation, or it's simply a totally different model. Either way, if it's smaller, the only penalty is to make sure you never try to use it as a parity drive. The small size difference won't hurt anything if it's a data drive.

Very seriously doubt it's personal, just business. The amount of effort to develop and properly support it doesn't look to be worth it compared to the added benefits given the use cases presented right now. The number of people showing interest really is pretty small compared to the people wanting better VM and docker support. Features in unraid tend to be worked on based on perceived need, so if more people want a feature, that's where the limited development and support tend to go. Give it time, and maybe iSCSI's time will come. We lobbied for years to get UPS support, external notifications, dual parity, etc added. Now we have all that plus VM's and dockers.

Keep in mind that applications can force a specific download directory when they send a torrent automatically, so you need to make sure any apps sending torrents are also set to /data, and their docker mappings for /data are set to the same mount point in unraid as deluge so they can find the finished files.

Perhaps you could include the relevant apache and nginx sample reverse proxy configs in the documentation of each of the containers? Maybe even in the overview section of the template?

They are inside the container. You need to read up on docker exec.

I could be wrong, but what I think the bald one was getting at was the "out of band" encryption issue. If you allow your secret key to be accessible through an externally available web page, you have just potentially weakened your VPN by allowing a hack that penetrated NGINX to also access your VPN secret key. With any encryption scheme using a public / private key system, you should restrict access to the private key to the absolute minimum possible.

Just promise us this: when you abandon Unraid/VB as an OVF-compatible virtualization/storage platform, tell us where you went so we can follow along :-) There are other reasons to use virtualbox, but OVF works just fine with unraid's built in KVM manager. Frankly it's less work to extract and use the disk image from the OVF archive in KVM than it is to install and use the virtualbox plugin. The automatic disk image selection in unraid doesn't pick up the ova or vdi file, but you can easily type it in to the selection box and it works fine.

192.168.122.x is the default virbr0 address.

File system content, corrupt, formatted, blank, or whatever, will never cause a red ball. The ONLY thing that causes a red ball is a requested write to the drive fails. It could be a controller error, a bad or poorly connected cable, or an actual drive failure.

Instead of VPN'ing the whole server, I'd recommend using binhex's VPN enabled download clients, there are several variants available.

Shot in the dark, but what happens if you remove the comma after www in subdomains?

Not belated, but rather delayed Apparently the delay was set for 1 week. ;D

At this point, setting up nginx is just another troubleshooting tool we can use. If it works with nginx, then probably the issue lies with apache. It it doesn't work, then something is up with the nextcloud config. At least then you can concentrate on one or the other. Right now, it's rather difficult to tell which one is giving you a problem, apache or nextcloud.

At this point, how married are you to apache? If it were me, I'd temporarily stand up a letsencrypt nginx docker and see if that works any better. Just be sure you don't have both apache and nginx running at the same time, and you should be able to seamlessly swap between the two for testing. It really doesn't take long to set up, WAY less time than you've already beat on apache at this point.

No.

Unless you are an ISP or a large organization, you don't own any public IP's. And no, you can't get SSL certificates for things you don't "own".

If someone wants to migrate to this container, what differences are there between this and the Nginx-letsencrypt by aptalca? Does this container have Perl-FastCGI baked in?

What mount point are you currently attaching to? If it's not /mnt/disks/* then you won't be able to use UD.

Here is what seems to be the relevant log entries that probably indicate my issue. Haven't really researched it yet, but a few of the google hits seem to indicate it's something specific to alpine. I do know the trouble started after the rebase. Nov 4 08:53:04 AVFiles kernel: forked-daapd[18560]: segfault at 2ae072c78000 ip 00002ae072b20c29 sp 00002ae072c6d618 error 6 in ld-musl-x86_64.so.1[2ae072ad1000+88000] Nov 4 08:53:57 AVFiles kernel: forked-daapd[30009]: segfault at 2b99baa13000 ip 00002b99ba8bbc29 sp 00002b99baa08618 error 6 in ld-musl-x86_64.so.1[2b99ba86c000+88000] Nov 4 08:57:17 AVFiles kernel: forked-daapd[30685]: segfault at 2b64ecd5a000 ip 00002b64ecc02c29 sp 00002b64ecd4f618 error 6 in ld-musl-x86_64.so.1[2b64ecbb3000+88000] Nov 4 09:07:34 AVFiles kernel: forked-daapd[405]: segfault at 2b446d161000 ip 00002b446d009c29 sp 00002b446d156618 error 6 in ld-musl-x86_64.so.1[2b446cfba000+88000] Nov 4 09:17:39 AVFiles kernel: forked-daapd[10512]: segfault at 2b813658a000 ip 00002b8136432c29 sp 00002b813657f618 error 6 in ld-musl-x86_64.so.1[2b81363e3000+88000] Nov 4 09:27:54 AVFiles kernel: forked-daapd[20966]: segfault at 2abbcfeab000 ip 00002abbcfd53c29 sp 00002abbcfea0618 error 6 in ld-musl-x86_64.so.1[2abbcfd04000+88000] Nov 4 09:37:59 AVFiles kernel: forked-daapd[31065]: segfault at 2ad7ab9db000 ip 00002ad7ab883c29 sp 00002ad7ab9d0618 error 6 in ld-musl-x86_64.so.1[2ad7ab834000+88000]

Looks ok. I never had any issues except the warning, so I'm not sure there ever was a widespread issue, probably just some specific indexers would have problems.

Retune https://play.google.com/store/apps/details?id=com.squallydoc.retune&hl=en Works fine... When the container is working. I had a working setup I use occasionally several weeks ago, it seems to be broken at the moment. Don't know if it's related to the current support case or not.

Yeah, just noticed that. Would it make sense to use different ports as defaults for each docker? No. There is no need or benefit for a typical user running multiple instances on different ports. Only one privoxy should be running at a time, no matter how many of binhex's VPN enabled containers you are running. If you are advanced enough to utilize multiple instances, you have to know how to set up ports anyway.