Espressomatic

IMO, you'd handle that with overrides/hosts list on a DNS resolver like Unbound.

For iOS you'd have to use whatever tools the system offers you, unless you want to be restricted to share access within a specific app. No third-party app can have privileges to mount resources that are then available system-wide. I'm sure there must be multiple alternatives for Windows, but as Windows allows you to map network drives by default and restores them on every boot (unlike MacOS), I've never really looked.

Whether you're using NFS or SMB on MacOS, I strongly recommend checking out Automounter from Pixeleyes to manage your share connections. The reduction in frustration alone is worth the low registration price. In addition to managing your mounts, it can mount/unmount when triggered by network connection and other parameters. https://www.pixeleyes.co.nz/automounter/

Yacht generally shows all of the info from Unraid's Dockerman setup:

You can use Yacht or Portainer to make it easier/faster to make edits to vairables right now if that works for you. Not the same as editing a raw text file but quite a bit faster with many less clicks than Unraid's UI. In portainer you can also load (import) env files containing multiple definitions at one time.

Not from the appdata hierarchy, no. That persists when you reinstall containers. Are you sure you don't have multiple JD folders in appdata with different names?

How would this work? Certificates are issued for domain names. Docker containers don't know anything about their domain name, that's the job of DNS. A Reverse Proxy, with for example, Certbot, solves all these issues, including procuring certs on a schedule. But even that still needs a hosts list on your machine or DNS entry to direct a FQDN to an IP address. If you read the info for the step-ca local CA being talked about in this thread, you'll see it still needs all these other services, cerbot, reverse proxy, DNS resolver.

Yes. The way I do it - sort of, because I have 6 ethernet ports: Run each bridged (no bonds). The bridge for the one Unraid is using (primary, eth0) gets assigned to LAN and the other to WAN, in OPNSENSE. Ignore the description in my screenshots, the parts in braces describe the physical ports location/labels on my specific system/enclosure. In this axample above, I'm using one of two 10G ports and one of four 2.5G ports. In my specific setup, I'm now assigning an additional 10G port as well, but that's not necessary. So I have Unraid running one 10G port and the LAN at large running a different 10G port. But I used to have them one and the same. In the VM config, you assign the "br" bridges as two virtio devices (4 and 5 in my case, likely 1 and 2 in your case)

or some combination thereof for at least one file pattern you know you downloaded. It's probably somewhere under the .../appdata/jd* folder

I'm pretty sure that qualifies as one of the big tech companies - it's owned by Microsoft. To run without oauth you can run your own Headscale. The best way to do that is to use your domain connected to a vhost/VPS running somewhere out on the inernet, and then run docker there, and install headscale plus a reverse proxy. But, you should also be able to set up your own authenticator (OIDC) like Authentik and tie Tailscale to that. I recall it being listed at the bottom of the options when first signing up. I'm sure it'll take a deep dive into the documentation to set up.

You won't be able to access an IP on a different subnet - as you've noticed. It's possible with some changes to router settings on something like pfSense, but in general, that's the reason you can't access Home Assistant. You need to make sure it's on an interface that gets IP addresses from your normal DHCP (your router). So a network bridged to a real LAN port on the machine like I mentioned, or a host port like you mentioned above.

Yes, it's the fault of Unraid for your hardware issues. I typically don't reply to pity-party emails -but yeah, it's your party, cry if you want to. Just don't blame Unraid for your apparent apathy to anything not catering to your self-imposed misery. unRAID 6.9.0-beta25 I really hope that's some kind of inside joke or a signature you just haven't touched for over 3 years.

IMO, if you're corrupting your boot disk on a regular basis, unless you have a bad USB controller, it doesn't matter if you're using USB drive or SSD. Likely you have bad memory and you'd corrupt any/all boot devices regardless of what bus they're connected to. For every person with a USB-based issue there are likely a thousand without such issues. My four Unraid systems have no issues with USB and no issues with USB keys, no matter the price, no matter the BUS (2/3). It's SOLID. Same USB drive since 2018 here, another from 2020 and a couple from earlier this year, tiny little Sandisk cheap ones. But catastrophes can happen and that's another reason Unraid works so well. A restore from backup takes a minute to a new USB drive and then booting brings everything back online - a new license is automatically installed after confirming an on-screen prompt at startup.

I don't have any experience with this container for setup, but WRT Home Assistant, it's always been as simple as downloading their image, configuring a basic VM (OVMF bios!) in Unraid and firing it up. IMO, the most important part of the VM config to not overlook is this: Always Bridge network. The one potential hiccup can be at startup, where Unraid may not boot the image - that can be solved by turning off Secure Boot in the boot manager. Once it boots, it always gets an IP - if it doesn't then something's wrong with one's DHCP server or Network config in Unraid isn't set up correctly (br0 bridge).

Hmm. Is it possible to put other illegal characters in there? That's a bug either way.

I love when people say they want nothing to do with Google and then run a Chromium browser, where Google is responsible for almost 100% of the code that actually does anything to do with browsing. I wish there was something new to run, with a completely different base. At the moment we have 3 shit-sandwiches served with a couple of dozen different condiments. So I've given up on taste testing. Just in case the above is not obvious, Chrome/Chromium/Edge and all derivatives are 100% absolute GARBAGE. Unless you're getting paid real money to use one of them, stay away. Firefox and all derivatives are 100% GARBAGE. Safari is about 50% garbage, making it by far the best browser platform available with 0% chance of the other two ever catching up regardless of how much money is ever poured into them. But, it remains unusable as a daily driver because it can't run uBlock Origin and a number of other absolutely critical plugins to augment missing features. Period.

Just to get deeper into the weeds, if you wanted to avoid running a dedicated reverse proxy but DO intend to run Tailscale for secure VPN access, you can use Tailscale to obtain and server certificates via its MagicDNS feature. I thought I recalled reading about this, so I went looking for it again this morning to confirm... Details: It looks like Tailscale has built-in support to obtain a certificate from Let's Encrypt. And using its MagicDNS, it can serve this certificate to your browser so it doesn't complain when visiting the URL in the cert. In other words, Tailscale already does encrypted VPN, but a browser needs a TLS cert. Use Tailscale for both: https://tailscale.com/kb/1153/enabling-https IMO, this is more work on the long-term than using a reverse proxy and isn't nearly as scaleable. Might be a good solution if you only need to do one or two domain names and don't care that you can't use your own custom FQDN (it uses the tailnet name).

Every day seems to be a learning opportunity. This is more likely a solution or better workaround to someone else's requirements. It doesn't address needing to run Tailscale on all machines. It looks like Tailscale does have built-in support to obtain a certificate from Let's Encrypt. And using its MagicDNS, it can serve this certificate to your browser so it doesn't complain when visiting the URL in the cert. In other words, Tailscale already does encrypted VPN, but a browser needs a TLS cert. Use Tailscale for both: https://tailscale.com/kb/1153/enabling-https IMO, this is more work on the long-term than using a reverse proxy and isn't nearly as scaleable. Might be a good solution if you only need to do one or two domain names and don't care that you can't use your own custom FQDN (it uses the tailnet name).

This was in the message you quoted: Red text "of course you can" in reference to the repeated mention that no internet connection is needed for VW.

OF COURSE YOU CAN There is definitely a disconnect, because I've said multiple times already that what you want is possible - when installation and setup are finished however, you need to use HTTPS for encryption features. If the Vaultwarden docs had been scanned/followed, I don't think there would be a question about this. #1 issue is likely that VW is set up to start on port 80 and that browsers won't use cryptographic features on HTTP - that what prompts the error - VW won't have access to features it needs from the browser. You should use certificates through a reverse proxy. It's not only insanely simple and robust, it's going to be future-proof for whatever browser you use. It's infinitely easier than trying to manage certificate installation and/or procurement from multiple different machines/containers. In a pinch you can also generate self-signed certs with some super long lifetime. Using a certificate doesn't mean you put the Vaultwarden machine on the internet. It doesn't need a path to the internet at all if you only want to connect to it locally. Certs live on your NPM machine, not Vaultwarden machine. If you didn't want to use NPM you could manually copy/install certs from any other machine. Every bit of information and instruction to accomplish all of this is available here in the forum. You're just in the wrong thread right now. Consulting threads specific to the different containers is recommended. 1st, NPM, 2nd, Vaultwarden - optionally 3rd. Tailscale (only if you ever want to connect to services from outside your LAN) I'll repeat myself again (and again). You seem to have started down this path without first outlining and making clear what you want to do, instead getting tripped up in all the minutiae that would have otherwise been ignored as part of an otherwise very simple install and setup process. Vaultwarden is one of the easiest services I've ever set up using Unraid.

It's obviously that you've never written, let alone (and more importantly) tested, a single line of code. If the requirement to perform a 60 second installation of a plugin and/or fan control driver is the biggest complaint against a project/product, I'd say it's a certified winner. What I find truly amazing, and staggering, is that I haven't noticed requests for the inclusion of thee drivers mentioned in the future features thread(s).

They're working on it. The amusing irony of mentioning HexOS, is that Unraid is the de-facto inspiration for that thing. Because obviously TrueNAS isn't suitable as-is. HexOS is where it is because 1. every functional part has already been done for years in the form of TrueNAS and 2. people like Linus of LTT have thrown a ton of money at it - he's invested at least $250K that's been publicly disclosed.

The bottom line is that you can't easily port settings from one instance to another. The easiest thing to do is to make a full/complete backup and restore. There are a lot of config files in a number of places, plus database files. Lots of encryption keys and other settings, if anything is mismatched, it leads to unrecoverable errors and things break. Some of those cause the entire UI to go tits-up. NPM is like a delicate and elaborate castle made of loose playing cards. If you don't look at it the wrong way, it's reliable. Start to poke under the hood too much and.... As an aside: I'm sure that Caddy and Traefik are far more reliable and robust alternatives for anyone interested. It's just that they've been designed to be impossible to understand, even for people who claim to be experts on the topic, and near-impossible to install correctly for anyone else. So that's why I also continue to use NPM.

I hope this reply is read as it's intended - somewhat hyperbolic and mildly entertaining, but still trying to make a reasonable point. I'm confident now that you've misunderstood the purpose of both a reverse proxy and Tailscale. One in no way replaces the other for any purpose/outcome. Let me make the blanket statement again: Vaultwarden does not need an internet connection at all, nor at any time after it's set up. Literally never. With or without SSL. I don't mean to be pedantic, but this "offline" meme is getting frustrating to the point of exhaustion (not just here). You need an internet connection to do things like download. How will you download Vaultwarden or anything else without an internet connection? You need an internet connection to participate in a global forum like this one - how can you do this offline? So, let's agree that at some point, everyone needs an internet connection to do at least SOME things. So, internet required to download and set up Unraid. Download Vaultwarden. Download certificates. See, the cert is just like anything else you don't have or make yourself - it needs to be downloaded. But you can do that on any machine, from literally anywhere. You can download certs on your phone. On a Commodore 64 running a WiFi modem adapted to its cartridge or serial port. You get the picture. What doesn't need to ever have an internet connection, is the machine running Vaultwarden. You copy the cert to that machine on your LAN or you serve it and then proxy VW with a reverse proxy. You absolutely do NOT use Tailscale at all for any reason to accomplish any of this. It's of no use whatsoever for LAN-only. The entire point of Tailscale is to be a secure tunnel between the LAN and one or more devices outside the LAN (somewhere beyond the WAN) - aka the "internet." So "offline" doesn't factor into the Tailscale discussion and Tailscale doesn't factor into the offline discussion. If you 100% want INTERNET, then Tailscale is for you and this is the thread. If you 100% don't want INTERNET, then Tailscale is not for you (at all) and this is not the thread. It sounds to me like you need to stay away from Tailscale like a communicable disease. Recognize it exists, don't worry about its inner workings, just know you don't want it. Now if you intend to run any services whatsoever on your LAN you absolutely want domain resolution and for some services you may want secure certificates. You can do this a bunch of ways, but the absolute easiest is to kill multiple birds with one stone and use a reverse proxy to map domain names to IP+PORTS while ALSO obtaining and serving certificates. Obtaining valid public certificates requires downloading them from the internet. If you don't want to use the internet for this, on any machine, then you can use self-signed certificates which will work for some, but not all services, or you can also run, as EDACerton mentioned, your own certificate authority - which you then also have to manually trust in every browser that will access a certificate it verifies. IMO, good luck with this, because the info available for it is far less readily available and you'll need an internet connection to find/access it anyway. Serving a self-signed cert with NPM is otherwise super simple - just select it from the menu. So let's say that this all gets set up and is now working 100% "OFFLINE" - What's the point? How is an offline instance of Vaultwarden going to help you? What passwords and login credentials is it going to store that you will only use OFFLINE on your LAN? OK, maybe you have a lot of secure services that you use locally and need to keep locked down with different an elaborate passwords - fair enough. But maybe you intend to use Bitwarden clients ON-LINE while Vaultwarden itself is completely cut off from the inernet? Sure, that can work, but only while you're at home. Once you're outside the LAN, Bitwarden clients will no longer be able to access Vaultwarden and therefore become useless. Remember Tailscale? Nevermind, forget about it. I've come long enough into this reply that I've already forgotten why I started it and pretty soon I'll be discussing something completely unrelated like Immich or suspension geometry. Clearly outlining a goal would likely have made for a really short and quick suggestion at some point in the past which would have avoided the entire Tailscale discussion, possibly also anything about reverse proxies. You never know, maybe a plain text file on an encrypted disk volume could have been floated as a replacement for Vaultwarden. At the end of the day, it really seems like a piece of software expressly designed for anywhere connectivity is trying to be used for an as-yet unknown purpose.

That can't work to solve the problem unless he also intends to write all his own software from scratch, without so much as referencing existing code. And certainly posting here about it will be equally impossible. Unless he also hosts an offline forum and we all show up at his house to post in-person on his LAN.