tjb_altf4

Seems this was a PEBKAC error, all working now!

Currently on 2022.03.07, on Unraid 6.10.0-rc3o Attempting to start preclear for multiple disks results in fail dialog, I can start preclear on an individual disk however. Can't see anything reported in preclear log (or syslog).

My experience is that as soon as nested virtualisation is enabled, performance tanks. I needed this for docker on a windows dev VM. If I'm reading your use case correctly, you maybe be better of creating a VLAN for your work VMS, and having all that traffic isolated on that VLAN and routed through the VPN. This is also a reasonable advanced use case, but I think you will get a better result and more options for help with configuration that way.

Unraid will only update when its told to (Auto Update plugin, CA backup, manual etc). One way to force it to absolutely stay on the same version is to change latest to the specific tag version. e.g for Unifi controller I need to ensure I stay on a fixed version for stability, so instead of latest: linuxserver/unifi-controller:latest I use a specific tag version: linuxserver/unifi-controller:version-7.0.23

This is potentially one of the directions the UPC component in 6.10 could be leveraged, that's my hope anyway.

Checking on my server, I've been running 10.7.7-1-01 for at least 3 months.

looks like the database tried to migrate and things went pear shaped after that. I'd say it's the same issue as some others have seen

@DammitDaphne censor your credentials

Same, Dynamix Auto Fan Control is great at controlling based on HDD temp, as long as everything is detected properly. Dynamix System Temperature is the temp monitor he seems to be describing.

Hotio's Lidarr template lets you pick if you're after something right now.

Thanks @Squid

Doesn't appear in autocomplete. It has its own entry on the tools page, and does not exist as a subpage, but its own page i.e. https://hash.unraid.net/Tools/Preclear

I noticed preclear plugin doesn't show, is there something the author needs to add to ensure its picked up?

it gets worse, Newegg RMA'd the board, Gigabyte stated it had socket damage and it would cost $100 to fix. Newegg opted not to fix, then sold it to a customer (Steve) The gigabyte RMA ticket was still on the motherboard...

In addition to @Frank1940's information, also note this PSA from LimeTech, which identifies problems with SanDisk USBs in recent times.

Although likely due to a configuration option I don't fully understand impacting its operation, highwater has never worked as advertised for me. One disk would just get pounded into the red zone, while the rest of my array sat quite empty, forcing me to manually move files around so mover didn't fail. After switching to most-free, my disks started being utilised across the array in a somewhat predictable manner.

@spacezmonkey the path in the first script is missing the leading forward slash

Enabling help in the GUI provides clarification of the options (for this and many other options).

Unraid requires a 64-bit CPU, I don't think there where any x86-64 processors that had DDR2.

Upgraded without issue.

Unraid shows a container as stopped if it shuts down before timeout. Normally a docker will shutdown gracefully, but if for some reason it doesn't, the timeout gives you a way to force shutdown without you needing to manually intervene.

Although docker's documentation has a bunch of great info for getting various stats including this one, you can access this report directly in the Unraid GUI like so Unraid GUI > Docker > Container Size [button]

The design is pretty crude at the moment, once I finish my current project I'm going to work on the v2 which should have improvements and potentially incorporate easy to source backplanes. I've got a spare server case to work with, so I'm hoping I can iterate the design quickly over the next few months. I'll have to dig out the v1 STLs, I'll add them here when I find/regenerate them. - How does the bottom part look like Identical to the top, but with a layer of thin adhesive eva foam to add some vibration dampening qualities. I ended up doing it this way as it meant horizontal components, left and right halves, used the same STL. - How much tolerance do you have on the drives The model was designed with zero tolerance, because I knew the print could go either way and I could adjust It's ended up as a "firm, but gentle press" haha, but I need to design a mechanism to allow easier retrieval. - Why not 15 drives instead of 14? I wanted to maintain a reasonable airgap for cooling and 15 wouldn't work for that, besides the overhang from the side of the case restricted use of the full width of the case. - Any vibration issues? between the base material and the use of plastic/filament for the mounting, its very minimal, even with the current 28 drives. - How is the airflow and drive temps? Good, no temp warnings over summer here in Oz, typically low 30C for front, and high 30C in back... second fan for push pull would help a lot. Also using 140mm gave a big improvement in terms of airflow and pressure, while actually being quieter than the 120mm fans they replaced. - On the rear, I see two squares, are these just there to hold up the mount? Yeah, just in lieu of rear fans... originally made for support on the sides but I miscalculated the thicknesses so they didn't fit there. Its needed as its a tight fit getting drives in and there's no other support there currently. - How did you glue/stick/mount them together? These were plastic welded with a filament stick and a dremel, but I've since worked out the filament I 3D print with (Prusament) can be bonded with acetone, which is easier, neater and results in a stronger bond. (note: acetone bonding doesn't work with plain PLA) - Did you screw the cage to the rack, or is it just sitting there loose? Friction fit would best describe it, but yes not fastened. An improved design would see some threaded inserts added to the finished print so I can affix to the chassis

The trick is the entire dockerfile is build time, so you'll need to move that copy logic into the entrypoint (or cmd), which is called later at run time. As you have an existing entrypoint used to start the application, you might have to do some testing to see what works best for you. This is what one of my dockers looks like, copying the .sh from the build folder COPY docker-entrypoint.sh /usr/local/bin/ ENTRYPOINT ["docker-entrypoint.sh"] You could create your own docker-entrypoint.sh to manage those copy steps (don't forget to chmod +x the file). I've added the old entrypoint command here at the end of the docker-entrypoint.sh... this "should" work, but you might need to do some further research and experimentation beyond this. #!/usr/bin/env bash # copy logic... you should put file detection here so as not to overwrite files on each startup cp -n /usr/src/app/cloudcmd.css /config/cloudcmd.css cp -n /usr/src/app/dist/index.html /config/index.html cp /usr/src/app/banner.png /config/banner.png cp /usr/src/app/favicon.ico /config/favicon.ico cp /config/cloudcmd.css /usr/src/app/dist/cloudcmd.css cp /config/index.html /usr/src/app/dist/index.html # start cloudcmd /usr/src/app/bin/cloudcmd.mjs exec "$@"