Keexrean

And again procyon-diagnostics-20200714-0910.zip

And again... and again... procyon-diagnostics-20200714-0018.zip procyon-diagnostics-20200713-2010.zip

That time it was the cheaper option, by unit it was 6.99, and the 3 pack was 18.99. Basically saving 2€ Edit: their narrow edge's etching is fully identical on all 3.

Here's where I got them: https://www.amazon.fr/gp/product/B081PQDGW6/ref=ppx_yo_dt_b_asin_title_o00_s01?ie=UTF8&psc=1 Notice vendor name. And they don't look like fakes. Bought the pack of 3*16GB.

Well well well. Thank's Kingston, only one of these will be used for unraid then, the 2 others will go for other distros.

Thank you very much!

Hi again @saarg , I'ld like to ask you to edit/snip your quote you made of my message earlier in the thread. It contained some info about what email, domain, and IPtracker I use for letsencrypt and all, including docker configs and all. Few days ago I started having heavy traffic on owncloud login page, with a lot of random login attempts. I wouldn't have linked it to this post if, checking the email account used in letsencrypt, it wasn't also being targeted, finding a few fake alerts and fake OVH login page phishing attempts in it. This mail wasn't used to register anything else than letsencrypt, so in two years up to now it collected 0 spam and no mail. If editing the post won't stop the actual attack (which I'm not fearing about it actually succeeding, just annoying), I would like that no one else but that random script kiddie be tempted to give a try at it, so it would be better to just not leave these hints available. I edited my post already, I would appreciate it if you would please snip the full quote you made of it. My post Yours with the quote Thanks!

Well, concerning SanDisk, I did linked a bit long post and didn't really pointed out some important piece of informations, to keep it short. Here are the main points: For the same "Product Name", they discovered that SanDisk sells under the same name (in this post the user Nejko had a SanDisk Ultra Fit 32 GB, and later bought more) at least 3 different product codes (BM141024848V, BM141224848V and BM150224846D), only the first of the 3 actually successfully booting linux, the two others getting stuck early on on a "(initramfs) Unable to find a medium containg a live file system" issue, accross multiple distros. Worse, same user, Nejko, got a hang of a Sandisk Rep through mail, and here's what they got told: You heard that. They don't test their keys to see if they are bootable!! Pretty dismissive, and the kind of BS that doesn't make me want to do any business with them when it comes to USB sticks. At least their SSDs are tested to be able to boot... so far. Later in the post, the user jdb2 went deeper on the issue on their own SanDisk key: That's why I completely ruled out SanDisk when it comes to bootable USB disks. I may be over-engineering the question, but since I'm planning on buying a pack of 10 keys, I don't wanna play lottery with product codes. And yes, your Sandisk USB keys boot fine, I have 1 that does too, and doesn't heat up or anything... but had one that never booted and that I gave to a friend for their university stuff. The user Nejko had one, then went to buy more of the same model "Name", and got done in the rear IO. Given the issues I encountered, that a lot of other people encountered, and SanDisk's apparent policy, if I'm ready to give a chance to any other brand, SanDisk is simply completely ruled out to me.

Thanks for the input. Kingston as I said I had only ONCE a bad experience with (a slow af drive that I gave to my mother, which stored quite important documents on, and basically failed the day of an important meeting just 2 months after purchase!). And given that I only ever had 3 Kingston key, I was just unable to give a proper evaluation of their USB keys, nor willing to risk to waste money into potentially defective drives. And with the particular environmental parameters inside a server compared to what most people do with USBkeys, I would have had to risk having servers bootings off of keys I don't trust already? Yeah no. Also, the reason I was questioning about usb 3.0key over 2.0 even on USB2.0 port, was for the simple reason I would think that 2.0 nowadays could be a good reason to cut down on flash chip quality to cut costs for manufacturer. Aka, nice chips going to 3.x keys, shitty slow chips going to 2.0 keys. But if you tell me you have 4 running strong and reliably, and at the back of/inside servers, I may try these!

Hi people! Whether you're running unraid in an refurb enterprise server or in a brand new case boasting a ludicrous amount of DDR4 and an Epyc processor, or have a threadripper or a janktastic set of garbagio parts that assembled themselves through dark magic into a server, there is one thing we, at 99.9% have all in common with unraid: we use an USB stick to boot. And that's where I'm having some concern today. No, I won't be like 'why not use something else', that's not the point. It's more like "what usb drive to use" My unraid server has been running strong for 3 years on the same USB stick. No write error, nothing, everything's great! Or almost. That drive is an idon'tremmemberhowmany years old 8GB JetFlash drive that's missing its plastic housing, wraped in kapton tape. I have an esxi box with a drive from 2007, missing its housing too, wrapped in greasy electrician tape. (I also have a "naked" SSD... I'm a monster 😲) And since I'll be expanding the number of servers in my humble ratsnest of a flat, I decided to replace the old drives from which my boxes are booting, and buy some extra for the new ones. The issue is, it's proven quite hard knowing which drive manufacturer to trust when it comes to this. I already completely ruled out Sandisk. They have been known to produce drives that aren't capable of being boot drive, not following official USB specs. How the f. This thread is quite interresing on the matter, basically linux can't enumerate the drive. Since I'm gonna order like 10 keys, I don't want to have 10 useless tokens of industrial failure. Kingston I had a bad time with once, Transcend several times, but I also owned a lot of transcend keys, and some... well are still holding so far 13years strong. And looking at customer review, basically every key I look up has its fair share of catastrophic failures (like breaking randomely, DoA or stupidly slow speeds, USB3.1 drives running at 1.1 speed). And most comparative reviews are made on sheer speed-and-housinglook&sturdiness-to-price, not durability over years of being powered on. So here's what I'm looking for: Is there some of you who have been running multiple identical pendrives over the years who can give a fair opinion on their speed and, most importantly, reliability? I'm basically looking for 8gig (max 16gigs) pendrives with usb3.0 and up, and just decent enough speeds, that with your experience with that particular drive, you would say it won't mind living next a PSU inside a server, with a raging hot CPU and ram bank puking an heat-wave at it, for years, 24/7. I'm keeping religious backups of my bootdrives, but since I host services for other people, including on opposing time zones, I have no hour acceptable to be a down time longer than a simple reboot (which is long enough already, long POST board.), and I prefer stuff to just WORK and not fail, for some madly inconceivable reason. TLDR: if it's easy for most components, a "server-booting usb drives: almanac of great ones" post is hard to come across.

And after like... half an hour of uptime? Happened again! Here is the diag for this one. I later used '/etc/rc.d/rc.inet1 restart' , which, without even touching the cable, made everything work again... Scratch that, if restarting the docker containers was enough, restart the VM didn't gave her back access to the network, and stopping libvirt, impossible to start it again after. Had to reboot. Also for information: - eth0 is on the R720's 4 port stock nic, connected to my lan - eth1 is a back to back SFP+ to an other box (main workstation) which was really useful to access the GUI when eth0 failed - eth2 is an SFP+ connected to nothing - eth3-4-5 are the other 3 out of 4 R720's stock nics procyon-diagnostics-20200626-1318.zip

28days of uptime now, and still going strong. I.... just don't get it, touched nothing. Ugh. EDIT: I rebooted the server (because I was doing stuff on it, and needed to reboot). Booted, all is nice and dandy. Leaving home. Come back, 3 hours of uptime, and around 1hour in, it happened AGAIN out of nowhere, while it's been issue-free during almost a month. And basically masturbating the ethernet cables on both ends yields nothing. Have to shut down all docker containers and VMs, and unplug both ends of the cables and plug them back in... And I don't know if it's linked, but I had an issue of "tainted VMs" in libvirt (don't know why), along with libvirt service sometimes not finishing to start (as in still displayed at starting in the bottom left corner of the webGUI), and auto start VMs not starting. *sigh* procyon-diagnostics-20200626-1227.zip

Yeah, I know it looks backward, but this router hasn't been built by geniuses. And I choose the computer from the list of devices I attributed a name and static IP to through the DHCP server of the router. Checking with websites like https://canyouseeme.org/ and all show 80 and 443 as working. Again, it all went haywire after a letsencrypt update. I did also at the same time made modifications to the host (changing the networkcard, setting the right port to eth0, deleting its old self from the DHCP server, adding its new MAC to it, setting back up all its port forwarding, ect, but thing is, other services work as before after this "migration") So I'm not sure of anything anymore... maybe it's a fluke of communication between docker and the new network card?... that makes no sense, sad. EDIT: I tried something I rarely do, and only out of frustration. I pulled the plug. On both the router and server (after shutting down the VMs and important services properly though). Plugged back in. It actually made a difference... #$@&%*!#$@&%*!? So what changed? Well, looking from an other IP than mine (to avoid loopbacks), nextcloud now shows up! That's stupid, but that's the case! Properly encrypted and all. owncloud though displays the "Welcome to our server" letsencrypt message. I swear I feel like my computers are haunted sometime, and out to mess with my nerves. Edit²: I changed the owncloud docker name to "Cloud" (yes, with a cap, like what it was originally), edited the owncloud.subdomain.conf accordingly, restarted the thing, as just a shoot-for-nothing attempt... it #$@&%*!ing worked... I'm not even happy it worked at that point... SO! Well, that's fixed for everyone else at least! Up and working and all, but I used to be able to visit these adresses with no issues from devices connected to this network, it seems like it wont let me now, apparently cause of a loopback. So I dug a little more. My ISP released a firmware update around the 20th of May.... and an other yesterday... #$@&%*, means neither letsencrypt nor migration were the cause most likely, and I just spent time wrestling my dockers and config files for nothing... I did nothing wrong... yeay, *underwhelmed happy noises* Bug reports on their forums seem to tell the first update was a buggy mess (reason it went all haywire, and due to migration and letsencrypt update, I thought it was else due to Letsencrypt or the network card swap and rule recreation, the firmware update was done silently and the buggy mess wasn't affecting anything else than port 80 and 443) and the second fixed most issues, but neither have a working loopback on port 80... There previous router had a lunatic loopback that worked on and off, had it for 3 years but working most of the time for me... had it upgraded to their lastest router for 2Gbps down 1.5up fiber (from 900mbps down 750mbps up) in March... #$@&%*! So basically my case here is solved, the rest I'll have to deal with my ISP and join the mob to pressure them into releasing less buggy firmware.... or actually using my VPN subscription for something else than my qbitorrent docker, just to access my own services. Thanks all anyways!

Okay, now it's been a week and I can renew certificates again. Had backups of old configs, not working now, used to. Tried redoing my config, the one that held for 2 years, from scratch, not working either. So I'm going to detail each step I took, both 2 years ago and 1 hour ago, which are basically the sames with just name differences, and an added docker, well supported and freshly installed for reference, since my owncloud is a clusterfluke. It's thus now a double setup of owncloud (my true install, tinkered with) and nextcloud (a bog-standard sqlite install with no modification). Owncloud and Nextcloud share a lot of code, and used to be one thing that just forked in dev and org. My old Owncloud config for letsencrypt was basically a copy of nextcloud's sample config, just tweaked slightly for it. I went to my router, cleared old port forward, port forwarded host180 to 80 and host1443 to 443. I have multiple other services portforwarded, they all work, so it should too. Port-probing tools show them open and not blocked by my ISP. On the host server, which now you know is called Procyon, opened console and went: $docker network create proxynet Installing letsencrypt from scratch with these settings: [Edited for post length and privacy] Yes this mail address exists and works too. Owncloud and Nextcloud are both restarted on this network: [Edited for post length and privacy] The xxx.fr domain belongs to me, through OVH. The nextcloud and ark-cloud subdomains are created (ark-cloud is 2 years old and never modified), C-NAME to a no-ip dynamic subdomain, xxx.servehttp.com, pinging either xxx.xxx.net or xxx.noipdomain.com pings my actual IP. [...]> nextcloud IN CNAME XXXX.servehttp.com. [...]> ark-cloud IN CNAME XXXXX.servehttp.com. Yes, I know, there is nothing on the main domain. A project didn't happened yet. whatever. nextcloud.subdomain.conf and owncloud.subdomain.conf, and their respective config.php files are configured as follow: appdata\letsencrypt\nginx\proxy-confs\nextcloud.subdomain.conf: (untouched on purpose, and valid in its default state) server { listen 443 ssl; listen [::]:443 ssl; server_name nextcloud.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app nextcloud; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } } appdata\Tempnextcloud\www\nextcloud\config\config.php: <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'XXXXXXXXXXXXXX', 'passwordsalt' => 'XXXXXXXXXXXXXXXXXXXXXX', 'secret' => 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', 'trusted_domains' => array ( 0 => '10.10.7.70', 1 => 'xxx.servehttp.com', 2 => 'nextcloud.xxx.fr', ), 'datadirectory' => '/data', 'trusted_proxies' => ['letsencrypt'], 'overwrite.cli.url' => 'https://nextcloud.xxx.fr/', 'overwritehost' => 'nextcloud.xxx.fr', 'overwriteprotocol' => 'https', 'dbtype' => 'sqlite3', 'version' => '18.0.4.2', 'installed' => true, ); appdata\letsencrypt\nginx\proxy-confs\owncloud.subdomain.conf: (basically a derivation of the nextcloud file, and alike to the original I used) server { listen 443 ssl; listen [::]:443 ssl; server_name ark-cloud.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app owncloud; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } } appdata\ownCloud\www\owncloud\config\config.php : (untouched for basically 2 years, just commenting stuff on and off when troubleshooting) <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'filelocking.enabled' => true, 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => '/var/run/redis/redis-server.sock', 'port' => 0, 'timeout' => 0.0, ), 'instanceid' => 'XXXXXXXXX', 'passwordsalt' => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', 'secret' => 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', 'trusted_domains' => array ( 0 => '10.10.7.70', 1 => 'xxx.servehttp.com', 2 => 'ark-cloud.xxx.fr', ), 'datadirectory' => '/data', 'trusted_proxies' => ['letsencrypt'], 'overwrite.cli.url' => 'https://ark-cloud.xxx.fr/', 'overwritehost' => 'ark-cloud.xxx.fr', 'overwriteprotocol' => 'https', 'dbtype' => 'mysql', 'version' => '10.3.2.2', 'dbname' => 'owncloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud', 'maintenance' => false, 'dbpassword' => 'owncloud', 'logtimezone' => 'UTC', 'installed' => true, 'loglevel' => 1, 'theme' => '', ); Indeed corresponding to the names of the dockers, with not capitalized characters (used to have caps, and working with caps): letsencrypt's console is clean and showing everything working as intended, like it did before it failed, and while it failed: [Edited for post length and privacy] No, I don't care about GeoIP. Both my owncloud docker and nextcloud 'reference' installation docker are perfectly working when taken out of the proxynet, and told to run insecure on LAN through edition of the config files. They also both work in unencrypted mode when portforwarded and displayed with xxx.servehttp.com:port, my no-ip.com subdomain. Owncloud has been running in tandem with letsencrypt on the ark-cloud subdomain across multiple updates, 2 different routers, 1 host server migration, and several unraid updates without a single hassle on the exact doppleganger of this config, that I can even check (backedup) is carbon-copy of the one I just re-did, just with different network and docker names (yeah, I like to rename my stuff). And the authelia update came, and it just crapped itself. https://ark-cloud.xxx.fr/index.php/login went: Your connection is not private Attackers might be trying to steal your information from ark-cloud.xxx.fr (for example, passwords, messages, or credit cards). Learn more NET::ERR_CERT_AUTHORITY_INVALID [ADVANCED] Blabla man-in-the-middle-dumbed-down explanation from chromium You cannot visit ark-cloud.xxx.fr right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later. and the newly made for testing purposes nextcloud docker https://nextcloud.xxx.fr/ returns: Different computer, different browser, even using smartphone with wifi disable on data, same result. Here where I'm at. Everything looks like it works. Everything shows up like it works. Everything has been working like that for almost two years. And now it doesn't. If it at least threw a bunch of errors at me, that I can deal with. I went through the same setup process dozens of times on the sole purpose it would finally throw an error at me, throw something I can chew on and that would be a starting point. So far, only thing that changed between when it worked and now, is updating letsencrypt. Not even jumping versions, I basically applied updates to it at worse a week late, and now it's a from-scratch freshly created new install, with no possible reminiscence of the past. Where is something wrong? If it's wrong, it used to work as is, but I'll hammer myself that it's not okay anymore that way. At that point I HOPE something I did is wrong. Or maybe is it that now OVH requires the use of the DNS plugin? I don't know. Interresting behavior though, neither of the messages change when I actually shut down all 3 containers. Still returns the same invalid certificate and didn’t send any data respectively. Yes, even after the emptying of the browser's cache, or trying from a computer that never visited them too.

Before you ask, no diagnostics attached yet, because I'm just waiting for an other drop to happen to make it lay one hot just out of the oven, but still putting the post out in the wild in case someone has a valuable input about it! R720 Dell power edgy, 4port NIC at the back. Randomly losing connection, console reactive, server reactive, everything else looks normal, but no amount of unplugging and plugging back in the ethernet cable fixes it, no amount of bringing the port up or down from the GUI either. Reboot needed. Tried configuring port 4 into eth0 instead of port 1, and it happened again yesterday. Twist: I have a SFP+ back-to-back link to an other computer that allowed me to access the webGUI through said link, so no, it's not a GUI crash, and indeed, everything's normal on it, except obviously that the server lost connectivity to the network and thus also internet, every dockers/services I run being thus down for everyone else too. If anyone encountered that on these servers already, I'ld gladly hear about it! I've heard that this issue was actually kinda known regarding the R720 and alikes, and I'm contemplating the option of getting a PCIe NIC as a work around, and thus if anyone has an example of a good reliable affordable PCIe card 2ports or more NIC that would also work in low profile (I may or may not mount it in the low profile slots, don't know yet), let me know! Side note: No, I can't just use bounding to have all 4 ports connected as one and give me extra fail-over and stuff, my router is too dumb for that and my switch is unmanaged and doesn't support it. My network equipment is quite le basic aside from that back-to-back SFP link... that doesn't count as a network.

@saarg well basically there wasn't much point detailing it atm because, trying stuff, I already over-ran the limit of 50 certificates / week, so I'm already effed and anything kind of support I would get now would be basically useless. For some reason it tried to renew the certificate many time despite it being valid, domain and subdomain staying the sames, and due to expire in 2034. So now I'm on hold a week. Great. Before you ask, my setup was pretty similar in every functional way to the one of Space invader one for nextcloud, on owncloud. docker network, edited owncloud's config.php, edited nextcloud's subdomain sample file into one that works for owncloud, using a no-ip domain to track my dynamic IP and a CNAME redirection to a subdomain of a domain I own, everything the exact same functionally speaking. I noticed that since the last update (or sometime since like summer 2018 when I setup up this whole thing) the default nextcloud.subdomain sample file changed. old: location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_nextcloud nextcloud; proxy_max_temp_file_size 2048m; proxy_pass https://$upstream_nextcloud:443; } new: location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app nextcloud; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } Trying to replicate the changes to my custom owncloud.subdomain thing yielded no result. Chrome's reaction is just "cunnekshion not private NET::ERR_CERT_AUTHORITY_INVALID" , and the "read more" just says "You cannot visit censored.censored.dork right now because the website uses HSTS" , so truly down for everyone who isn't the host of the whole thing (not CRITICAL, since only 3 people use it beside me, but widely bothering, since it's their off-site backup but also their way of accessing their data when not home, and one uses it for keeping versions of their game development sources backed up and versioned on a daily basis). No amount of Firefox, Opera, vivaldi or Edge give access. I made a full appdata folder duplicata of the whole stuff before starting to tinker with anything obviously, example of life: I killed a SSD by sending 12v into 5v just 2hours ago, so indeed I do backups since I'm a dork. Thing is, it just went from a configuration (again, nothing fancy, similar to what SIO did in video few months later) that worked flawlessly for 1year and 10 months, to something that doesn't work after an update.

Okay, I've been wrestling with Owncloud for the last 9 hours straight because I didn't suspected let's encrypt could actually have a derp. I hate myself for updating. It just dropped its job, aka, providing certificate for owncloud to a domain I own, and I have been trying to setup temporary owncloud, event tried switching to nextcloud (been thinking about it for a while now), but either of these, at the instant I restart them on the docker network to be listened by letsencrypt to be forwarded and cert to the subdomain, it goes haywire.

NVS315 arrived, slapped it into the server. Outputs console's video no issue. And if obviously disabling onboard video completely cuts off iDrac console, for some reason it even borked as far as preventing me to access bios via the NVS315 displaying to a physical screen. Obviously means trying to boot to UEFI with it is a no go. Had to hard reset BIOS to get access again, and now I'm having a hard time remembering the exact magic combination of parameter I dialed to silence that monster. Seems like that route is a no go as a work around the syslinux kernel derp.

I have a NVS315 incoming in the mail, I'll try UEFI boot with it on unraid and embedded video controller disabled. Will let you know by editing this message. It's a single slot low profile. Knowing I will only every use 2 of the 3 available low profile slots (1 for a SFP+ 10Gbps double port card, 1 for an HBA), I very much not care about having a card doing nothing taking up the 3rd slot. For info, before you ask about the HBA: - Yes I do have a mini mono Perc H310 already, driving the front back planein JBOD, for the hard drives. But I didn't wanted to put my 2.5 SSDs in the front 3.5 trays, nor have them run off the same controller, which is 8x PCIe x2, so hitting both the array and the cache could lead to a sad bottleneck. - Yes I added a SAS HBA to throw my SSDs in the back of the chassis, internally, on their own dedicated controller, in the corner on top of the PSUs, stacked on double sided tape, so I can still have a full height PCIe card in the Riser3. - Yes, I found where to sip 5volts on the motherboard to power them.

I can boot seamlessly without intervention on both front and back USB ports on the R720. That's why it's weird af. The internal USB port is near the PSU and one of the PCI slot "chambers". Lifecycle controller completes inventory check on boot without a single error, and iDrac is clean, configured and show no quirks. I litterally painfull went through every menu in both iDrac, LifeCycle and the Bios to check if I was missing something, and the sole thing I saw was in bios, asking to activate or not the internal USB, which I did, and even tried the old "switch off and back on" thing just to check on an eventual bios derp. And it's not like the port was physically broken, since when hitting F11 to go to the boot menu before it actually tries to boot to the device, then it shows up. It's just when it automatically does its thing, following the boot order which is with the usb key first and the raid controller second, then it can't find the USB anymore, just the hba/raid controller. That's just plain weird. As for the UEFI, yes, it's enabled, since that same unraid flash drive I booted in UEFI on an other computer as a sanity check, and it went seamlessly through the boot process and all. If UEFI wasn't enabled on it, it wouldn't even reach unraid's boot menu in UEFI mode. The "Failed to Allocate memory for Kernel command line, bailing out booting kernel failed: bad file number" is VERY MUCH not a "I'm too dumb to enable uefi", but more "syslinux craps its pants" or "some systems firmwares are derp with syslinux", it's a known issue, some managed to fix it, no all said how, the few who said I tried their way to no avail. So I'm reaching to unraid's community hoping people would shoot ideas or eventually if someone actually had this happen to them on a R720, and fixed it. Both the syslinux/firmware issue, which seems to plague several systems, and if any chance, the vanishing internal USB issue.

R720 here, same issue. Also, fails to boot reliably on internal USB in legacy mode, have to go through F11 menu at boot and manually select it, because just setting the boot order doesn't stick, when trying to boot without intervention it doesn't detect it and just pulls up the raid controller. Damn you, Dell.

I thank you but I basically repaired my install myself about an hour after sending the message. I had to deviate a bit from your manual update infos since the installation was borked, had to disable some apps through command line for the update to proceed, and I have a "weird" array arrangement, and as such the folders had peculiar read/write rights to manage, but all good.

I updated my Owncloud docker today. Nice. I hecking forgot this docker needed a whole procedure to update properly. Nice. Dat docker "Update All" button... Unraid Version: 6.8.0 btw.

Whenever SpeedTest is on, other dockers won't work properly. Deluge, Krusader, Resilio for example, start but will crash/resetloop if SpeedTest is already on.