BVD

This should do what you're looking for: https://github.com/lukaszlach/docker-tc

I was referring to this: <NIXED - I misread> There's several others in there that have relation to this with jonp in them, though this one wasn't, apologies all!

Wow, looks awesome, and done SUPER quick, thank you so much! I don't use the animated icons, as I'd unfortunately never been able to get them to work properly on my end (idk if it's a versioning problem, one unique to my setup, or whatever the case may be lol), but had always thought they looked amazing regardless 😁 The only animation idea I'd had was something like having the center part of the icon look like it was 'dropping in', having it bounce once before settling. At first the center part is large, covering almost the entire icon tile, then it shrinks down and down till it's a bit smaller than default, finally increasing in size (more quickly than the shrink to simulate the 'bounce') till getting to the expected end size. Seemed like a neat idea, but as I don't (or can't? lol) use animated icons anyway, hadn't really mentioned 😅

It was also reported in various news outlets, such as heri. Its Plex deciding, without anyone's consent, that anyone youve shred your library with should also know what youve watched. And this is opt out, meaning you were defaulted in to it, and wouldn't uncover the setting unless stumbled across accidentally... Or after one of the people on your server shoots you an email asking about your latest viewing habits. The bigger concern for me is that it effectively shows they've 0 concern for anyone's privacy more broadly - theres nothing to stop them from doing something like this again, only never telling you, instead just selling your viewing habits to the highest bidder, and this time you'd not have someone reaching out to you so you knew to go change this new setting they implemented. SSO is single sign on - I have several family and friends on my bitwarden and nextcloud instances as well, so instead of adding yet another login they have to remember, I figured I'd set up SSO so they could log in to all three with a single account. I'm currently working on getting all their play histories synced from my Plex server over to jellyfin, and I think that'll be the last step before I start getting people migrated over. Hoping to have the Plex server taken offline by spring... At least thats the timeline ive got planned at this point lol

@hernandito Thanks so much to both yourself and @Josiah for your creative efforts here! Certainly feels nice to have added a little spice to the dashboard 💚 If you're still taking requests, I'd be very interested in a Jellyfin icon replacement, if you've the time at least? I'm using the yellow/gold set, but color agnostic as I can always change it after of course! I'd been working on laying the groundwork for transitioning everyone on my plex server over to jellyfin ever since they added 1st party streaming, but had basically set it aside for the longest time as it didn't seem *tooooo* bad due to all the effort involved - not just setting up jellyfin itself, but implementing SSO for it, compiling all documentation I'd need to communicate to the users transitioning, testing clients to do so, etc... But with the recent *MASSIVE* privacy scandal/issue, that's been the kick in the pants needed for me to pick it back up and try to get it over the line. It'd be awesome to keep the beautiful dashboard scheme with the transition 😁

Just updating here as I came across a feature request post from @jonp (ex-Limetech) which pre-dates this one. Completely missed it up until now, as it's in the "Unscheduled" sub-forum... Indicating I guess that it is something that's on the Limetech radar to be implemented at some point, right? I sincerely hope so! I really would like to move away from virtualizing UnRAID some day 😅

There's a huge amount of discussion around this, going back at least to 2015 - it was very nearly the one thing that kept me from purchasing in the first place actually 😳 I've also tried to articulate use-cases for this to justify the development effort as best I could.... I may also have... ranted... about it a bit 😅 Seems that the biggest thing keeping this from happening is UnRAID's licensing model - it's been noted that this would effectively require a complete re-write of the core/legacy OS components (array stop/start, device handling, service handling, etc). Understanding it's an utterly massive undertaking... I think it's absolutely a necessity at this point, as it's truly hampering the platform's flexibility more and more as time goes on 😓 Aaaanyway, please do upvote / comment on the feature request if you would - the more visibility we can get on it, the more people show the desire, the more likely it is to get the attention it needs to be scoped and implemented! 💚 EDIT: Looks like it goes back at least to ~2014, as a feature request by what was to become a Limetech employee 😅

This sounds like a bug imo... Someone not noticing for an extended period would need to copy everything out and back in to reap the compression benefits, and that can be a huuuuge PITA...

It'd be nice to have the image updated, esp now that docs supports dark mode, assuming you've the time available 👍

I came to the same conclusion myself... I'd previously taken issue with the fact that unraid's design means that 'everything' must be taken offline in order to address an inevitable eventuality for a NAS - adding storage, replacing a failed drive, or expanding capacity with larger disks, these are the kinds of things that are expected to be semi-regularly undertaken with any NAS, and unraid is the only OS I've seen that *requires* down time for even the most basic maintenance. The fact that it can be solved any number of ways (several of which have already been proposed which are completely viable), but hasn't had a whisper from LT has been... Difficult.

I think what you're experiencing is Confirmation Bias. And you sort of side-stepped my point, but that's alright, we can run with it - Yes, a good number of people want VM snapshots and backups in the UI (and absolutely, it'd be a valuable feature) - no, it's not all, nor even a majority (as we can tell from the poll results here). When it comes to unraid user engagement, reddit is a ghostland compared to these forums. VM backups are quantifiably less desired by the unraid user base than... Well, multiple arrays in this case. I'd argue that the 'biggest reason' people move to virtualize unraid is actually two separate reasons - if you read through the history of this forum, the years of posts that've come through within that time, there are two recurring themes: The handling of licensing is *extremely* annoying - having to effectively 'turn off my NAS' to replace or add a drive is utterly absurd. And worse, now that ZFS is 'included', you have to shut down everything in order to do any work on it as well. Any NAS OS should be able to remain online for anything short of a (non-media) hardware failure, or an OS update. This is a pretty huge failure in design IMO. Having to work around all the various "unraid-isms" - if you want to make anything persistent, it takes a bunch of extra steps to do so, steps that are unnecessary on (literally anything else). Even simple things like keeping your bash history, installing a package, they're all so unnecessarily complicated that folks effectively 'graduate' to another OS. Used to be any user could easily recompile the kernel after installing whatever packages they might find useful to them, now you have this location you have to put the package, and wait for unraid to re-install it each time you reboot. More down time (see licensing above). Just a million little cuts like this. In the last 6 months, all of 9k people have downloaded the macinabox image - across all of dockerhubs users, not just unraid. This isn't as common as you seem to be alluding to. In 4 years, it's had ~2.5m pulls, again, across all of dockerhub - how many of those are folks updating to a new image? Or pulling another copy on another machine? What percentage of docker users are also unraid users? If you can show me verifiable numbers that say otherwise, I'm absolutely open to them, and my apologies in advance if so; I just don't believe unraid users running macos in a vm alongside a windows vm is nearly as common as those simply running windows machines, especially given the OS's target audience. As for corporate doublespeak... Lol? I don't know how to respond to this honestly, and I don't mean to be rude here, it just feels more like someone lashing out than working to justify their position in a logical and reasoned way...? I don't have a horse in this race 🤷‍♂️

+1 !!!! Whole reason I'm still on 6.11.5 😅 Really wish I'd thought of this being an issue beforehand - I'd not have agreed so strongly for its implementation lol 🤣

This definitely isnt the only reason one might choose to virtualize unraid on proxmox... But as I understand it, your point is that "all NAS operating systems should have native virtual machine backup utilities" - is that correct? Assuming yes, I'd frankly disagree. Unraid's primary target audience (I believe) is the average home user who's looking for an efficient NAS OS, and the "average" consumer's main usage for a VM would *typically* be relegated to a windows gaming machine - something that unraid actually handles as well or better than anything else ive tried... And for backing up that one VM? You can do this just as you would any other Windows machine. Virtual machines are inefficient when compared to containerized workloads, and CA makes it extremely simple for even a novice to quickly spool up a container for any number of needs. I understand your request is for built in VM backup functionality, and I certainly agree that this would have value - I'm simply saying I dont necessarily agree with the premise that it forces users to virtualize unraid, or that lacking native VM backups is something of an "Achilles heal" given its most common use cases and customers.

They're logically completely separate devices and can be treated as such

Yup! All based on the PCI address, so 02:00.1 could have 4 VFs and leave 02:00.0 untouched.

The Stats plugin does this pretty well (Sorry for the crappy screenshot, I'm mobile currently)

Not as a default, not in my opinion anyway, as setting this to a value of 1 can be dangerous. The setting itself determines how the OS responds to memory allocation requests from applications, with the options being (take some of this with a grain of salt, been a while): 0 - default, responds to allocation requests via an algorithm to determine how much memory can be allocated based on currently reserved, free, and committed memory. Typically safe. 1 - always accept any memory allocation request, regardless of (anything) 2 - never overcommit memory (never reserve more memory than actually exists, e.g. fail the allocation request if not enough exists) In a system like unraid where we've no swap by default, setting to 1 could be problematic for some, especially lower memory systems, and should (I feel at least) have *some* kind of consideration from the user prior to making such a change (meaning 'make the user have to set this themselves, so at least they've the chance to consider the implications' lol). There are numerous use cases where it's beneficial to set vm.overcommit_memory=1, just have to be aware of the consequences... Which are potentially crashing your server if unraid attempts to allocate memory for itself (mover running, parity check, file access, etc) when there's not enough available. If you plan to set vm.overcommit_memory to 1, it's important to be more cognizant of system memory utilization, being sure to monitor memory usage more closely than otherwise. I'd also consider setting up the swapfile ('fake it till you make it' ram) if you've any concerns over whether or not you've enough memory to handle all you're running on your server.

So I apparently finally hit the tipping point towards experiencing what you were seeing with Lidarr - seems to be somewhere in the 65-70k track range, where the way the queries to the DB are formulated means the sqlite DB just absolutely chonks in protest. I finished converting Lidarr over to postgres last night, and while it's still sub-optimal IMO from a query perspective, pg is basically able to just brute force its way through. Start-up times cut down to maybe a tenth of what they were previously, and all UI pages populating within a couple seconds at most 👍

You just made my day 🥳

Also wanted to note - while a plugin version would be great as a bandaid, this kind of thing really should be part of the core OS longer term imo (so it doesn't require the user to seek out the plugin to monitor their drives)... It's one of the few areas where I feel that UnRAID lags significantly behind as a platform. It's one of the most basic functions of a NAS, so hopefully this can eventually make it in to the OS - no new packages needed, just management / UI thankfully! My justification here is mainly that every other NAS OS out there, both free / open source, as well as commercial options, they all have this baked in (all I've ever put my hands on at least!) - OpenMediaVault: Truenas: Rockstor - it requires manual input, but is still all UI with tooltips, so... I guess that counts? lol: (etc etc)

It's thankfully even much easier than that, at least for the 'short' tests - just need to run: smartctl --smart=on --offlineauto=on --saveauto=on /dev/sdX Output looks like: smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.19.17-Unraid] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF ENABLE/DISABLE COMMANDS SECTION === SMART Enabled. SMART Attribute Autosave Enabled. SMART Automatic Offline Testing Enabled every four hours. As to the 'long' tests though, I'd not really looked at my disk monitoring setup since the 6.9 (?) changes to how modprobe functioned in UnRAID (not that it's directly related lol), but it should *REALLY* simplify this since smartd comes with the base OS as part of smartmontools. Copy /etc/smartd.conf to to your flash drive, then denote the drives to run against and when you'd like them ran - then link the file to the source location, and you're done (I added it to my list of symlinks which get generated on first array start). I just removed my original scripts for this, much cleaner now! I'd imagine there's a relatively easy way to populate the conf file based on the disk settings given the user chooses the controller type for their drives as part of the disks config within UnRAID already, so finding / sorting / populating based on that UnRAID config should make it pretty well fully hands off for the user 🎉

Technically correct (the best kind of correct!), but I think if one were speaking to a filesystem layman or lifetime windows user, its the closest equivalent available, and if you were to simply leave it at "zfs has no fsck" without further explanation as above, it may leave them with a potentially undeserved negative sentiment. Either way, once more, this wasnt posted for you specifically, but as an additional breadcrumb trail for others who might come across this through search (etc) to give them some additional search terms to help 🤷 As this is a feature request post (and the core issue of corruption has been resolved, at least in this instance), I wouldn't really expect any sort of timeline for a response directly from limetech honestly... Not only is this something thats being requested for a future build, butgiven the size of the team, they've got to focus their efforts in the forums primarily on support and bug fixes, at least during a period where there's still release candidates needing sorted out (the macvlan issue, for example, is one thats been plaguing folks for quite some time, and may finally be getting ironed out - woot!) Several other things I'd say are worth keeping in mind - There's a plugin already available which would help test for this, 'Fix Common Problems', as @Squid mentioned above. UnRAID can't realistically be a 0 maintenance/monitoring system, just as any other, but there are at least tools out there that can help lighten the load of doing so. The older a drive is, the more active monitoring it should have to keep an eye out for such issues - not sure if your signature is still accurate, but all of the drive models mentioned are at least 10+ years old, and even the generation following is now something like 7-8. When disks get anywhere near this kind of run time, the 'standard' recommendations for data protection can't really be applied (e.g. monthly for parity checks and the like) - with anything over 5 years, I'd be running them at least bi-weekly, as disks often fail extremely quickly at that age. As opposed to slowly incrementing errors, I regularly see them pile up massively over a course of hours, maybe days, rarely lasting weeks. Subsequent to this, desktop drives (but most especially older desktop drives) were/are kinda crap at self reporting issues - this seemed especially true 5+ years ago, though it has gotten at least a bit better over the years. Where an enterprise or NAS drive might show themselves as failed before running out of LBAs to reassign bad blocks to, desktop drives would often happily churn along as though nothing happened, corrupting data along the way. I'd check that disks SMART data / reallocated sector count at the very least. Unraid is somewhat unique on the NAS OS front, in that it builds it's array out of multiple disks containing independent file systems (of varying types) as opposed to building an array out of the physical blocks themselves by combining the disks into a virtual disk - given there's no single reporting mechanism at the FS level which would encompass all supported FS types in the array, there's almost certainly some complexity to reporting individual disk corruption out from underneath the array. Like I said though, I'm not disagreeing on any specific point, and in fact agree that UnRAID could do more here - it should at the very least regularly run SMART tests by default, propagating errors up to the notification system, and I do hope the devs find time to integrate this into the OS so I can remove my scripts for them. It would nearly certainly save folks a lot of pain recovering from backups down the line!

I guess I was sorta getting in to symantics 😅 With ZFS, I always think of the pool layout as the FS 'equivalent'. Fsck can only really do 'fsck' because its a journaling filesystem (a feature shared with XFS, which is why it has more of a direct equivalent), while ZFS is transactional (as is BTRFS) - there's no direct eequivalent, namely because the way they commit. No journal, nothing to replay, atomically consistent. ^^ Again, just for clarity should anyone else come across this later. If your pool becomes corrupted, there *are* methods to potentially repair it, but they require manual intervention, and the chances for success vary widely depending on the specific circumstances (pool layout, media type, etc).

ZFS does have this, it's just referred to as a 'scrub' instead of fsck: zpool scrub poolName You can also use tools like 'zdb' for more granularity/control of the check/repair (scrub), things like specific block failure reporting, running 'offline' on exported pools, etc. ( just notingfor anyone else that might come across this in the future 👍 )

Again, I think this would've been caught by a parity check - I can't think of any reason this wouldn't be the case... While I agree that additional checks would be helpful, it seems there *is* actually a 'catch for this in the OS, right? Or am I missing something maybe? I definitely do agree that there's more that could be done to safeguard the data, but also at least want to acknowledge the stuff thats already there of course...