Closed tamirweiss closed 2 years ago
I just downloaded Ejectify and I'm experiencing the same issue. I have a similar issue with only one SSD connected to a hub while running Monterey 12.3.1. Clearing these error messages are a pain!
If it's of any help, the 'Display turned off' seems to be the best option, but as I said, I still get the error messages from time to time.
Can you check this FAQ, especially the Console part, to see if there's any information indicating why unmounting fails?
Also, for the ones using a hub: does it work (better) when connecting the drive directly to your Mac?
I have yet to try the suggested steps. However, something that has caught my attention is that my Mac is connected to my hub via USB-C. I suspect that the Mac is turning off power to my USB C hub when in sleep because the Ejectify software only dismounts the drive. This is okay the first time because this is what the app is intended to do. But I'm guessing that my Mac intermittently turns on because I have allowed my Mac to wake while sleeping to receive and transmit data.
I'm assuming when doing this, the Mac actually turns on power back to USB hub thus remounting the ssd. So IF I'm right, 3 things can be attempted to overcome this:
1) [Easiest] Turn off wake for network access assuming this is the cause of cycling output power from the Mac. Downside is you won't have real time notifications or data upon start up. 2) [Moderately easy] Turn off Mount after delay. This should prevent your ssd from remounting when the Mac power cycles. Downside is you might need to remount your drives every time you login. In my opinion this defeats the purpose of the app. 3) [Tedious] Connect the ssd drive to an external power supply, which in my case is my monitor and not my USB hub. My monitor has the feature of using its built in IO pins given that is mounted to the USB hub via USB-A. Ensure the sleep mode on your monitor menu does not cycle power in which case it does for me. I'll review this option for the next 24 ~ 48 hours.
@tamirweiss, unfortunately all options seem to not work for me
Have you tried turning off Wake for network access? If so, does it solve your issue?
The issue still persists even if Wake for network access is on or off. As for my hypothesis, seems like its moot option 1 and 3 showed no tangible results. Any other ideas ?
default 00:09:48.276784+0300 diskarbitrationd unmounted disk, id = /dev/disk3s1, ongoing.
default 00:09:48.280447+0300 kernel apfs_stop_bg_work:1065: disk3s1 Volume Backup is unmounting, stop any bg work
default 00:09:48.282814+0300 kernel apfs_log_mount_unmount:1889: disk3s1 unmounting volume Backup, requested by: umount (pid 6909); parent: diskarbitrationd (pid 125)
default 00:09:48.282824+0300 kernel apfs_vfsop_unmount:2740: disk3s1 waiting for purgatory cleaner to finish
default 00:09:48.295981+0300 kernel apfs_vfsop_unmount:3074: disk3 nx_num_vols_mounted is 0
default 00:09:48.313610+0300 kernel apfs_vfsop_unmount:3087: all done. going home. (numMountedAPFSVolumes 7)
default 00:09:48.321448+0300 diskarbitrationd unmounted disk, id = /dev/disk3s1, success.
default 00:09:48.389679+0300 deleted Disk was unmounted
default 00:09:54.991100+0300 diskarbitrationd unmounted disk, id = /dev/disk5s2, ongoing.
default 00:27:02.721198+0300 kernel apfs_stop_bg_work:1065: disk5s2 Volume Home Time Machine is unmounting, stop any bg work
default 00:27:02.801351+0300 diskarbitrationd unmounted disk, id = /dev/disk5s2, failure.
error 00:27:02.802685+0300 diskarbitrationd unable to unmount /dev/disk5s2 (status code 0x00000001).
default 00:27:03.108920+0300 mds Unmount while stores closing on device:16777236 0x7fc8457f324f; ignoring
default 00:27:03.117819+0300 mds volume:0x7fc845f5d04f vsd:0x7fc84c77084f ********** unmount setting -1
default 00:27:10.118371+0300 mds volume:0x7fc845f5d04f vsd:0x7fc84c77084f ********** unmount setting 1
default 00:27:32.402342+0300 mds Unmount canceled. All stores just finished closing. Schedule disk for remount device:16777236 0x7fc8457f324f
Does this help? I couldn't find anything about "Dissenter status", as suggested in the FAQ.
default 08:22:17.761615+0300 itunescloudd <ICInAppMessageManager: 0x7ff26ca1a890> failed to download image 3e2f02a7-b772-4355-9605-5df269200f1b for message [com.apple.Fitness:c1e93f37-41b0-4c48-8543-901f445a2a3d, Native, (valid from (null) - (null)), download=1]. err=(null)
default 08:22:17.761694+0300 itunescloudd <ICURLSession: 0x7ff26bf2f030> Checking request queue (counter = 111).
default 08:22:17.761698+0300 itunescloudd <ICInAppMessageManager: 0x7ff26ca1a890> Downloaded 0 resources for message com.apple.Fitness:c1e93f37-41b0-4c48-8543-901f445a2a3d
default 08:22:17.763076+0300 mDNSResponder [Q2617] Received acceptable 60-byte response from <IPv4:BBRPCbcn> over UDP via en0/6 -- id: 0x955A (38234), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/1/0/0, BBghxgIt IN A?, 1890 IN A BBeNKuLU
default 08:22:17.763243+0300 mDNSResponder [Q2617] Handling concluded querier: BBghxgIt A IN
default 08:22:17.763410+0300 mDNSResponder [Q13891] Received acceptable 103-byte response from <IPv4:BBRPCbcn> over UDP via en0/6 -- id: 0x1C03 (7171), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/0/1/0, BBghxgIt IN HTTPS?, BBavcDKm 824 IN SOA BByFMIzF BBEFJxLX 2017033724 86400 86400 86400 86400
default 08:22:17.763536+0300 mDNSResponder [R6666->Q58316] getaddrinfo result -- event: add, ifindex: 0, name: BBghxgIt, type: AAAA, rdata: <none>, reason: query-suppressed
default 08:22:17.763685+0300 mDNSResponder [R6666->Q2617] getaddrinfo result -- event: add, ifindex: 0, name: BBghxgIt, type: A, rdata: BBeNKuLU, expired: no
default 08:22:17.764168+0300 mDNSResponder [Q13891] Handling concluded querier: BBghxgIt HTTPS IN
default 08:22:17.764461+0300 mDNSResponder [Q7171] mDNSCoreReceiveResponse ignoring <mask.hash: 'Cy+9ej1A9VgEyxAbzgOR3w=='>
default 08:22:17.765075+0300 mDNSResponder [R6666->Q13891] getaddrinfo result -- event: add, ifindex: 0, name: BBghxgIt, type: HTTPS, rdata: <none>, reason: no-data
default 08:22:17.766253+0300 kernel [IGFB][LOG ][DISPLAY ] getCurrentDisplayMode: FB=1 fCurrentMode = 0x80001000 fCurrentDepth = 0x1, fBootDisplay = 0.
default 08:22:17.766164+0300 mDNSResponder [R6666] getaddrinfo stop -- hostname: <mask.hash: 'bW4xrv00WeIXRIu+vZdD7Q=='>, client pid: 2603 (CalendarAgent)
default 08:22:17.766259+0300 kernel [IGFB][LOG ][DISPLAY ] Setting current mode to 0x80001000 and depth=0x1, bPortraitMode 0, bAnotherRun 0.
default 08:22:17.859801+0300 mDNSResponder [Q28129] Sent 44-byte query #1 to <IPv4:BBRPCbcn> over UDP via en0/6 -- id: 0xA7B4 (42932), flags: 0x0100 (Q/Query, RD, NoError), counts: 1/0/0/0, BBVfkOnv IN HTTPS?
default 08:22:17.860532+0300 Ejectify Dissenter status: kDAReturnBadArgument | Unknown | Unknown
default 08:22:17.861418+0300 mds diskDisappearedCallback Unexpected:0x7fc8457f324f
default 08:22:17.861470+0300 mds Handle disk disappeared device:838860921 0x7fc8457f324f
default 08:22:17.862070+0300 mDNSResponder [Q28129] Received acceptable 117-byte response from <IPv4:BBRPCbcn> over UDP via en0/6 -- id: 0xA7B4 (42932), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/0/1/0, BBVfkOnv IN HTTPS?, BBrCpFBv 131 IN SOA BBrowriZ BBRYnMDX 1 7200 900 1209600 86400
default 08:22:17.862268+0300 mDNSResponder [Q28129] Handling concluded querier: BBVfkOnv HTTPS IN
default 08:22:17.861679+0300 mds diskDisappearedCallback Unexpected:0x7fc84c72784f
default 08:22:17.862310+0300 mDNSResponder [Q42932] mDNSCoreReceiveResponse ignoring <mask.hash: '6QThWcQDtQJroXh+cmFWVw=='>
default 08:22:17.861702+0300 mds Handle disk disappeared device:838860920 0x7fc84c72784f
default 08:22:17.862575+0300 mDNSResponder [R6664->Q60253] getaddrinfo result -- event: add, ifindex: 0, name: BBVfkOnv, type: HTTPS, rdata: <none>, reason: no-data
default 08:22:17.862643+0300 mDNSResponder [R6665->Q28129] getaddrinfo result -- event: add, ifindex: 0, name: BBVfkOnv, type: HTTPS, rdata: <none>, reason: no-data
default 08:22:17.861939+0300 mds diskDisappearedCallback Unexpected:0x7fc8457fe24f
default 08:22:17.862056+0300 mds Handle disk disappeared device:838860919 0x7fc8457fe24f
default 08:22:17.863297+0300 mDNSResponder [R6664] getaddrinfo stop -- hostname: <mask.hash: 'oYw1SE/A4lJk/hTwy06GVQ=='>, client pid: 2603 (CalendarAgent)
default 08:22:17.863177+0300 CalendarAgent nw_endpoint_resolver_update [C93 Hostname#833854e2:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Adding endpoint handler for IPv4#d2b497f3:443
default 08:22:17.863305+0300 mds diskDisappearedCallback Unexpected:0x7fc84e78044f
default 08:22:17.863235+0300 CalendarAgent nw_endpoint_resolver_update [C93 Hostname#833854e2:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Adding endpoint handler for IPv4#9790ebf5:443
default 08:22:17.863357+0300 mds Handle disk disappeared device:838860918 0x7fc84e78044f
default 08:22:17.863372+0300 CalendarAgent nw_endpoint_resolver_update [C93 Hostname#833854e2:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Adding endpoint handler for IPv4#ee7cc0c7:443
default 08:22:17.863600+0300 CalendarAgent nw_endpoint_resolver_update [C93 Hostname#833854e2:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Adding endpoint handler for IPv4#60b4d17f:443
Found one! This is after switching to 'System starts sleeping'. Pasting here with a few lines before and after if it helps to get context of the issue.
Could you both try the following and let me know the result:
Run Ejectify (temporarily) using administrator permissions to see if (un)mounting works more reliable. See this comment for instructions. Make sure to keep Console open as otherwise, Ejectify stops running.
Temporarily enable the Force unmount option to check whether another process is blocking the disk from being unmounted.
Quick update - I tried 'Force unmount' before and it did not solve the issue. However, since I tried running Ejectify as root I did not encounter a single issue! I will keep watching it to make sure this is stable, and will report back here in a few days. So far so good!
Happy too soon.... It happened again. Only once so far. This is what I was able to find in Console:
default 17:47:24.123716+0300 runningboardd Invalidating assertion 197-173-74114 (target:[anon<Ejectify>(501):18892]) from originator [daemon<com.apple.WindowServer(88)>:173]
@nielsmouthaan any suggestions on things that we can attempt ?
What I've seen working with others is the following:
@Kuma-99 are the number of notifications reduced since running Ejectify?
I think I've tried everything besides connecting the disks directly, which would make the whole thing unusable for me anyway. Any other ideas? Any log files that will help you troubleshoot this?
Temporarily connecting the disk directly gives clarity on whether Ejectify fails to properly work because of external hardware (the USB hub).
Short-term there's nothing I can do to improve Ejectify for your cases if my other suggestions are not helping. If this makes Ejectify useless, contact me via this form and provide the email address used to purchase Ejectify so I can initiate a refund.
About running Ejectify as root - you mention that Console needs to be running while doing it. Does it have to be started (meaning collecting logs) or is it enough that the app is running, but in a paused state?
When you run Ejectify as root via the earlier mentioned command and you close Console, Ejectify will quit too. Hence, you'll need to let both run.
Are the volumes encrypted by the way?
No they are not encrypted.
By the way, after a long weekend, I found my Mac has crashed, and the Apple log seems to indicate it is related to the unmount command. I would love to share this log with you, but I am not comfortable uploading it here, so if you have a private means of sending you data, I would prefer sending it there.
You can send it to nielsmouthaan a t me.com
Does Console needs to keep recording the whole time, or is it enough the app is running?
On Apr 28, 2022, at 12:55, Niels Mouthaan @.***> wrote:
Could you both try the following and let me know the result:
Run Ejectify (temporarily) using administrator permissions to see if (un)mounting works more reliable. See this comment https://github.com/nielsmouthaan/ejectify-macos/issues/34#issuecomment-1038299356 for instructions. Make sure to keep Console open as otherwise, Ejectify stops running.
Temporarily enable the Force unmount option to check whether another process is blocking the disk from being unmounted.
— Reply to this email directly, view it on GitHub https://github.com/nielsmouthaan/ejectify-macos/issues/38#issuecomment-1111995332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTRAS6XNGJJAETDGTDIPSDVHJN7VANCNFSM5UHKSGIQ. You are receiving this because you were mentioned.
Console needs to run only when you want to collect logs.
This planned enhancement is a possible solution to this issue. It will disable the notification entirely.
I have 2 external SSD connected to a hub. Running Monterey 12.3.1
I have tried the various 'unmount when' options and some worked better than others, but none worked 100% of the time. I would appreciate some help in further troubleshooting this, as I would really love to get it to work 100% of the time. Should I have the Console app running and logging during the problematic sleeping period? I have never used Console before...