Issues with sparsebundle after 11.3

Alas, I do not have the time to create another user account and wait for the problem to happen (or not); I am busy working with my machine. Before I go down that route, I wonder what theoretical ideas we can have about what causes these sparsebundle issues and how they could be user-specific. Considering that at least the issue with APFS-formatted volumes also happens in safe mode –

I am currently testing apps that have "control your computer" privileges under Security&Privacy – Accessibility to see if they might involuntarily mess with volume mounting in the Finder. But so far, no culprits found, and overall none of these app should actually be remotely involved in mounting/unmounting volumes. My prime suspect was ExpanDrive, I uninstalled it, but no win either.

I still think this is a Big Sur bug, but do not find a lot of reports online, which gives me pause. Or maybe there are just not a lot of people anymore that use sparsebundles.

I too am having trouble with a sparsebundle (Mac OS Extended, Case-Sensitive, Journaled) spontaneously unmounting since upgrading to Big Sur. I have no new insights to offer that have not already been noted in this thread, just another voice in support of there being a Big Sur specific problem.

I do not believe this is user account specific. I've got a personal Air and a work MBP. The user account management is completely different - enterprise vs. out of the box macos. The work MBP has all kinds of enterprise tools monitoring access to files (virus scanners, etc.); the personal machine does not. I use the same APFS case sensitive sparsebundle technique on both that primarily contain collections of git repos I'm doing software development on. Both exhibit this spontaneous unmount of the sparsebundle behavior. Apps that are accessing / modifying the content of the sparsebundle include a wide variety of command line and developer tools; in addition to the enterprise tools on the work MBP.

I've gotten frustrated enough by this that I've tried various techniques to try to insure I lose no more work:

1) My first, simple approach of having a script append a character to a file every minute to make the volume appear to be in use (and provide me a clue when the filesystem switched to read-only) did not provide a solution.

2) My next approach, creating git hooks so that whenever I made a git commit that would get immediately pushed to an upstream repository did not prevent me from losing modifications that had not yet been committed.

3) My current 'solution' involved creating a Hammerspoon-based filesystem watcher, so that whenever any file gets changed on the volume a script is run to rsync the changes of selected contents to Linux-based mirrors. So far that has saved me from losing any additional work, but doesn't speak well for the impact of Big Sur updates. (This began for me with 11.3; I encountered no problem from 2015 up through 11.2.

FWIW it seems as though the unmounts occur for me when the volume is relatively idle, but as noted above, periodically writing to the volume was insufficient. As I think others have noted, I don't believe excluding the volume from Spotlight indexing had any positive effect either.

I have been struggling with this same issue for months! Currently on 11.4. My sparsebundles were originally HFS+ (Mac OS Extended), and those would just unmount themselves at random times (generally when working with files within the bundle volume). So I figured, maybe Apple has been ignoring HFS+ testing and I'll recreate them as new AFPS bundles. Did that, cloned the data over using CCC (and of course kept the old bundles just in case things go wrong with APFS.) Now the behavior has changed -- With APFS, the volumes no longer unmount themselves, but many files or entire folders simply disappear at random times. Again, seemingly correlated with rapid file activity (e.g. saving a project file, building code, etc.) Whatever app I am using starts to wig out and show errors about the files missing. Ejecting the volume and then remounting solves it, but this is not a real workaround.

To earlier advice about decrypting bundles before upgrades, or other host disk issues: No. This has nothing to do what that. Both the host volume and the bundles checks out fine using Disk Utility. And as mentioned I even tried creating a new APFS disk image from scratch.

Apple clearly has a widespread bug in their Disk Image support on Big Sur. The process "diskimages-helper" is likely the where the bug exists.

The issue is intermittent, but frequent enough to drive you insane. Depending on usage, it may take a few hours, or a day or two. Generally when not actively using the volume it behaves -- You can check in and see the files are still visible. But soon after you start reading/writing files, it glitches out. Haven't been able to pin down the exact cause, but might try writing some stress tests.

Just to chime in: I have exactly the same issues. Strange enough, I have two of these sparse bundles (one for sensitive work related stuff, one for sensitive personal stuff), and only the work-related sparsebundle keeps disappearing. So far no loss of work but that's because VSCode is very good at preserving changes even if it crashes, somehow. Then again I just upgraded to 11.4 from 10.15 a week ago...

I literally just started googling for a possible solution, haven't tried anything yet, but solutions like "just unencrypt it" are frankly completely missing the point and make no sense whatsoever (and yes of course I have a backup. Who doesn't?)

Disk Utility says the volume is OK, and it seems to be unmounting during times of inactivity, but that might still be a coincidence. It's funny that it's only one volume that has an issue, although the other volume could be even more quiet, IO-wise...

Thanks for the extra insights about your 2 different bundle behaviors Jason. It's an intriguing detail.

I've been dealing with this problem for several weeks now and have also avoided losing any work. I too use VSCode and occasionally vim to do my development work with my git repos stored on a sparsebundle. I usually notice that the volume has unmounted when I save a file and VSCode barks at me about it or I run a git command, e.g. `status`, `add`, `commit`, etc. I always run git commands from a CLI rather than VSCode git integration. I don't know if that matters wrt data loss risk. When I realize the volume is unmounted, I remount it, `cd` back into the directory I'm working with in the CLI and carry on as normal. It's a pia but no work lost yet.

I have the same problem. New MacbookAir (M1, 2020) with BigSur 11.3 and 11.4.

Volume unmounts by itself from time to time, at least once a day.

I have two users on my Macbook and when I switch the users the volume unmounts almost immediately. That happens not everytime but in about 90% of user switches.

As a followup. I may have found a workaround for this.

I noticed that the bundle that doesn't spontaneously unmount lives in my home directory. ~, /Users/myusername.

The bundle that shows the erratic behaviour lives in ~/Desktop (so I can mount it by clicking).

I've moved that bundle from ~/Desktop to ~, and it no longer automatically unmounts!

Could still be a coincidence, I just did "mv ~/Desktop/name_of_partition.sparsebundle ~/" so the files did not really move on the disk, but it might still be a coincidence.

The downside is that you can no longer click the icon on your desktop to mount the volume, you either have to open a finder window to your home directory, or type "open ~/name_of_volume.sparebundle" in Terminal.

Can someone confirm that this solves their issue?

My bundle lives in ~/Documents. But: I did not experience unintended unmount now for several days! I did user switching some times in the past which always led to an unmount. The only difference are the new silent security updates of MacOS few days ago (end of June).

Thanks for the tip @jpcornet. I moved my .sparsebundle file my home directory and it has not unmounted on me now for nearly a week.

WRT to being able to double-click on a desktop item, have you tried creating an alias on your desktop to the image file? I would expect that work.

Since the latest updates by others to this discussion mention moving the sparse disk image to their home folder from either the Desktop or Documents folders. Perhaps it's a bug with the privacy protections?

Also, no one mentioned it but has anyone tried mounting the sparsebundle via the Terminal's "hdiutil attach" command instead of mounting via Finder?

I have also been experiencing this issue since May. I also removed the file from TimeMachine and Spotlight and still see the issue.

I will try moving the sparse bundle to my home drive and see if this works.

I know it’s a customer Forum.

I also have the conviction, that Apple customers should know, with associated details, that their problems are not unique. Apple is not in the habit of reporting this in this forum, or…?

My experience shows, that reporting bugs in this Forum (also) has a far better chance of spurring Apple into action, than ANY bug report, you may (only) send their way.

Now you’re here, you can lead my comments along the right channels to provide even a slight chance, that Apple solves the recently introduced problems with file handling, networking and reliability (not the most prevalent factors in marketing, I assume).

Recent Apple policy changes on privacy, and this and other similar recent bugs In file system and networking has made med decide, that my Mac Mini M1 was my last Apple silicon - and my last Apple device completely.

It will free my Apple budget up for other devices - I’m OS agnostic, but not fond of continued growth on the instability and bug front heavily limiting trust and functionality for ALL my active Apple products (several iPads, several iPhones, several Mac Mini’s and one remaining MacBook).

After Mac Mini M1 has introduced non-support of 30-bit color in UHD HDR certified monitors, I’m actually shocked how limited the M1 is in many parts. Speed is nice to have, but new limitations on quality and other options previously supported also count. My several years older Macbook Pro 13 (2018, 4 Thunderbolt ports) still has no problem delivering 30-bit Color to the same monitor using Big Sur 11.5.1 too (and also using several prior OS X versions). But, hey… we may wake up one Day, and also discover that 30-bit Color is no longer supported on existing hardware.

I wouldn’t be surprised any more.

@jpcornet Indeed, you seem to have found a workaround! After testing for 3+ weeks, I can confirm that I had not any sparsebundle unmount itself when the image resides in the user's home root folder "~/". Interesting, isn't it. I think this again points to some bug with permissions as has been discussed in this thread before. I could sometimes witness "spontaneous unmounting" when some app asked for file access permissions in ~/Documents or an external drive.

I can also confirm that the sparsebundle issue otherwise still happens in Big Sur 11.5.2. But now I have moved all sparsebundles to the home directory. Bug report submitted to Apple, and nothing will happen, as usual.

There are many other serious issues in Big Sur, to be discussed in other threads.

I can confirm that, my sparse bundle would start having problems every few hours, sometimes after ten minutes, files would disappear, then I wasn't able to eject it anymore. I moved the sparse bundle in my home directory, and boom, working like before. Huge thanks to @jpcornet and the community. hope apple fixes this "soonish"...