tjb_altf4

@Partition Pixel it should be: ghcr.io/chia-network/chia:latest I updated yesterday, and I'm currently on 1.1.6.dev0 according chia version You should only need to press the check for updates button on docker page, if you want to force a check

Out of the box this docker isn't configured optimally for logging, after some research these are two changes I've made to get better logging. Both changes are made to the config.yaml file that will be in chia's appdata folder: change log_level to INFO (from WARNING) change log_stdout to true (from false) Change one adds more useful info to the logs, change two pushes the logs to the standard docker logging mechanism, which means it is visible from the GUI's log button. Happy hunting!

Looks like new image has been build, it should appear shortly. It is recommended to update as soon as you can.

Put a fan on them so there is air moving through the enclosure (or across the bare drive), this will bring the temp down significantly.

No resume at the moment, so make sure your jobs have finished before you restart/update the container. note: this is a problem on all platforms, not docker specific

Make sure you either disable your old NIC, or ensure the 2 NICs are on different subnets. If the 10GbE is now your primary, or you have swapped around IP/subnets etc, make sure you also power cycle your network equipment.

This document linked from their FAQ should give you a good idea https://www.chia.net/faq/#faq-8

My server is busy 24/7, so I don't use S3, so I cannot confirm either way.

Did CA settings get reset to default on a recent update ?

Sorry if this has been covered, but does the plugin work with multiple pools? Any gotchas? Thanks.

Do you still see the 100% usage when the array is stopped?

From 6.9 onwards the global setting was deprecated due to multi-pool functionality, and is now set via each shares settings. For each share, you can now choose the type of pool use (including none), and the pool you want to use.

That will work, all that card does is pass the lanes to the nvme, so as far as your system is concerned it is directly connected. I've run a single nvme adaptor like this one in the past and it worked well.

Documentation is a little out of date for newer versions of Unraid, which has simplified the process to a drop down

Assuming you're on version 6.8.3 or higher... Create the pool (if it doesn't already exist), then go into settings and convert it from the default raid1 to raid0 using the dropdown in the pool settings (under balance heading), select raid0 and press balance.

169 address means unraid can't reach a DHCP service, i.e. the one on your router. Try power cycling your network equipment to start with. On the off chance you LAN is 2.5GbE, make sure your installing the latest unraid release (6.9+)

I would keep latest backup locally (from CA backup), you could then do incremental backups to a remote location based off the local backup. If you really don't want to keep the local backup, you could remove after the remote backup is complete.

Try running the "detect" minimum PWM value again, or trying manually setting it higher.

Hi, did some quick investigation on this looking into @folic86's issue, and the packet capture data is being written directly to the container itself. My experience: 10min of packet capture blew up the container size by 2GB stopping packet capture, stopped the container from increasing in size further forcing a container update returned the container size to normal. I would imagine this data path would be best pushed to appdata folder or a share etc.

For your distance, fiber is the appropriate choice, direct attach copper (DAC) is a cheap and effective alternative when dealing with short distances. This video should cover the rest.

I'm surprised the sandisk flash drive didn't work, I've had a few of the USB2.0 & 3.0 (not 3.1 though) drives and have worked well for Unraid. In case you are confused about the talk about the USB's GUID, that is what the license gets tied to.

I've been loving this plugin, but any chance you can add the ability to label the fans, and for this label to be also reflected in the dashboard (instead of FAN 0, FAN 1) so we can more easily identify the fans/fan-groups? i.e. CPU FAN, HDD FAN, FRONT FAN, REAR FAN etc. This would greatly improve managing the configs and monitoring.

On top of @Vr2Io's suggestions, it can be useful to limit the cores (cpu pinning) for downloaders such as deluge, particularly to exclude the cores primarily used by Unraid i.e. cores 0+12 in your case. I've noticed deluge will use all resources available when moving files, I've seen it spin up 32 cores on my 1950X when I've moved multiple torrents. Here is how my deluge instance is now configured As mentioned, I also have a separate disk off the array dedicated to downloads. Only the finished product (i.e. unzipped movie file) gets moved to array, while the torrrent and associated files stay on downloads HDD. I set this up long ago on an unassigned device, but if your on 6.9+, setting up on a pool makes more sense.

I see the same issue as @ionred, also specifically only on main.