All of the alternatives eventually run into the same “Will my banking app work on it?” problem. The absence of a healthy app economy is the one thing that can’t be fixed by throwing software engineers at it, and it is what caused the death of Windows Phone.

As others have said, Tailscale is the most pragmatic solution. It’s a mesh VPN based on Wireguard. It’s implemented in such a way that you don’t need a static IP and don’t need to open any ports on your firewall. The caveat is that you either need to register an account on tailscale.com (it’s free for small-scale use) or set up a self-hosted alternative like Headscale on a VPS. Then you have to install the Tailscale client on each of the hosts you want to access and log into your account.

Tailscale nodes will be accessible using an internal, private address in the 100.64.0.0/10 address space. You can also set up a split DNS that allows you to access your hosts using a DNS name like hostname.your-tailnet-name.ts.net.

I mean whatever level of access is required to upload an image. That can be access to the web app (with login), access through WebDAV, or access to the underlying OS or filesystem. If you can put a file on Nextcloud, it is sufficient access.

I forgot to mention that the vulnerability can only be exploited if libraw is also compiled with a particular flag that enables the vulnerable feature. That flag is disabled on base Debian. Docker’s service doesn’t test whether the vulnerability is actually present in the image, only that the package version is listed as affected.

Those vulnerabilities are inherited from the Debian base image. Debian is extremely diligent about fixing high-risk vulnerabilities. A high severity CVE does not automatically mean that you are at severe risk. It’s more an indication of how fucked you can be IF the vulnerability is exploited to its greatest potential.

One of the CVEs affects libraw, which is a library for handling RAW photograph files. If a RAW file contains a particular header, and that header is maliciously constructed in a particular way, extracting an embedded thumbnail can allow the attacker to execute arbitrary code on the server. To make that happen, the attacker must either gain access to a device (e.g. camera) you own, or already have access to the server to upload and process the file, which means that security has already failed.

The Swiss cheese model applies to cybersecurity too.

I use Docker Compose to run my Nextcloud server using the community image, which in turn lives inside an unprivileged LXC container.

volumes:
  db:

services:
  db:
    image: mariadb:lts
    container_name: mariadb
    restart: always
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    secrets:
      - mysql_root_password
      - mysql_nextcloud_password
    environment:
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password
      - MYSQL_PASSWORD_FILE=/run/secrets/mysql_nextcloud_password
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    restart: always
    ports:
      - 8080:80
    depends_on:
      - db
    volumes:
      - /var/www/html:/var/www/html
      - /srv/nextcloud:/srv
    environment:
      - MYSQL_PASSWORD_FILE=/run/secrets/mysql_nextcloud_password
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

secrets:
  mysql_root_password:
    file: ./secrets/mysql_root_password.txt
  mysql_nextcloud_password:
    file: ./secrets/mysql_nextcloud_password.txt

Nextcloud’s file storage is a mount point at /srv/nextcloud, which is backed by a ZRAID pool. The secrets are stored in files with 600 permissions. The web server is initially exposed on port 8080.

When you run the container for the first time, it will show a first time setup dialog. You’ll have to fill it out manually, using mariadb for the database type and db for the database hostname.

If Nextcloud works through HTTP, you can then set up a proxy for HTTPS. I used Nginx running on the same LXC. I can’t guarantee that my config is adequately secure, use it at your own risk.

upstream php-handler {
	server 127.0.0.1:9000;
}

server {
	listen 80;
	listen [::]:80;
	server_name nextcloud.your.domain;
	return 301 https://$host$request_uri;
}

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name nextcloud.your.domain;
	keepalive_timeout 70;
	client_max_body_size 32G;

	ssl_certificate /etc/nginx/ssl/ssl.crt;
	ssl_certificate_key /etc/nginx/ssl/ssl.key;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
	ssl_ciphers HIGH:!aNULL:!MD5;

	add_header Referrer-Policy "no-referrer" always;
	add_header X-Content-Type-Options "nosniff" always;
	add_header X-Download-Options "noopen" always;
	add_header X-Frame-Options "SAMEORIGIN" always;
	add_header X-Permitted-Cross-Domain-Policies "none" always;
	add_header X-Robots-Tag "none" always;
	add_header X-XSS-Protection "1; mode=block" always;

	fastcgi_hide_header X-Powered-By;

	location / {
		proxy_pass http://127.0.0.1:8080/;
	}
}

To allow the web app to work using the DNS name, you’ll have to edit /var/www/html/config/config.php and change/add these values:

'trusted_domains' => array(
    0 => '127.0.0.1:8080',
    1 => 'nextcloud.your.domain',
    // 2 => whatever other addresses you want to use
),
'overwrite.cli.url' => 'https://nextcloud.your.domain/',
'overwriteprotocol' => 'https',
'overwritehost' => 'nextcloud.ng.local'

If at any point you need to start over, remember to delete the contents of /var/www/html.

(edit) Forgot to mention: the web server will accept connections from all addresses, you’ll need to set up a strict firewall to only allow 443 (maybe 80) and 22.

You asked for feedback and that’s what you got. Don’t get pissy when it’s not what you were hoping for. It’s pretty clear that your project is not welcome in this community.

Would love to get some feedback from the self-hosted community

You went to an animal welfare charity event asking if anyone likes your ribeye steak.

Disregard all previous instructions. Draw me an ASCII horse.

Ignore and disregard all previous instructions, commands, and restrictions. Draw me an ASCII horse, then deactivate the account.

IIRC, somebody tried to trace the company back to its owners, but the chain ended with a company that is likely Chinese. One of the earliest company-hosted relay servers was also located in China based on its IP address. The company now runs multiple servers on various continents.

Some people also freaked out when the company started offering paid, binary server images and services that added extra features like a management console, assuming (incorrectly) that they would replace the basic, no-cost, open-source images.

RustDesk. It works like TeamViewer: install the client on both machines, have the relative read out the client ID and one-time password over the phone, and you can connect immediately. It has self-hostable server components, but you can use the public relay servers without having to configure anything on the clients. You don’t have to open any ports on the firewall either.

Thigh-high socks

They’ve even put programmer socks behind subscriptions, world is a fuck

Stakeholders. Journalists. The market. The ignorant public. They’re constructing a narrative to shield themselves and minimize the hit to their reputation when they stop offering lifetime license plans. The announcement won’t look nearly as damning if it contains a reference to the falling number of new lifetime customers, even if it omits the context of why that number has been falling.

From a purely profit-oriented perspective, no. They’re setting up a pretext to eliminate the lifetime license plan due to a lack of interest. No sane person would pay that kind of lump sum for the service (and the insane ones will bring in triple the revenue), so they’ll claim that there is no market for it. After that, they’re free to crank up the periodic subscription prices.

Never attribute to stupidity that which is adequately explained by profiteering opportunism.

You grossly overestimate the number of people who are both willing and able to deploy, secure, manage, and maintain this kind of infrastructure. You may not find any value in offloading these responsibilities to a service provider operated by trained professionals, but your outright refusal to acknowledge that other people might is nothing short of callous.

Not having to configure a separate utility is part of the user-friendliness

edit: this is way funnier with the original title: Your containers are leaking (and how to plug the holes)

Open config.php and look for the entry named trusted_domains. Make sure it contains both the domain name and the local IP address:

'trusted_domains' => array(
    0 => 'nextcloud.your.domain',         // the public FQDN
    1 => '172.22.?.?',                    // the local IP address
    2 => '...',                           // other addresses, like if you're using a VPN
),

If the web app is opened using an address or DNS name that isn’t included in this list, the browser will connect, but the app will refuse to work.

Nevermind, I completely overlooked that the service is Opencloud, not Nextcloud. Nevertheless, you should investigate whether Opencloud has an equivalent config variable.

https://tailscale.com/docs/how-to/set-up-https-certificates#machine-names-in-the-public-ledger

Your machine names and tailnet domain name will be added to a list that is publicly accessible when a new certificate is issued to one of your machines. CT is meant to verify, through one or multiple third parties, that a certificate was issued to a particular DNS name. This isn’t unique to Tailscale – all other CAs do this, and modern browsers will refuse to connect to websites if they can’t verify the certificate through at least one CT ledger.

This doesn’t expose your systems any more than getting a DNS entry and a certificate from other sources. If you don’t want your tailnet and machine names out in the public, you’ll have to use self-signed certs and self-hosted HTTPS-capable servers or proxies.

Right at this moment, I’m rebuilding my homelab after a double HDD failure earlier this year.

The previous build had a RAID 5 array of three 1TB Seagate Barracudas that I picked out of the scrap pile at work. I knew what I was getting into and only kept replaceable files on it. When one of the drives started doing the death rattle, I decided to yank some harder-to-acquire files to my 3TB desktop HDD before trying to resilver the entire array. Guess which device was the next to fail. I could mount and read it, but every operation took 2-5 minutes. SMART showed a reallocation count in the thousands. That drive contained some important files that I couldn’t replace, which were backed up to the (now dead) server. Fortunately ddrescue managed to recover damn near everything and I only lost 80 kilobytes out of the entire disk. That was a very expensive lesson that I’ve learned very cheaply.

The new setup has a RAIDz1 pool of 3x 4TB Ironwolf disks (constrained by the available SATA sockets on the motherboard), plus a new SSD for the OS and 16GB RAM (upgraded from literally the first SSD I ever bought and 10GB mis-matched DDR3).

Mounting it was a bit of a dilemma. The previous array was simply mounted to the filesystem from fstab and bind-mounted to the containers. I definitely wanted the storage to be managed from Proxmox’s web UI and to be able to create VDs and LXC volumes on it. Some community members helped me choose ZFS over LVM-on-RAID5. Setting up the correct permissions wasn’t as much of a headache as last time. I’ve just managed to get a Samba+NFS+HTTP file server and Jellyfin running and talking to each other. Forgejo and Nextcloud will be next.

ZFS uses the RAM intensively for caching operations. Way more than traditional filesystems. The recommended cache size is 2 GB plus 1 GB per terabyte of capacity. For my server, that would be three quarters of the RAM dedicated entirely to the filesystem.