JonathanM

Try using the NUT plugin instead?

This.

Why bother? It's going away when you remove the drive anyway.

Enable nat loopback, hairpinning, reflection or whatever your router calls it. Nothing you do to this container or unraid will fix it, you must get your router to cooperate.

No point in shopping for a UPS until you know the max power draw of the server, and the unplanned clean shutdown time needed. Once you know the watts, and time a shutdown with all services running, find a UPS with at least double the time at the given wattage. The UPS you listed shows this... Watts Minutes 50 55.8 100 21.9 200 8.8 300 3.8

@GuildDarts,I have a really pedantic observation, act on it or not, doesn't matter. It's becoming common usage anyway, regardless of accuracy. The applications managed by the docker engine are containers. Dockers is a clothing brand. To be technically accurate, the label referenced in this report should be "Containers" not "Dockers"

What is your power draw during parity check?

Unless you have a backup of the libvirt.img file or the xml's from before, I suspect your only way forward is to redo the settings. Your domains share contains the hard drives for the VM's, so all your data is still intact, but the xml settings for the VM's live in the system share, and apparently that was created fresh recently for some reason. Create a new VM, but in the primary vdisk, select manual, and select the vdisk.img file that you are wanting to bring back.

Is it mounting properly? Did you reconfigure it at any point?

Did you remove a cache drive at some point?

Bridge must be enabled.

Unraid uses RAM, it doesn't install and run from a disk. If you are talking about a VM, normally you create a file on the cache pool that is mounted as the VM's disk, so no need to separate it out. Unraid isn't RAID. Each disk in the parity protected portion of the array is an independent file system, not striped. You can use XFS or BTRFS on any of the parity array disks, you can mix and match if you want.

Personally I'm using the built in FTP in a very limited role, LAN only, as a destination for a AIO network scanner function. I'm not comfortable making the blanket recommendation that what I'm doing is ok. If you are allowing access to your LAN by any device that could be exploited, Unraid's FTP is pretty much wide open since the credentials are easy to sniff. Why is FTP a requirement for you? Can you accomplish the task some other way?

This. USB is the worst possible choice for external drive connections. SAS and eSATA are the only consistently reliable ways to connect to hard drives in a separate enclosure.

It's not unraid, it's the spec for the processor / motherboard.

Updated the latest nightly, and again, all subs are gone after the update. Which db file in the appdata is supposed to hold sub data? The db.json file has this "subscriptions": [], I've attached the dropdown on one of the videos, no "go to subscription" present. The info gives what looks to me a normal result The subscription page

Read this thread.

Sorry for the misunderstanding, I thought I was in the undervolting power save thread.

Possible reduced stability. It's almost like the inverse of overclocking. Circuits are designed and tested to run at spec, deviate and you risk bit errors. Depending on the quality of your specific silicon you might be fine, but you don't know for sure. How valuable is your data integrity? See @mgutt's reply, I was referencing undervolting, wrong thread.

Read this thread for more about why that's possibly a bad idea.

Sorry, I have no experience with proxmox.

That's not entirely true. The GUI editor only sees img, but you can manually specify the name of the vmdk in the XML. Just don't make any changes in the GUI editor, it'll blow away your manual edits.

Unraid is a cut down version of slackware, specifically stripped of everything that's not needed, because it loads into and runs entirely in RAM. We don't have the luxury of just slapping every single driver and support package into it, you would end up with a minimum 16GB or 32GB RAM spec. Before VM and docker container support was added, you could have all the NAS functionality with 1GB of RAM. Now, 4GB is the practical bare minimum for NAS, even if you don't use VM's and containers, and 8GB is still cramped. Adding support for a single adapter that works well in slackware, providing the manufacturer keeps up with linux kernel development shouldn't be an issue. That way we can tell people if you want wifi, here is a list of cards using that driver that are supported. It's the blanket statement of "lets support wifi" that doesn't work. BTW, even if we do get that golden ticket wifi chip support from the manufacturer and Unraid supports it perfectly, the forums will still be bombarded with performance issues because either their router sucks or their machine isn't in the zone of decent coverage, or their neighbours cause interference at certain times of day, etc. Bottom line, wifi on a server just isn't ready for primetime yet. Desktop daily drivers, fine. 24/7/365 servers with constant activity from friends and family, no. It's much easier support wise to require wired. If the application truly has to have wireless, there are plenty of ways to bridge a wireless signal and convert it to wired. A pair of commercial wifi access points with a dedicated backhaul channel works fine, that's what I use in a couple locations.

Exactly. Name each instance so it's easy for you to figure out which database serves what. That way when something gets ornery, you can deal with only the one app. Use the docker folders app to keep things tidy if having many container icons showing causes you OCD pain.

Never, ever. Not even for a moment.