10.6.3 Resizing Sparsebundle Disk Images

Same result:

Last login: Mon Apr 12 15:39:23 on ttys000
JPsBigiMac:~ jamespond$ chmod -w /Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.*
JPsBigiMac:~ jamespond$ ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
total 24
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 15:36 .
drwx------ 11 jamespond jamespond 330 Apr 12 11:43 ..
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 15:35 Info.bckup
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 15:35 Info.plist
drwxrwxrwx 1743 jamespond jamespond 59218 Apr 12 15:35 bands
-rwxrwxrwx 1 jamespond jamespond 532 Apr 12 15:35 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx 1 jamespond jamespond 0 Apr 12 11:41 token
JPsBigiMac:~ jamespond$ ls -lad /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 15:36 /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
JPsBigiMac:~ jamespond$ hdiutil resize -size 20g /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
JPsBigiMac:~ jamespond$
|
--------

Starting standard backup
Attempting to mount network destination using URL: afp://James%20Pond@JPsAirPortExtreme. afpovertcp.tcp.local/S.Misc1
Mounted network destination using URL: afp://James%20Pond@JPsAirPortExtreme. afpovertcp.tcp.local/S.Misc1
Resizing backup disk image from 20.0 GB to 279.0 GB
QUICKCHECK ONLY; FILESYSTEM CLEAN
Disk image /Volumes/S.Misc1-1/JPsBigiMac.sparsebundle mounted at: /Volumes/Time Machine Backups
Backing up to: /Volumes/Time Machine Backups/Backups.backupdb

That's strange, +chmod -w+ should remove write permissions from those two files, but all of yours have read, write, and execute.

Try the chmod with verbose output:
+chmod -vv -w /Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.*+

And then the ls commands again.

Note, that if the permissions are indeed changed, you won't be able to use the resize command. So you should resize first, unless you want to see the "Permission Denied" error.



Oh, a thought, do you "*Ignore ownership on this volume*" checked for your S.Misc1 volume? If checked you likely won't be able to keep TimeMachine from resizing the backup using this method.

fracai wrote:
. . .
Oh, a thought, do you "*Ignore ownership on this volume*" checked for your S.Misc1 volume? If checked you likely won't be able to keep TimeMachine from resizing the backup using this method.

I did. Connected directly, un-checked it, reconnected via Airport, then retried, same results:

JPsBigiMac:~ jamespond$ hdiutil resize -size 20g /Volumes/S.Misc1/JPsBigiMac.sparsebundle
JPsBigiMac:~ jamespond$ chmod -vv -w /Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.*
/Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.bckup: 0100777 [-rwxrwxrwx ] -> 0100577 [-r-xrwxrwx ]
/Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.plist: 0100777 [-rwxrwxrwx ] -> 0100577 [-r-xrwxrwx ]
JPsBigiMac:~ jamespond$ s -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
-bash: s: command not found
JPsBigiMac:~ jamespond$ ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
total 24
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 18:55 .
drwx------ 12 jamespond jamespond 364 Apr 12 18:49 ..
-rwxrwxrwx 1 jamespond jamespond 498 Apr 12 18:55 Info.bckup
-rwxrwxrwx 1 jamespond jamespond 498 Apr 12 18:55 Info.plist
drwxrwxrwx 1742 jamespond jamespond 59184 Apr 12 18:55 bands
-rwxrwxrwx 1 jamespond jamespond 532 Apr 12 16:24 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx 1 jamespond jamespond 0 Apr 12 11:41 token
JPsBigiMac:~ jamespond$ ls -lad /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 18:55 /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
JPsBigiMac:~ jamespond$
|
--------

Starting standard backup
Attempting to mount network destination using URL: afp://James%20Pond@JPsAirPortExtreme. afpovertcp.tcp.local/S.Misc1
Mounted network destination using URL: afp://James%20Pond@JPsAirPortExtreme. afpovertcp.tcp.local/S.Misc1
Resizing backup disk image from 20.0 GB to 279.0 GB
QUICKCHECK ONLY; FILESYSTEM CLEAN
Disk image /Volumes/S.Misc1-1/JPsBigiMac.sparsebundle mounted at: /Volumes/Time Machine Backups
Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
Backup canceled.

I suspect that permissions are being ignored when the drive is connected to the Airport. I don't have such a setup so I can't check, but the fact that chmod shows missing write permissions and then ls shows read / write / execute for everyone seems to indicate they aren't sticking. You could confirm this by performing the chmod and ls while directly connected and then ls again while connected over Airport. I suspect you'll find the correct permissions when directly connected and global read / write / execute while over Airport.

If Airport disks always ignore permissions (?) my solution won't work for you. I wonder if you could "chain" sparsebundles by placing the TM image inside another which TimeMachine might not try to resize. Certainly less than optimal, but it might work.

I also saw a reference today that MacOS X Server includes an option to limit the size of client backups, but I'm having trouble finding that thread again. It may be possible that the mechanism used by Server is also available to Standard.

Also, my Verify and Repair completed with no problems [1]. Several backups have also completed with each printing the attempt and failure to resize the sparsebundle. I'll try downsizing the image to its minimum and see how another backup works out.

[1] If there's one thing that "stinks" about TimeMachine it's DiskUtility and the time to verifying all the hard links.

Message was edited by: fracai ("stinks")

fracai wrote:
I suspect that permissions are being ignored when the drive is connected to the Airport. I don't have such a setup so I can't check, but the fact that chmod shows missing write permissions and then ls shows read / write / execute for everyone seems to indicate they aren't sticking. You could confirm this by performing the chmod and ls while directly connected

*Directly attached:*

If I do, it says: permission denied.

If I do with sudo, it says: no such file or directory.

Then re-enabled ownership, JPsBigiMac:~ jamespond$ chmod -vv -w /Volumes/S.Misc1/JPsBigiMac.sparsebundle/Info.* runs, but no verbose mode messages (?)

JPsBigiMac:~ jamespond$ ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle/
total 24
drwx------@ 7 jamespond jamespond 238 Apr 12 18:56 .
drwxrwxr-x 10 jamespond jamespond 408 Apr 12 18:49 ..
-r-xrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.bckup
-r-xrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.plist
drwxr-xr-x 1743 jamespond jamespond 59262 Apr 12 18:56 bands
-rw-r--r-- 1 jamespond jamespond 532 Apr 12 18:56 com.apple.TimeMachine.MachineID.plist
-rwx------ 1 jamespond jamespond 0 Apr 12 11:41 token

*Back to Airport (ownership still enabled)*

JPsBigiMac:~ jamespond$ ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle
total 24
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 18:56 .
drwx------ 12 jamespond jamespond 364 Apr 12 18:49 ..
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.bckup
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.plist
drwxrwxrwx 1743 jamespond jamespond 59218 Apr 12 18:56 bands
-rwxrwxrwx 1 jamespond jamespond 532 Apr 12 18:56 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx 1 jamespond jamespond 0 Apr 12 11:41 token

*Connected directly, disabled ownership, back to Airport*

JPsBigiMac:~ jamespond$ ls -la /Volumes/S.Misc1/JPsBigiMac.sparsebundle
total 24
drwxrwxrwx@ 7 jamespond jamespond 264 Apr 12 18:56 .
drwx------ 12 jamespond jamespond 364 Apr 12 18:49 ..
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.bckup
-rwxrwxrwx 1 jamespond jamespond 499 Apr 12 18:56 Info.plist
drwxrwxrwx 1743 jamespond jamespond 59218 Apr 12 18:56 bands
-rwxrwxrwx 1 jamespond jamespond 532 Apr 12 18:56 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx 1 jamespond jamespond 0 Apr 12 11:41 token

If Airport disks always ignore permissions (?) my solution won't work for you. I wonder if you could "chain" sparsebundles by placing the TM image inside another which TimeMachine might not try to resize. Certainly less than optimal, but it might work.

I can't imagine that Time Machine would find it there.

I also saw a reference today that MacOS X Server includes an option to limit the size of client backups, but I'm having trouble finding that thread again. It may be possible that the mechanism used by Server is also available to Standard.

If you're referring to the +*defaults write /Library/Preferences/com.apple.TimeMachine MaxSize nnn+* command, it doesn't work, either. (I'm not sure it ever did -- it may have during beta testing.)

I'm beginning to think we're out of luck, especially since the most need is on a Time Capsule . . .

fracai wrote:
Also, my Verify and Repair completed with no problems [1]. Several backups have also completed with each printing the attempt and failure to resize the sparsebundle. I'll try downsizing the image to its minimum and see how another backup works out.

What are you backing-up to?

[1] If there's one thing that "stinks" about TimeMachine it's DiskUtility and the time to verifying all the hard links.

Considering that TM backups are about 99.9% hard links . . .

I think chmod didn't output any verbose info because the permissions were already set as requested. Perhaps try it again as +chmod -vv 444+ ( read only for owner, group, and others); that's what my Info files are anyway.

I think you're right though. It's looking more and more like Airport disk sharing ignores permissions regardless of your settings. I don't know if there's a way around that.

I'm backing up two machines, an iMac and a MacBook, to a Drobo, connected to the iMac. Both backup to sparseimages that I created. The Drobo is shared to the MacBook over AFP.
I've resized the sparseimage down to its minimum, added a few files to the backup list, and am watching that backup delete old backups to make room. So far it looks good.

Unfortunately, it's looking like directly attached drives can use the Info.plist modification to restore restricted sparseimage backups. Airport users may have to wait for an Apple sanctioned solution. Have you filed a feature request?

fracai wrote:
. . .
Unfortunately, it's looking like directly attached drives can use the Info.plist modification to restore restricted sparseimage backups.

That's not going to help most users who back up to directly-attached drives, since their backups aren't in sparse bundles anyway. (And if they are, you have to manually mount it to use the "Star Wars" interface.)

Plus, of course, it's much easier to just partition the drive!

Mumble, grumble.

Thanks anyhow.

Airport users may have to wait for an Apple sanctioned solution. Have you filed a feature request?

Yup. And I'm holding my breath . . .

That's not going to help most users who back up to directly-attached drives, since their backups aren't in sparse bundles anyway. (And if they are, you have to manually mount it to use the "Star Wars" interface.)

More reasons to hope for an official method.

P.S. After TM deleted two backups it is proceeding with the current run. It's looking like this will be an acceptable solution for some segment of users, however unsatisfactory that may be.

Apple! *shakes fist*

fracai wrote:
. . .
P.S. After TM deleted two backups it is proceeding with the current run. It's looking like this will be an acceptable solution for some segment of users, however unsatisfactory that may be.

Apple! *shakes fist*

Ditto. And it's even worse for novice users with Time Capsues. See this terrible workaround for a TC's internal HD (which can't be partitioned): Item #Q3 in the Using TIME MACHINE with a TIME CAPSULE *User Tip.*

Here's the reference regarding the ability to limit TM backup space.
http://groups.google.com/group/backmyfruitup/msg/4c668766f0856662

The documentation does indeed reference these settings, so it's possible that the same mechanism is available in the standard OS X install. If it's not, it should be.

10.5 page 226
10.6 page 241

fracai wrote:

The documentation does indeed reference these settings, so it's possible that the same mechanism is available in the standard OS X install. If it's not, it should be.

No, it's not. 😟

None of that management stuff is in the standard install.

Time Machine in a standard install is managed +*by the Mac being backed-up,+* via TM Preferences.

OSX Server manages it +*from the server.+*

same here, the sparsebundle got resized automatically everytime TM starts a backup 😟

would greatly appreciate if anyone finds a solution to this

How 'bout another attempt?

The chmod trick has been working fine for my laptop for some time now for me, so I tried applying it to my desktop machine. There it's not working. So I tried something new, I "Locked" the Info.plist and Info.bckup files. This can be done most easily using the SetFile tool provided by the Apple Developer Tools (/Developer/usr/bin/SetFile or /usr/bin/SetFile). With the locked file, I'm again seeing failed attempts to resize the bundle. As with chmod this isn't an ideal solution, but it may be acceptable for some users.

+SetFile -a L sparsebundle/Info.*+

Note: If the Info files are already marked un-writeable, the SetFile command will fail. Likewise, if you have locked the files, chmod will fail. Both can be worked around by using sudo.