JokesOnYou77

Hi all, About six months ago I was out of town and we had multiple power outages while I was away. Unfortunately, my UPS wasn't configured correctly and my unRAID server went down and came back up multiple times with the outages. When I got home I ran a parity check and all of my data was fine but I noticed that a bunch of my settings, like the server name and FTP off/on, had changed or reverted back to defaults and I found a ton of fsck files on my USB drive--presumably because some process tried to fix a damaged filesystem. I restored my VMs from my backup but when I went to restore my USB drive/unRAID setting I realized that I had made a serious mistake. The CA plugin I had been using for USB backup was just doing a daily rsync rather than a versioned backup! It had already been more than a day by the time I got back so my backup had already been overwritten. Initially, I thought, no problem, I documented my setup, Ill just follow my own instructions. But, as is often the case, my docimentation isn't perfect, and after I finished my initial setup I didn't document every little tweak. All that to say, I don't have a perfect record I can recreate my unRAID settings from. After all of this happened, I ended up just shutting down my server. I didn't have time to deal with it and I didn't know what I even had to do to fix things or if I had a viable and secure configuration. But now I have some time again and I want my server back (and I want my data back). This time around, I started by copying everything from the USB drive to my workstation and then diffing against the baseline install zip file from the version of unRAID I was using. I figured I would be able to at least get a good indication of the changes I had made. However, once I started going through the diff I found changes all over the place and it looks like some config files may have had defaults written to them which overwrote my settings (not confirmed, I just see a lot of settings that don't match what I remember). Any ideas how to get everything back to my settings? Best, -- Jokes

If this can be done in an OS update, it would be awesome. But I don't have that power, unless there's something I'm missing in the code on github. But what I can do to solve this problem for myself and others in the immediate term is to write about 50 lines of code/JSON with instructions on my github. But by no means am I proposing that we mark this topic as closed/solved. Building this into the OS would be great. But I think that's a much longer discussion around the right scope, user experience, and implementation. To me, that means it's likely to take a while. To get that discussion started though, let me share some of what I've learned so far (I lost the source links though, sorry): 1. The change can't be made through CSS. Seems like there are a few contributing factors here but the big one is that the drawing is all done in Canvas. 2. Ttyd is started once and has to be restarted to change the server-side configuration. In addition to the above, I would add another point which is that I have observed, from my own behavior, that I access the web terminal from different devices with different screen sizes at different times and I re-attach to the same tmux/screen/byobu session each time and I'd like to have a different font size on different client machines. Moreover, if restarting ttyd kills the running multiplexer session because ttyd is the parent process that would not be a great user experience (not to mention other stuff like losing command history depending on how users have that configured). Both the screen size and multiplexer issues make me think that a client/browser-side solution would be preferable to restarting ttyd on the server side. That said, a server-side "base" configuration might not be a bad idea either. I don't have the time this instant, but a good next step might be good to run a test by starting a tmux session, starting htop or something, then restarting ttyd and seeing if tmux is still running.

The modified move command makes sense to me and I can change my commands accordingly. But I seem to be getting conflicting information here in that I absolutely am getting duplicate files and I can delete the one on the cache without removing the one on the array disk (checked and double-checked but I'll check again later today to confirm).

Hi all, I have two shares, downloads and Media. Downloads uses a cache pool and Media does not. When a download finishes, I ssh in and mv downloads/some_dir/ /mnt/user/Media/. But this results in two copies of the data, one in /mnt/cache/Media/some_dir/ and the other in /mnt/disk1/Media/some_dir/. It seems like this is some kind of conflict between the default Linux mv behavior, which simply changes the reference for where data is stored when moving data on the same physical disk, and the UNRAID behavior that follows caching rules. Is this expected/desired behavior? It seems very counter-intuitive to me and it results in a warning from Common Problems because a share that doesn't use a cache gets a path on a cache drive. It also raises questions to me about how reads will behave and if there are potential race conditions (seems unlikely but possible).

@ljm42 My PHP isn't very good, but it doesn't look like there's a place to inject logic for this in the UNRAID webGUI on github. That leaves browser plugins or greasemonkey scripts as the best way to distribute this in an easy to use fashion. If I were to build such a thing, what would be the right forum to announce it in?

I'd also like to see the web terminal don't size made configurable. As it is, I can't increase the terminal font size without also zooming in on the main UI page which blows that up and makes it difficult to have terminal and GUI both open and readable. Has anyone done the work to see how we could actually use xterm-webfonts? Maybe we can make a browser addon to inject it? UPDATE: I spent some time messing with it and reading docs and made a little progress. Entering the following in the browser JavaScript console gets the desired behavior: term.setOption("fontSize", 20) Just need to package as a browser addon to distribute. I'm unlikely to have a ton of time to do that so I'll probably run manually for the time being, but I hope this helps others. In the future, it looks like ttyd has options to override the client-side options on the initial start: https://github.com/tsl0922/ttyd/wiki/Client-Options#basic-usage I suspect that UNRAID users could be given a config file with options they could add to the ttyd call at some point if that's determined to be a desirable direction.

I'd like to request the addition of the pixz compression tool. It's a wonderful extension to the standard xz (LZMA) compression tool that allows random access to files in the archive. For large tarballs, the ability to extract any arbitrary file, and show the archive index, without reading the rest of the files in the archive (more or less constant time). I deal with 2-3 GB archives in my day to day work and I am guessing that I'll be dealing with a lot more as I get into UNRAID and it would be really nice to have random access to my compressed/archived files.

Packaging as Docker container is a great idea, I do that at work to make executables. If pixz didn't need pthreads I'd even be tempted to use scratch as the base image. I'll start with a petition to Nerdpack though. For future reference:

I've installed the Nerdpack plugin but it's missing a command I'd like to have: pixz I've seen other posts suggesting that UNRAID isn't a "full" linux distribution and I'm guessing that means I need to download and compile from source, and I'm comfortable with exploring that if that's the route to go. But if there's a better/recommended way I'd like to try that first. To address questions I assume will come. Yes, I know xz is included, and I know xz now supports blocked archives and parallelism. It's just not the same as the ease of use of the random access to files provided by the index with pixz (try it for yourself and you'll see what I'm talking about). And I also saw that pigz is in Nerdpack, which is a nice substitute but still not the same. I'm sure I could make do with alternatives, but as I explore UNRAID during my trial period I want to see what I can and can't do to the system (with the help of the community).

Thank you! Exactly what I needed to know.

Ok, I would not say that my tests were definitive, but I am confident enough to say that this was user error (my fault). The ultimate issue sprang from how I made my key. I tried to concatenate a few binary files to make a file key and, for whatever reason, the key that actually registered was only the first of the concatenated files (I made sure to test with a combined keyfile size of less than 8 MB). While I don't have a complete, in-depth understanding of what happened, I think I have enough information for me to keep going with my build.

Hi all, I'm pretty new here, just starting my UNRAID journey, and I just noticed there is a polls section on the website. I took a look at the RAM poll and saw the first page was from 2014 and many people were using 2 GB of RAM. I thought it would be interesting to look at how the poll results have changed over time and maybe share that back to the community. So I thought I should ask a few questions to start with: Has this kind of thing been done before? I.e. looking at forum poll results over time. Are there approved methods for scraping the forums or downloading a dump/snapshot? Are there politeness rules or access rules for scraping the forum? -- Jokes

If I plug in a USB drive and directly copy data from it to local share, or cp a local file from somewhere else to a share, is the data parity protected? E.g.: cp -r /mnt/disks/External/Movies /mnt/user/Media/. I looked at system stats and drive I/O and it looks like the answer is, yes, but I didn't want to assume since I'm new to this and I don't have a good mental model for how the parity operations are integrated into the system (kernel? user-space program? something else?).

I tried a bunch of things that didn't appear to fix the problem (wipefs, write the first 4 MB with zeros). That made me more sure it's something I'm doing wrong. I'll post again when I can confirm. @JorgeB Thank you for your help and prompt replies. I appreciate it.

Not strictly relevant to fixing my issue, but shouldn't UnRAID have prevented me from making an array with a new key if it wasn't going to work? Is there a command I can run to quickly test if a disk will take a new key so that I can "fail fast"?