Issues with sparsebundle after 11.3

Try this simplistic fix: boot into Safe Mode according to Start up your Mac in safe mode - Apple Support and test to see if the problem persists. Reboot normally and test again.

NOTE: Safe Mode boot can take up to nearly twice as long as a normal boot as it's doing the following; 

• Verifies your startup disk and attempts to repair directory issues, if needed

• Loads only required kernel extensions (prevents 3rd party kernel/extensions from loading)

• Prevents Startup Items and Login Items from opening automatically

• Disables user-installed fonts 

• Deletes font caches, kernel cache, and other system cache files

This is an Apple Customer Forum. There are Apple employees on this forum but only as moderators and curators. You need to get this information to the right people at Apple.

You should file feedback and a bug report to Apple. Run through your testing, take detailed notes and document it all. Include as much detail as possible. Be sure to mention the specific NAS you have, the disk format of the NAS and version information, etc. They need to be able to reproduce the problem before they can fix it. I would suggest using smaller sparse image files for testing.

Developer Feedback Assistant

In Safari type in applefeedback:// on the location / search bar

or

https://feedbackassistant.apple.com

or if you have a (free or paid ) Developer Account

https://developer.apple.com/bug-reporting/

I have now tested a bit further, and I have found no way to get sparseimage to work, when it is to be mounted from a NAS SMB share. But...

If you create the exact same encrypted sparseimage with exact the same content as a MacOS (journaled) drive (HPFS), the problem does not exist. I haven't tested sparsebundle, since I'm not using that, but hope this can be of help/inspiration to sparsebundle users affected by sudden "APFS instability" .

The problem is quite clearly located in Big Sur sparseimage/sparsebundle handling, where APFS is used (I have a suspicion, what could be the cause, alas... it's not my task to do the work Apple hasn't done).

I'm enrolling my windows 10 gear for future use on that front, since Bitlocked disk images have worked and mounted trouble free without any hickups for years and years and years and... reliably! Fiddling around with the still somewhat flakey APFS file system based storage is to insecure for my taste. Who knows, the HPFS support may also vanish without warning at some time. Whether intended or caused by a bug.

Regards

P.S. An APFS formatted sparseimage, that mounts without any problems from a locally connected Thunderbolt SSD, exhibits the following behaviour (if password is located in keychain, otherwise password must be entered immediately, when mounted from an SMB NAS share):

• The "image" is checked for a loooong time:

• When completed, the following error message is shown:

Stating that: No archives can be activated.

I will stop using APFS for disk images in general, and - of course - any Apple formats on all external disks (especially when encrypted). Who'knows, what new surprises the APFS format "work (still) in progress" may turn up in form of spanners for existing and currently working functionality ;-)

I have a similar problem with sparseimage files on my Intel and M1 Big Sur machinery.

I have used sparseimage files for years; placed on my NAS as encrypted APFS (earlier HPFS+) files, that grow as required. Typically for encrypted backup of personal data. I discovered a problem opening existing sparseimage files recently, and got the message, that there were no archive systems present, when mount was attempted.

I decided to try from afresh (it would not involve any data loss, but serve as a much needed file shrinking process). I did the following:

1. Created an encrypted 128GB sparseimage file with APFS GUI system on an external Thunderbolt SSD connected to my Mac mini M1 (10 Gbit) system. That process is the fastest for initial content creation and "fill of initial data", and has worked for years and years. No problem either on all systems up to and including Big Sur 11.something.
2. Checked encryption status. Verified status and image validity.
3. Copied the file to a subdirectory on my NAS share. Worked.

So far so good.

Today, I wanted to sync current content into the sparseimage, and... and... no dice. After some checking, I got the message:  No archive systems, that could be activated. Hmm... just as when I decided to create the sparseimage some days ago.

Then I decided to look a bit deeper:

1. When I try to copy the file from the NAS subdirectory, I get the message, that I’m not allowed to access the file. Hogwash!
2. Renaming the file from inside Big Sur is not possible either (the file is deemed “in use” and access is not allowed). Also Hogwash!
3. Info shows, that I have read/write access to the share, the subdirectory and the individual sparse image file. True!
4. When I rename the same file from filename.sparseimage to filename.sparseimage.dmg (from “elsewhere” outside the Apple sphere of sudden disasters ;-), there is no problem copying the file to - for instance - the internal or an external thunderbolt SSD. Read access is no problem. Write access on target is no problem. But copying 25.4 GB takes more than a few seconds ;-)
5. I can now rename the file back to filename.sparseimage on my SSD. No problem. Access rights are shown as Read & Write. Here tested on an external APFS Thunderbolt SSD connected to Mac mini M1 (10GBit ethernet version).
6. The identical sparseimage copy can now be opened locally without any problems.
7. Content is fully valid, as expected. It is “fully operational”.
8. Unmount and Re-mounting is no problem either.
9. After unmounting the sparseimage, it can be copied back to the NAS share (still holding the identical file as filename.sparseimage.dmg and therefore no conflict can arise).
10. A few minutes later, the file has been copied to NAS without any hickups.
11. When I again try to open/mount the working and fully valid filename.sparseimage file just transferred to NAS, it is no longer possible.
12. When I try accessing the same sparseimagefile for the first time from an Intel based MacBook Pro 13 - also with Big Sur 11.5.1), I am requested to enter the key for the encrypted file. It is accepted, but after some time checking system and whatnot, the mount is rejected, due to no archive images present. This is clearly not the case. Pure hogwash.

The sparseimage is both legal and valid, but mounting the filename from a subdirectory in a NAS SMB share with full access rights is no longer possible, as was normal for years and years. It's the identical file, to the one present locally and copied to NAS, and it is legal, when copied back to local storage and mounted without any ado.

Nothing has changed, except the file is now placed in a subdirectory in a NAS SMB share. Just as it has been normal use case for years. My dmg-files placed in the same subdirectory on my NAS SMB share - also encrypted - and they are "fully operational", as expected. They take a lot more time to mount, than they used to, but... they mount. Only the sparseimage files can no longer be mounted, when placed in a NAS share.

The problem exists in both Intel and M1 versions of Big Sur. The problem is fairly new, and present in 11.5.1, 11.5 and also 11.4 - maybe even earlier; I’m not sure, when the problem turned up in Big Sur. You may be right, that the problem was a "miscarriage" delivered by Apple in Big Sur 11.3.

I have now made a quick and dirty check on a sparsebundle "system" - also 128GB of size, both 128 and 256 bit encryption, APFS and all that jazz. Created on an external SSD on my Mac mini M1 system, and copied to my NAS. Call it test.sparsebundle. Copy succeeded.

When I try to open test.sparsebundle from my Intel based MacBook Pro 13, just to avoid any "spill over" from my M1 system, it displays the exact same behaviour as sparseimage. Not possible to mount and access content in test.sparsebundle on my NAS SMB share. The same is also the problem on my M1 system.

It's clearly a problem in Big Sur. A recently introduced problem. One more example of Apple "code rot" proliferating into all systems the later years.

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 experiencing this too, roughly once a day. I've been using the mechanism described https://coderwall.com/p/mgi8ja/case-sensitive-git-in-mac-os-x-like-a-pro and https://stackoverflow.com/questions/8904327/case-sensitivity-in-git/12085233#12085233 for years without problem. The sparsebundles live in my ~/Documents folder. They are unencrypted but the volume that ~/Documents lives on is encrypted. This worked flawlessly since 2016 until 11.3. Now the volume will suddenly go 'read-only' and the contents seem to disappear though the volume stays mounted. I work around it so far by 1) using `lsof /Volumes/CM` (where my CM.sparsebundle gets mounted) to find what processes are still accessing the volume, stopping/killing them. 2) `sudo lsof /Volumes/CM` will always show at least one `mds` process still active on the volume so; 3) I just end up force ejecting the volume. system.log shows a flurry of mds processes being automatically killed at about the same time the volume goes 'read only'. My current suspicion is that SpotLight indexing is causing a problem; so I excluded that by adding /Volumes/CM to my work MBPs SpotLight Privacy exclusions. Will see if that helps at all. On my personal Air this has occurred only once so far but that gets exercised less than the work MBP. And yes, I have run Disk Utility on the sparsebundle volume as well as the underlying physical disk (from Recovery Mode) - no problems found by fsck in those.

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

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

Another question to all: Which format do your failing sparsebundles have? AFPS?

If everybody who is having problems deals with AFPS-formatted bundles, maybe we can avert the bug by using good ole "Mac OS extended". Might be worth a try.

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.