rilles

Do you have a AMD Ryzen system?

Hello, to protect the data on my drives I enabled encryption. To enable autostart I inserted into /boot/config/go the line "cp /boot/config/keyfile /root" This seemed to go well with the drive autostarting on bootup. Then I bought a giant usb drive to use as an array backup, so I installed unassigned devices and UD plus so that I could also encrypt the usb drive. I do a reboot and all is not well. The UD luks encrypted usb drive does auto-mount... but my array no longer auto starts its asking me for a keyfile or keyphrase. If I open a console window and go into /root the keyfile is not there. If I pass in a keyfile from the webGui then it start and the keyfile is in /root does anyone have any idea what is going on? why is the keyfile not getting copied from the go script (or why is it getting deleted after emhttp starts)?

A year old post - but I was looking into this. unraid uses luks for encryption - you can setup a system or virtualbox system with luks and mount the drive with with the secret key to mount and read the drive. I have not tried this, but should work in theory.

I have the same Asus board with a 2200g, and have the same SATA/network dropping but only under heavy sustained cpu load. Interesting that a mobo changed this - I wonder if its the chipset or the manufacturer that improved things.

I have an asus prime b450m / csm with a 2200g Beware. I've done all the hacks, generally I don't have any issues with it, parity check or otherwise. Under heavy load for a few minutes all the motherboard i/o ports get borked but the cpu is not locked up. This may or may not cause a unpleasant experience when you shutdown and reboot. I've had to remove some of my dockers (like sabnzdb) to avoid sustained cpu spikes.

I have a LSI-9211 controller - I put the spinning cache disk on this controller and repeated my test. The SATA didn't die but everything else did. So yes I believe you are right - the issue is under heavy load the Ryzen motherboard built-in interfaces (SATA / networking) bork. though i've never had an issue with parity test only heavy application load. my parity check actually is faster now then before by 10MB/s oddly.

The DDR4 ram was 3200 - changed it to auto (defaults to 2600), turned off C states, set PS supply mode to "typical current". Held my breath - ran sabnzdb - and same issue. I put in a old WD green spinning disk as cache - my theory now is the SSD when heavily loaded borks the SATA interface which borks other stuff on the mobo.

Very relevant as I'm running an AMD 2200G with an Asus b450m mobo, but only using officially supported RAM speeds and my AMD is not locking up as the console still works and I can do a graceful shutdown. SMART health checks all good. So if I assume its not a bad drive issue then sabnzdb is relevant because its pushing a high CPU load, c-state is probably not related as I have no issues any other time after running this system for 6 months. which could then lead to motherboard based services choking? leading to file system shutdown? from the error log it appears they stop responding: May 9 00:32:02 Tower kernel: ahci 0000:02:00.1: AHCI controller unavailable! May 9 00:32:03 Tower kernel: ata6: failed to resume link (SControl FFFFFFFF) May 9 00:32:03 Tower kernel: ata6: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF) May 9 00:32:05 Tower kernel: r8169 0000:08:00.0 eth0: rtl_chipcmd_cond == 1 (loop: 100, delay: 100). I will start fiddling with settings based on this post:

Issue: when I ran sabnzdb and its unpacking its downloads, I'm more and more often seeing "XFS metadata I/O error in "xlog iodone"" errors and the file system shuts down and unraid goes offline I've searched for this topic and the results are typically: - change your cable - reformat your cache drive - delete and redo your dockers. I'm using a ADATA SSD connected to a motherboard SATA port. I've changed cables and ports. I've reformed the cache drive from btrfs to xfs. I've deleted my dockers and the img file and redid them - same result. sabnzdb will trigger it, copying lots and lots of large files to the cache does not. What the heck could be causing this? I've attached two of the debug files generated when unraid crashed. tower-diagnostics-20200509-0030.zip tower-diagnostics-20200509-2005.zip

that was the issue. when I first started dong this I did not realize that letsencrypt requires the rproxy to allow inbound access from the internet.

Assuming you have a cache drive. "/mnt/cache/appdata/caddy/config" <-- this is the directory to put your config file and certs into. I remember some ancient days when I had to use vi - go to the spot you want to edit and press "i" and then edit when you are done editing press escape. press ":" and then "w" to save the file and then ":" and then "q" to exit. root@Tower:/mnt/cache/appdata/caddy/config# v -rw-r--r-- 1 root root 693 Apr 18 15:35 Caddyfile -rw-rw-rw- 1 nobody users 1350 Apr 18 15:16 caddy-selfsigned.crt -rw-rw-rw- 1 nobody users 1704 Apr 18 15:16 caddy-selfsigned.key here is my copy of the "Caddyfile" config file (192.168.1.243 is the IP of my unraid server) :443 { # tls ${SSLCERTIFICATE} ${SSLKEY} tls caddy-selfsigned.crt caddy-selfsigned.key # or 'tls self_signed' to generate a self-signed certificate # This setting may have compatibility issues with some browsers # (e.g., attachment downloading on Firefox). Try disabling this # if you encounter issues. gzip # The negotiation endpoint is also proxied to Rocket proxy /notifications/hub/negotiate 192.168.1.243:8008 { transparent } # Notifications redirected to the websockets server proxy /notifications/hub 192.168.1.243:3012 { websocket } # Proxy the Root directory to Rocket proxy / 192.168.1.243:8008 { transparent } }

"tls self_signed" is for testing only and only lasts 7 days. created a 5 year self signed cert in Ubuntu: openssl req -x509 -nodes -days 1825 -newkey rsa:2048 -keyout caddy-selfsigned.key -out caddy-selfsigned.crt copied it to unraid file share, copy it from the share to /mnt/cache/appdata/caddy start caddy, launch console and edit CaddyFile with vi. change "tls self_signed" to "tls caddy-selfsigned.key caddy-selfsigned.crt" restart caddy and away you go. I tried some of the ngix dockers but I could not get any of them to work, either due to letsencrypt errors or just to hard and fiddly for an amateur.

just download this and trying to use this with bitwarden. Issue is I cannot seem to get a LetsEncrypt cert - every time I try to create one I get an "internal error". if I look at my proxy error its basically missing the .pem file (probably related to the error) edit: read through the above now understanding it a bit better - no luck. giving its own unique IP has the same error.

I used this to enable BitWarden over HTTPS (the unraid docker only supports HTTP) https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples using self signed. works great. edit: "tls selfsigned" only is for testing and regens after 7 days. create some self-signed certs and copy them to /mnt/cache/appdata/caddy

So I watch space invaders video and a few others and my head was exploding in anger and frustration. I don't want to expose this to the internet, I don't want a domain and I don't need a real cert, waaay too much fiddling. So scraped the bitwarden_rs docker site and they have a few easier suggestions - the one I used was Caddy 1.x (also a unraid docker) https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples you can't use localhost so make sure you enter your server IP address, and I enabled "tls self_signed" works fine for me now on all browsers.

I'm using Ubuntu and firefox with Bitwarden over port 80 and it has been working fine, that is until the last day or two it appears firefox (v75.0) was auto updated and now it has the same issue as chrome. When I try to login a little red box appears "This browser requires HTTPS to use the web vault. Check the bitward_rs wiki for details on how to enable it" I guess I'm going to watch to watch spaceinvaders video to setup a proxy. grr.

I'm also seeing kodi unable to browse nfs shares. I had no issues in 6.7.X - but after I upgraded to 6.8 I fiddled with the samba/global share sections and it stopped being browsable. No fiddling has been able to restore it.

I've noticed this also. when i upgraded to 6.8 I fiddled with the samba settings and now I cannot browse nfs shares on unraid but i still can on my other machines that export nfs. i've fiddled more with the settings to no avail.

same with a 2200g,.. unraid crashed hard. better to not have the option there for amd igpu

i like how unraid keeps getting better... more then just a simple nas. My one wish is that a new libreelec image becomes available. the current one is old and doesn't play nice with mysql and newer kodi versions

While it seemed the answer to everything... it doesn't appear to be stable. running it as a plain docker it just runs for a bit then exists for no apparent reason. Running as a unraid docker, it randomly shuts down also. Tried running emby, but it seems to have random shutdowns also under load and has too many quirks in the way it works I don't like. So now I'm running kodi 18.1 in a Virtualbox Ubuntu session.. that seems to work really well. So next step is to get a raspberri pi to run kodi and do the updates.

I found a docker that seems to do what I want - a headless kodi docker that just does library updates and cleans. https://github.com/milaq/kodi-headless But I have to run this on my main pc until I can figure out how to get a "raw" docker on unraid.

And the workaround for the non-exported symbols. https://www.phoronix.com/scan.php?page=news_item&amp;px=ZFS-On-Linux-5.0-Workaround

RobJ has an opinion. But ECC is not REQUIRED for ZFS or btrfs, probably strongly suggested for the more data paranoid who may lose sleep over a possible "scrub of death". But, RAID is not a backup - so I'm not going to be upset if bits flip in my movie stash and all my actual important stuff of course is backed up somewhere else.

Yes, unless bits rotting away keep you up all night, but then you'd already have ECC RAM in your unraid box.