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.

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.

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.

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

Read my comment again, it has the answer. Most VPN services do not provide end-to-end tunnelling. If the exit node is located outside Russia, then what enters the Russian internet will be simple HTTPS traffic.

Been running it from Russia where stock WireGuard stopped working mid-2025.

Sounds like the issue is ISPs within Russia blocking outgoing Wireguard traffic from customers.

If the traffic exits the tunnel without hitting a Russian ISP (e.g. a Mullvad exit node in Sweden that routes the unencrypted traffic to the destination), you won’t be affected. If the exit node is behind a Russian ISP, it might get filtered by DPI depending on which direction is subject to the filter.

It’s problematic, but possible: https://jamesguthrie.ch/blog/multi-tailnet-unlocking-access-to-multiple-tailscale-networks/

If the other person has a Tailscale account, it sounds like the most expedient method is to simply invite them to the tailnet as a non-admin user with strict access control.

You could share a node with an outside user, but I don’t know how much the quarantine would affect its functionality. You could also use Funnel to expose the node to the internet (essentially like a reverse proxy), but there are obvious vital security considerations with that approach.

deleted by creator

Three important factors:

• Gigabit ethernet
• SATA-attached storage
• My family not knowing what the fuck USB 3.0 is, and why blue USB is better than black USB.

Mine is using a network share to transfer files faster than any USB device we have at home.

Realistically, is that a factor for a Microsoft-sized company, though? I’d be shocked if they only had a single layer of redundancy. Whatever they store is probably replicated between high-availability hosts and datacenters several times, to the point where losing an entire RAID array (or whatever media redundancy scheme they use) is just a small inconvenience.

This is not meant for human beings. A creature that needs over 140 TB of storage in a single device can definitely afford to run them in some distributed redundancy scheme with hot swaps and just shred failed units. We know they’re not worried about being wasteful.

I’ve had good experiences with Rustdesk. The client is open-source and the no-cost server components (ID and Relay servers) are self-hostable. The remote server works on X11 and Windows. I use this script to run XFCE+Rustdesk in a headless session:

export SERVERNUM=69
export SCREEN_SIZE='-screen 0 2560x1440x24'
export DISPLAY=":${SERVERNUM}"
export XDG_SESSION_TYPE=x11

xvfb-run --server-num="${SERVERNUM}" --server-args "${SCREEN_SIZE}" startxfce4 & disown
sleep 1
flatpak run com.rustdesk.RustDesk & disown

Sunshine + Moonlight is also a good choice. I have Sunshine installed on a box at home and use Tailscale to connect to it from the Moonlight client. At 1440p 60 FPS it has no visible compression artifacts and responsive enough for gaming.

tl;dr: yes, credentials are cached locally. https://github.com/dani-garcia/vaultwarden/discussions/4676

The major downside to the single file storage used by Keepass is that it’s easy to accidentally create a conflict between files on different devices if they’re not synced immediately. Conflicting files have to be merged manually or data might be lost. I’ve run into this several times with Keepass + Nextcloud. In comparison, a central master database with local cache can resolve conflicts between individual records.

deleted by creator