NAS

This completely ignores the whole docker development push. From a unRAID user standpoint there is no longer a difference between "over the network" and "local" so any real solution cant differentiate either.

It seems we would be considering this as a fix and issue resolved? This would not be ideal as leave it hanging about for all other access methods will shoot someone in the foot eventually. Midnight Commander has been mentioned but what about ajax files type tools or even XBMC. Docker opens up easy access to many tools and all of these have the potential of seeing this bug and we cant hope to educate every users to prevent this happening again. Is there no possibility of a more fundamental fix that can be put in place? FYI if we implemented this solution I would also need to change the logic of how I work in a very similar fashion to Joe L

The plugin has been updated. We all say thank you.

We have slipped 9 versions out of date ` v2.17.3` released Apr versus `v2.21.0` released Aug. Too many changes to list https://github.com/docker/compose/releases Can I suggest with such a fast paced cadence upstream we look at a quarterly catchup backstop to avoid such sizable version drift. Excellent project. Invaluable.

Right but it should be on users with problems to work around or disable modules and not for everyone else to hunt out and install addons for mainstream hardware. To be clear I am not critiquing you work, it is excellent, but this is not a rare component and has been on countless boards now for >10 years. It is a slippery slope.

Whilst it is excellent that @ich777 created this package, drivers should be in the core OS and addon should be for edge cases only. Who is tracking feature requests these days @limetech this needs added to core.

Thank you for the update to `Docker Compose version v2.17.3`. The fix for pull screen glitches is a welcome fix.

Could we trigger an update on a semi regular basis? I do not know what your build pipeline is but I would like to avoid getting into a situation where we are essentially nagging you as a trigger. Even once a month or perhaps on each minor release could be automated.? Ultimately the end goal should be to make your life easier helping where we can; forking, splitting effort or taking away from your work should never be our goal.

Can I ask about release cadence. Compose is now 13 versions out of date, is there any way we can assist in increasing this cadence? Does the addon need work every time the compose dependency changes? If so can we split this into two addons, one for compose itself and one for manager? Could we request compose be shipped with unRAID itself, would that help? Trying to understand where the bottleneck is as we just passed the 200 days mark since the shipped version of compose was released and that is too long. This post is not a criticism at all, just a realistic shout out to see if we can find a way to make this burden easier for you.

Could I request an option to bypass this feature completely please. This would be a real quality of life improvement for compose users.

This is a very long thread but I can only find issue reports and not a fix. How do I disable the image update warning entirely? I find myself starting to ignore Fix Common Problems because 99/100 it is docker noise and that cant be a good thing when that one time is important.

Very much this. Is this an accepted feature request?

I can confirm that spinning down a drive before you unpower it reduces or even removes completely the unpleasant noise. This is expected behavior since these noises are caused by the very action of un-powering an actively moving drive. This is not USB specific it is also true of hotplug albeit harder to hear because they are typically within a chassis. I apologize if this was not clear. I started this discussion from a position of already knowing that reducing the power state has this impact. What was not clear is how far "down" we could take them and the best methodology to do this within unRAID.

Sorry for slow reply, I gave up trying to make my comments and quotes look pretty. I agree on `udisksctl`. We should not consider adding this as it is unnecessary. I only mentioned it as it had a documented caveat that seemed relevant to any similar approach. `If I implement a 'safely_remove' feature it will not be generic in the sense that it will not be done on every unmount. The user will have to add a 'safely_remove' command, and only USB devices will be operated on. You can appreciate doing a safe removal on a built in hard disk by accident. A reboot would be required to restore it.` Can we consider making this a button (or buttons) operation. I had imagined this never being event driven but rather would require a human button action in an identical manner to umount each and every time. This feels safer to me, allowing users not to press it of they choose (or even need) to do so if there are any edge cases out there. It would also let us add some safety where the button is only available within the correct context i.e. drive is not mounted. The term `safe removal` might be too harsh if we go this route since it implies not pressing would be `unsafe` which we have no proof is actually true. We can discuss terminology if this is agreed. `You can appreciate doing a safe removal on a built in hard disk by accident. A reboot would be required to restore it.` I agree that this would be a terrible situation but I expect that since we know `echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan` can reactivate a device we could create an action to undo this mistake. e.g. https://www.systutorials.com/docs/linux/man/8-rescan-scsi-bus.sh. I say this for two reasons. Whilst I agree with your conclusion about maintaining flash /boot writes is bad I suspect `I'm not sure a re-attach is practical for UD.` could also be covered by this generic scan/undo action without having to maintain a state or action memory. More importantly I would like to made sure hotplug disks are not excluded from this as there is no real need to limit it to USB as long as we can exclude arrays disks and have a scan/undo option. Should we create a new thread on this whole concept and discussions to attract more attention and make it easier to refer back to and google later?

This is good feedback and even better practical advice. Obviously it is expected behavior needing to physically re-plug a device that has been fully removed although I admit is it not intuitive behavior. It does in my opinion reinforce the concept that a `warm and fuzzy` state exists below umount where the OS has released even more control of the device for safer removal. We are in a strong position to cater for this unintuitiveness since we will know that the disk is still there and which bus it was on so in theory at least we can have a reattach button. One unconfirmed edge case from udisksctl manpage Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives. I am unsure if this impacts the more specific block action, testing will tell. I found linked via a previous suggestion this discussion discussing this approach on the Debian forums which is quite insightful.