Issues with sparsebundle after 11.3

I also have these issues with one mounted, encrypted APFS sparsebundle, size around 40GB. Did not have any issues with sparsebundles under Mojave and just upgraded to Big Sur 11.4 a few days ago. Symptoms are like others have reported: File access on the mounted volume works fine, then all of a sudden all access fails. Clicking into folders of the volume's root directory shows empty content, w/o error alerts.

For me this is very serious as I have an app accessing a database on this mounted volume. Whenever I start using this app, I now repeatedly run into this issue in between a few minutes, making the whole setup unusable. My app start throwing errors. Did not find anything useful yet in system logs.

And yes, ran disk repair on both volume and container and nothing wrong is found.

Suspicion: Maybe this access failure has to do with security permissions under Big Sur. The app I am using to access the sparsebundle volume has permissions to access the "Documents Folder" under System prefs, Security&Privacy, Privacy, Files and Folders. I wonder if macOS has a bug that treats mounted images as "removable volumes" even if the underlying image file resides under ~/Documents. Since my app in question does not have "removable volumes" neither allowed nor listed and does not ask for such a permission.

I will monitor if my problematic sparsebundle also craps out just by mere Finder access, or by opening documents on there with other apps.

Question to the group: When talking about accessing files and the subsequent failure, how are those files accessed? Which apps? Finder? Read only, or also write?

One thing noteworthy: I experienced such issues before under Mojave _only_ for volumes that existed on an external SD cards. (On a 2014 iMac). Back then I thought my built-in SD card reader might have become flaky, but now with these errors under Big Sur, it looks more a software issue has already existed back then. Hmm.

Long story short, unencrypt your data before upgrading.

Upgrading an encrypted system has lots of potential for corruption, especially if the drive is marginal to begin with.

You should be backing up your data prior to upgrading in any case.

Once upgraded, you'll have less sparse bundle issues.

I've been having the same issue, where the files 'disappear' about once every 2-3 days. No problems with earlier versions / upgrades to Mac OS prior to 11.3. I re-created a new .sparsebundle under Big Sur, same issue. Unmounting then remounting the drive brings the files 'back', but it's incredibly disruptive to keep having to do this.

I can now confirm that the sparsebundle becomes inaccessible / unusable even if no files are read or written while it works; no app accessing the mounted volume. So it just fails by itself (or some other unknown background process issue).

I had my bundle mounted, all was well, left my iMac on over the night, and in the morning the problem had already occured.

@OldToad a standard advice, but no, the issue persists also in safe mode. By the way, safe mode in Big Sur is slow as molasses and borderline unusable, including the attempts to test things. F.e., clicking on a file/folder in column view takes about 8-10 seconds until anything is shown in the preview window or as file list in the folder; this is a on a 4Ghz i7 iMac.

New findings:

(1) newly created, mac-os-extended-formatted sparsebundle (mounted) just disappear all of a sudden - poof!

(2) AFPS-formatted sparsebundle (mounted) shows the mentioned issues, but sometimes it is just the Finder window that stops working. Opening a new Finder tab/window allows access. In a failing window, I also get funny stats like "-5 items" in the window status bar on the bottom.

Continued:

Mounted sparsebundles (mac OS extended) keep disappearing about 1-5 times a day, APFS-formatted ones become inaccessible.

Excluding these volumes from Spotlight does not help.

Disabled finder access (Accessibility) for a bunch of apps to test if they mess with the mounting, to no avail.

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.

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).

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.

Addendum to addendum to.... :

4 - FOUR - hours ago, the Mac Mini M1 was shut down (no AC either). It has now been started, and this time - shortly after startup, I again started the verify process. Now there us traffic on the network connection and after some minutes preparation network traffic is around 2-5 MByte/sec (network is heavily stressed by reading and creating a copy of the same sparsebundle on a Windows 10 machine).

The crux is, that this is nowhere near, what my previously produced video shows.

There may have been a bug involved, but not even an error message was presented. The positive view is, that verification may not have worked at all. Without any warning or error message. No success message either, but… if a user does this for the first time, how is (s)he to know, that one SHOULD be coming?

That’s probably, what is possible when another machine positively hieves around 100-120 Mbyte/sec out on the same network.

Let’s see, how long it takes to crunch through the task.

After around 10 minutes (plus?) - 600 seconds - all network read traffic has ceased (Time Machine backup is not active for this test). This looks suspiciously similar to the time frame involved, when a sparsebundle is copied into my machine. After 10 minutes, access is denied. I get a message, when the copy is done manually by me at the keyboard. It's time bound, not performance bound, it seems.

No error message. No success message. Up to now.

CPU System is around a couple of percent. User the same. Available: Around 96%. Not dramatic, if you acknowledge, that this note is written, while the - ahem - verification procedure is going on.

I’ll let the machine trundle along for a couple of hours, without me at the helm. If no success message is produced, sparsebundles are buggy. Time Machine also affected.

If no success message is received in a couple of hours, I’ll try a new verification operation.

Care to guess, whether that one will last one second, around 10 minutes or something else (preferably much longer or comparable to a quarter size backupbundle verification - performed on another machine - at least in time, since the same network, NAS etc. is involved, and the M1 does not speed this up in any way or form)?

Smile.

This is still happening to me now on 11.4. I had hopes that that 'minor' upgrade would fix Apple's bungling of this. The only difference: now sometimes the volume will simply disappear completely, unmounting itself, out from under processes that have their current directory on the mounted sparsebundle, and leaving lsof saying - rightly - that there is no such volume. Here is one example:

COMMAND   PID USER   FD     TYPE             DEVICE SIZE/OFF                NODE NAME
node    74278  xxx  cwd                                                          cwd|rtd info error: No such file or directory

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.