Expanding Encrypted Disks/Volumes

I have a MAC Pro Retina. I have a 128GB SSD inside. I have a carved out a 4.7GB volume (SuperDisk) in this ssd drive (MACmac), and have an encrypted sparse image in/over this volume. This little encrypted volume is nearly full.
I need to expand the 4.7GB volume (SuperDisk) to double it's size. I used Disk Utility to reduce the size of the boot volume by 5GB. So I have 115GB + free space and then the empty space I just created.
How to do I use this free space to expand my 4.7GB volume and encrypted sparse image?

Similar Messages

Unable to create an encrypted disk image in Lion

disk utility gives the error Unable to create "Volume.dmg." (error - 60008) when creating an encrypted disk image. I am using the following steps:
    1.    Open disk utility
    2.    Select the disk (internal or external) to create the image on
    3.    Select File>New>Blank Disk Image…
    4.    Save As: 'Volume'
    5.    Name: Volume
    6.    Size: 50GB
    7.    Format: Mac OS Extended (Journaled)
    8.    Encryption: 128-bit AES encryption
    9.    Image Format: read/write disk image
    10.    Click the Create button
    11.    Password dialog appears
    12.    When I enter a password the dialog closes after entering only a few characters i.e. before I've finished typing, and the following error message displays:
Unable to create "Volume.dmg." (error - 60008)
I have previously, successfully, created encrypted disk images in Snow Leopard, and I don't know why I can't in Lion
Does anyone have any ideas?

Thanks for this Thomas.
I've tried naming the image differently, but still received the error, I did however try different permutations for the password.
The error seems to happen if I use a purely numerical password string and occurs on input of the 10th numerical character, if I start with numerical character but use an alpha before the 9th number I can continue and create a password, and I can create a password if I start with an alpha and switch to numerals after the first alpha character, purely alphabetical passwords are fine too.
It seems that Lion doesn't like purely numerical passwords greater than 9 characters, whereas Snow Leopard wasn't so fussy. Seems it's a bit of a bug.
Thanks for your help

Creating an Encrypted Disk Image on an External (USB) Drive

I have an external 600 GB drive (2x 300 GB SATA 3.5" disks in a Thecus N2050 RAID0 external enclosure connected to iMac by USB2) onto which I would like to backup a large amount of data (500 GB).
I store this external drive away from my home (in the office) and since I cannot guarantee physically locking away the drive I would like to logically lock the drive by placing all the backup data into an encrypted disk image created on that volume.
I have tried creating an encrypted disk image on my USB volume in Disk Utility (Apple's instructions here) but I experience a number of issues not documented in the Apple article:
1) I am not presented with a drop-down option for the size of the disk image.
2) When I go ahead and try to creat the image I am told that the creation was impossible "file or folder does not exist".
Is it possible to create disk images on USB volumes (I cannot create such a large disk image on my iMac HDD as I do not have sufficient space).
thanks in advance
Raf

I realised that in Disk Utility you must not have any of your mounted drives highlighted in the left hand pane.

Corrupted files within encrypted disk images

Greetings Apple Hivemind:
I've run across a repeatable problem when using encrypted disk images from Disk Utility. Essentially, I'll create an image using settings like are shown below:
The disk image is then used for storing data. In my case, this is usually data for Adobe Lightroom.
At first, this worked very well, and I housed the disk images on my household NAS, connecting via samba (smb) to it on my Mac. Over time, however, something odd started happening: Files on those encrypted images began getting corrupted whenever I tried writing new data to them.
My first incident was where Lightroom informed me that the catalog it was trying to open was corrupted. I tried to create a new one on the same encrypted volume, and it too was instantly flagged as corrupted. I opened the individual image files on the volume with no problem, so I wasn't thinking that the volume was the culprit. That is, until I tried dragging new image files to it manually. The new files were immediately either completely unreadable, or a mish-mash of the content of random OTHER files on the volume!
The result was that all old data seemed intact, but I could no longer write new data to the volumes without major data corruption issues. I thought that this was isolated to one volume in particular, but it soon started happening on ALL of my encrypted volumes eventually. Including those which were not, and never had been, housed on my NAS, but were on my local hard drives.
I've since "evacuated" all my data from these images, since the ones created by Disk Utility appear to be useless, and am seeking an alternative.
Is this something that anyone else has encountered when using encrypted disk images? It seems like this is something I should really open a support ticket for, but I can't say I've ever tried it, so I don't know how successful it would be to do so.

bbonn wrote:
I should add that I've tried using the "Repair" and "Verify" functions of Disk Utility on the volumes, and despite the obvious issues that exist in them, the utility doesn't find (or fix) any inconsistencies.
Are you repairing/verifying the actual disk images, or just the partition they're on? If the partition, it won't look inside them.
Drag one to Disk Utility's sidebar, select it, then use Verify or Repair. Note: the usual messages may not appear on the DU window. Click the Log icon in the toolbar or select Window > Show Log from the menubar to see them.

Indexing of encrypted disk images permanently disabled in 10.8?

In the past, I've had no trouble forcing Spotlight to index my encrypted disk image, using the command in Terminal:
sudo mdutil -i on /Volumes/Encrypted_Data
After entering that command, my encrypted disk image was indexed and searchable using Spotlight.
A couple weeks ago I updated from Lion to Mountain Lion. Today I noticed Spotlight wasn't showing any results from my encrypted disk image. So went back to Terminal and entered the above command. Instead of successfully activating indexing, Terminal gives me this message:
/Volumes/Encrypted_Data:
Indexing disabled.
Is this procedure now impossible in Mountain Lion?
Is there any way to enable indexing of this encrypted disk image? I can't get it to work.
Thanks.

I appear to have solved the problem to get Spotlight to index a disk image. My image was an encrypted disk image. I was able to get spotlight to work when it was new, but now Spotlight won't index it. Here is the solution that I found:
After double clicking and mounting disk the image, open Disk Utility, select the disk image file, then click unmount in the Toolbar. Wait until it is unmounted, then click mount again. Then go to terminal and try mdutil -sa . If it is still not enabled, try to sudo mdutil -i on option. The unmounting and remounting must be done everytime the image is opened.

Erase encrypted disk

I have a couple of external firewire hard drives and I used one for an external time machine backup and now I am using another. I am finding it very dificult to delete the entire external hard drive because there is an encrypted partition. I found out that you can't use disk utility to do that and you have to use the terminal program. Using terminal I tried diskutil corestorage delete, and then when I put the name of the external hard drive it doesn't work. Any suggestions or programs to fully delete an external hard drive and delete the encrypted partition too?

I'm having a very similar problem. I had an encrypted Time Machine backup (encrypted using FileVault2 from within Time Machine). I reinstalled Lion on my computer and migrated my data using a SuperDuper backup instead of TM. When I tried to connect my TM volume, it would not mount.
I ended up completely repartitioning the external HD that the TM volume was on and if I try to create a new TM volume that is encrypted, the volume will not mount. If I just create a normal TM volume it works fine.

Cannot burn encrypted disk w/disk utility after Yosemite upgrade

I upgraded to Yosemite and now I cannot create an encrypted disk with disk utility. I have a disk loaded with a project I recently completed with Final Cut X and I need to make an encrypted .cdr file for the purposes of making write protected copies for my client. I have always been able to do this by selecting the volume in Disk Utility, clicking New Image, and selecting DVD/CD master for the image format and then my encryption level (usually 128-bit) ALWAYS WORKS but not since upgrading to Yosemite. Now every time (after restarts, etc.) I'm getting first a dialogue box telling me it's starting to create the .cdr then quickly an error box that says: Unable to create "<disk name>.cdr" (Inappropriate ioctl for device) HELP!!! Need to get these disks burned and out to clients ASAP!!!

Are you trying to save the file to the desktop? I read elsewhere that Yosemite doesn't like that permissions wise. I was able to successfully create a .cdr by changing the file location to Documents.

Encrypted Disk Image creation slow?

I just got a new MBP with Leopard. I have created a number of encrypted disk images in the past using Tiger and a MBP and have not had any trouble. This weekend I tried a few times to create a 50 gig encrypted disk image (128 AES) on an external drive and after going through the process of setting it up and waiting for it to be created, (and watching the progress bar as it was being created), after about 45 minutes NO progress was showing on the progress bar. I ended up having to cancel the creation a few times because I thought something was going wrong. I’m not sure if there is a problem creating the disk image, or leopard is slow, or what.
Does anyone know how long, on average, it would take to create an encrypted disk image of this size using leopard? I just want to know if there is a problem doing this on my MBP. Thanks for the help.

A regular 50 GB disk image takes 50GB of space, no matter if it is full of files or empty.
A 50 GB sparse disk image only takes up the amount of space equivalent to that of its enclosed files. So if the 50GB sparse image only has 1 GB of files inside, the image won't be much bigger than 1GB.
A sparse bundle is similar to a sparse image, but instead of a single file it is a folder package with many, many enclosed files called bands. A new file added to the sparse bundle will tend to modify only a few bands. This makes incremental backups of a sparse bundle more efficient because only the changed bands need to be backed up again. Any change to a sparse or regular disk image will mean that the entire image will need to be backed up again.
If you regularly add/remove files to a disk image, and you intend to back up that disk image with Time Machine, a sparse bundle is definitely the way to go. The other types will fill up your TM volume very quickly.

Encrypted disk image creation very slow-

I just got a new MBP with Leopard. I have created a number of encrypted disk images in the past using Tiger and a MBP and have not had any trouble. This weekend I tried a few times to create a 50 gig encrypted disk image (128 AES) on an external drive and after going through the process of setting it up and waiting for it to be created, (and watching the progress bar as it was being created), after about 45 minutes NO progress was showing on the progress bar. I ended up having to cancel the creation a few times because I thought something was going wrong. I’m not sure if there is a problem creating the disk image, or leopard is slow, or what.
Does anyone know how long, on average, it would take to create an encrypted disk image of this size using leopard? I just want to know if there is a problem doing this on my MBP. Thanks for the help.

A regular 50 GB disk image takes 50GB of space, no matter if it is full of files or empty.
A 50 GB sparse disk image only takes up the amount of space equivalent to that of its enclosed files. So if the 50GB sparse image only has 1 GB of files inside, the image won't be much bigger than 1GB.
A sparse bundle is similar to a sparse image, but instead of a single file it is a folder package with many, many enclosed files called bands. A new file added to the sparse bundle will tend to modify only a few bands. This makes incremental backups of a sparse bundle more efficient because only the changed bands need to be backed up again. Any change to a sparse or regular disk image will mean that the entire image will need to be backed up again.
If you regularly add/remove files to a disk image, and you intend to back up that disk image with Time Machine, a sparse bundle is definitely the way to go. The other types will fill up your TM volume very quickly.

Encrypted disk image sometimes mounts without password

I have an encrypted sparsebundle disk image containing sensitive information. On occasion (maybe one time out of ten), I'm able to mount it without being prompted for the password.
The password for the image is not stored in my keychain. Can anyone offer advice on this issue?

I was having exactly this same problem!
I keep a small encrypted disk image storing sensitive banking information. I do NOT have the option to store passwords in Keychain checked, and I verified that the password is not being stored in Keychain.
Yet, when I double-clicked the supposedly encrypted sparsebundle disk image, it opened right up and mounted - no password required! Unbelievable, right? So I started to investigate.
I first noticed this behaviour in Mountain Lion, I'm running 10.8.4 on a 2.7 GHz 15" MBPr.
In past versions of OS X I would mount the volume to work on it by double-clicking on the disk image, enter my passowrd, and then Eject the volume either by dragging to the trash or clicking the Eject button on the Sidebar. The next time I would try to access the disk image by double-clicking it, it would again prompt for a password. All good.
What seems to be happening in ML is, using the same workflow, even though the volume is disappearing from Finder, the disk image is not actually being unmounted!
When I go to Disk Utility, the disk image is still mounted, but the volume is grayed out. When I Eject the disk image in Disk Utility, it then reverts to the expected bahaviour, and double-clicking on the disk prompts for a password.
So the workaround seems to be when finished working on the volume, go to Disk Utility and manually Eject the disk image (as opposed to just the volume it mounts) to ensure it has unmounted and is thus again encrypted. The reason for it sometimes requiring a password, sometimes not is probably because after a restart of the computer it would unmount all disks, and then be unable to re-mount it until the password is entered. But in between, unless you were aware of this behaviour anyone with access to the disk image can view its contents.
What a terrible security flaw IMO, as there is no visual indication in Finder that the disk image is still unprotected after you unmount its volume and that icon disappears! I'm surprised this hasn't gotten more attention.
Incidentally brian_c, I tried to look at your linked videos but it returns the message that the videos violated the TOS of the site...?

Encrypted Disk Image mounts without Password

I've created a new encrypted disk image so that I can store sensitive documents and did it carefully, step by step,(per instructions from www.macworld.com/2425) but after I unmounted, then remount, it doesn't ask me for a password. It just mounts as if it were a regular file. Am I suppose to unmount the volume and drag the disk image to the trash? I don't know what else to try.

The Mac uses and encrypted database of keys called the "Keychain". When you login, it opens the "login" keychain using your login password. That keychain can be used to provide passwords for applications and services, and form data for web sites. In this particular case, the password for your encrypted disk image is being stored in the keychain and automatically provided.
If another user attempted to open the disk image, the disk image mounter would first look in his keychain and then the system keychain for a key to open it with. Finding none, it would prompt the user to specify the key (password). If the user supplies the correct password, the system would put it in his keychain for safe keeping, and the user would then be able to open the image again without supplying the password.
You can remove the key from your keychain by opening up /Applications/Utilities/Keychain Access, selecting the "login" keychain, and then looking for an entry with a name that matches the .dmg file in question. Highlight it, and then press the delete key to delete it. The next time you attempt to open it, it will prompt you for a password.

Password fails in encrypted disk image

I created a 300 mb encrypted disk image using 10.4.x, about 9 months ago, now I am running 10.5.2 and everytime I try to open the image and type in the password (the correct password I have been using for years) iI get an authentification error. I know Im using the correct password, any ideas what happened here. Could the image be corupted but still want me to authenticate?
I have not tried to open the file since Dec. 17th (via last modified date) I have check all the permissions on the eternal drive where the file is stored... also ran Techtool on the drive and found no errors... I am out of ideas...

I have encountered the same problem on two protected disk image files as well. Once in January and then again a few days ago.
I first thought that the first lockout was a fluke. Now after the second image lockout I'm very vary of opening another encrypted backup. I'm losing data. Even copies of the .dmg on different drives fail to authenticate. Searching for answers I found this thread.
Is it possible that a kernel panic / forced shutdown can corrupt an encrypted file? I wonder, but my encrypted home directory (FileVault sparsebundle) is fine.
Any insights would be appreciated.
This is my log:
Last login: Sun May 11 07:35:13 on ttys000
kevin:~ kevin$ hdiutil attach -debug /Volumes/kevin/busted.dmg calling DIHLDiskImageAttach with
agent: hdiutil
drive-options:
debug: true
image-options:
verbose: false
quiet: false
main-url: /Volumes/kevin/busted.dmg
2008-05-12 18:11:17.015 hdiutil[1745:1c03] using helper tool at "/System/Library/PrivateFrameworks/DiskImages.framework/Resources/diskimages-he lper".
2008-05-12 18:11:17.040 hdiutil[1745:1c03] connectToFramework
2008-05-12 18:11:17.141 hdiutil[1745:1c03] sendOperationToHelper: about to ask proxy to start operation
status proc called: initialize
2008-05-12 18:11:17.173 diskimages-helper[1747:1603] _imageOptions: {
"enable-keychain" = 1;
2008-05-12 18:11:17.176 diskimages-helper[1747:1603] _driveOptions: {
autodiskmount = 1;
"unmount-timeout" = 0;
2008-05-12 18:11:17.178 diskimages-helper[1747:1603] DIHelperAttach: initializing framework
DILoadDriver: checking for disk image driver...DILoadDriver: DI_kextExists() returned 0x00000000 (0)...DIIsInitialized: returning NO2008-05-12 18:11:17.188 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: entry
2008-05-12 18:11:17.189 diskimages-helper[1747:1603]
file://localhost/Volumes/kevin/busted.dmg - (null) ((null), (null)). perm=0
DIIsInitialized: returning YESDIBackingStoreNewWithCFURL: entry with
file://localhost/Volumes/kevin/busted.dmg
skip-permissions-check: true
DIBackingStoreInstantiatorProbe: entry
file://localhost/Volumes/kevin/busted.dmg
skip-permissions-check: true
DIBackingStoreInstantiatorProbe: probing interface 0 CBSDBackingStore
CBSDBackingStore::newProbe score 100 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 1 CBundleBackingStore
CBundleBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 2 CRAMBackingStore
CRAMBackingStore::probe: scheme "file": not ram: or ramdisk: scheme.
CRAMBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 3 CCarbonBackingStore
CCarbonBackingStore::newProbe: setting initial rval to +100
CCarbonBackingStore::newProbe: has resource fork, +100
CCarbonBackingStore::newProbe score 200 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 4 CDevBackingStore
CDevBackingStore::newProbe: not /dev/disk or /dev/rdisk (/Volumes/kevin/busted.dmg).CDevBackingStore::newProbe score -1000 for
DIBackingStoreInstantiatorProbe: probing interface 5 CCURLBackingStore
CCURLBackingStore::probe: scheme is
file
CCURLBackingStore::probe: not recognized URL scheme.
CCURLBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 6 CVectoredBackingStore
CVectoredBackingStore::newProbe not "vectored" scheme.
CVectoredBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreNewWithCFURL: CCarbonBackingStore
DIBackingStoreNewWithCFURL: instantiator returned 0
DIBackingStoreNewWithCFURL: returning 0x00000000
2008-05-12 18:11:17.190 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: resolving file://localhost/Volumes/kevin/busted.dmg returned 0
2008-05-12 18:11:17.191 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: imageUID (
"d234881039:i8914"
) shadowUID (null)
*** testing:
0: d234881039:i9111
(null)
(null)
*** testing:
0: d234881039:i9111
(null)
(null)
*** testing:
0: d234881039:i9111
(null)
(null)
2008-05-12 18:11:17.194 diskimages-helper[1747:1603] DIHelperAttach: resolving disk image
DIIsInitialized: returning YESDIIsInitialized: returning YESDIBackingStoreNewWithCFURL: entry with
file://localhost/Volumes/kevin/busted.dmg
enable-keychain: true
image-path: /Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: entry
file://localhost/Volumes/kevin/busted.dmg
enable-keychain: true
image-path: /Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 0 CBSDBackingStore
CBSDBackingStore::newProbe score 100 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 1 CBundleBackingStore
CBundleBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 2 CRAMBackingStore
CRAMBackingStore::probe: scheme "file": not ram: or ramdisk: scheme.
CRAMBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 3 CCarbonBackingStore
CCarbonBackingStore::newProbe: setting initial rval to +100
CCarbonBackingStore::newProbe: has resource fork, +100
CCarbonBackingStore::newProbe score 200 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 4 CDevBackingStore
CDevBackingStore::newProbe: not /dev/disk or /dev/rdisk (/Volumes/kevin/busted.dmg).CDevBackingStore::newProbe score -1000 for
DIBackingStoreInstantiatorProbe: probing interface 5 CCURLBackingStore
CCURLBackingStore::probe: scheme is
file
CCURLBackingStore::probe: not recognized URL scheme.
CCURLBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreInstantiatorProbe: probing interface 6 CVectoredBackingStore
CVectoredBackingStore::newProbe not "vectored" scheme.
CVectoredBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
DIBackingStoreNewWithCFURL: CCarbonBackingStore
opening /Volumes/kevin/busted.dmg setPermission 1723
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
closing /Volumes/kevin/busted.dmg setPermission 1731
DIBackingStoreNewWithCFURL: instantiator returned 0
DIBackingStoreNewWithCFURL: returning 0x00000000
DIResolveURLToBackingStore: processing level 1 encodings.
DIFileEncodingNewWithBackingStore: entry for encoding level 1
DIFileEncodingInstantiatorProbe: entry for level 1
enable-keychain: true
image-path: /Volumes/kevin/busted.dmg
DIFileEncodingInstantiatorProbe: probing level 1 interface 0 CMacBinaryEncoding
CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
opening /Volumes/kevin/busted.dmg openDataFork 1904
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
00000000: 656e 6372 6364 7361 0000 0002 0000 0010 | encrcdsa........ |
00000010: 0000 0005 8000 0001 0000 0100 0000 005b | ...............[ |
00000020: 0000 00a0 548a 2877 86c1 4f17 877b cf66 | ....T.(w..O..{.f |
00000030: beea 6066 0000 1000 0000 0002 780e 1734 | ..`f........x..4 |
00000040: 0000 0000 0001 e000 0000 0001 0000 0001 | ................ |
00000050: 0000 0000 0000 0060 0000 0000 0000 0268 | .......`.......h |
00000060: 0000 0067 0000 0000 0000 03e8 0000 0014 | ...g............ |
00000070: d369 cd83 75e8 bb7c 72e5 020d fdd3 68a9 | .i..u..|r.....h. |
diskimages-helper: fileNameLength $0000006E
diskimages-helper: resourceForkLength $60000000
diskimages-helper: dataForkLength $00000000
diskimages-helper: commentLength $00006700
diskimages-helper: MacBinary III signature (0x00000000)
diskimages-helper: header CRC $0000FDD3
diskimages-helper: minimum decoder version $0000000D
diskimages-helper: encoder version $00000002
no MacBinary III signature - checking for MacBinary I or IIDIFileEncodingInstantiatorProbe: probing level 1 interface 1 CAppleSingleEncoding
CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
opening /Volumes/kevin/busted.dmg openDataFork 1904
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
00000000: 7263 6e65 6173 6463 0000 0002 0000 0010 | rcneasdc........ |
00000010: 0000 0005 8000 0001 0000 0100 0000 005b | ...............[ |
00000020: 0000 00a0 548a .... .... .... .... .... | ....T........... |
closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
CAppleSingleEncoding::isAppleSingleFile loadAppleSingleHeader failed with error 22
DIFileEncodingInstantiatorProbe: probing level 1 interface 2 CEncryptedEncoding
CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
opening /Volumes/kevin/busted.dmg openDataFork 1904
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
CEncryptedEncoding::copyHeaderInformation: inBackingStore->openDataFork returned 0
CEncryptedEncoding::copyHeaderInformation: inBackingStore->getDataForkLength (stub header) returned 0
CEncryptedEncoding::copyHeaderInformation: backingStore data fork length is 0x0000000278100000 (10604249088)
CEncryptedEncoding::copyHeaderInformation: reading V1 header from offset 0x00000002780FFB04 (10604247812)
CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (stub header) returned 0
CEncryptedEncoding::copyHeaderInformation: not recognized as v1 header
CEncryptedEncoding::copyHeaderInformation: reading V2 header from offset 0x0000000000000000 (0)
CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (stub header) returned 0
CEncryptedEncoding::copyHeaderInformation: reading auth-entry count from offset 0x0000000000000048 (72)
CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (auth entry count) returned 0
CEncryptedEncoding::copyHeaderInformation: reading auth table from offset 0x0000000000000048 (72)
CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (auth entry count) returned 0
closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
max-key-count: 1
blocksize: 4096
uuid: 548A2877-86C1-4F17-877B-CF66BEEA6066
version: 2
passphrase-count: 1
private-key-count: 0
CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
opening /Volumes/kevin/busted.dmg openDataFork 1904
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
opening /Volumes/kevin/busted.dmg openDataFork 1904
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
(RW lock acquired)
closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
diskimages-helper: DiskImages secure mode enabled
CEncryptedEncoding:unclockCANTHROW: trying to unlock with normal keychain
UNLOCK: cannot find passphrase in keychain search list.
UNLOCK: SessionGetInfo returned 0
UNLOCK: sessionHasGraphicAccess
UNLOCK: sessionHasTTY
UNLOCK: sessionWasInitialized
UNLOCK: using TTY to prompt for passphrase
Enter password to access "busted.dmg":
unlockCoreFromTTY: passphrase is wrong
DIFileEncodingNewWithBackingStore: returning 0x00000050
DIResolveURLToBackingStore: level 1 encoding match failed. 80.
DIResolveURLToDiskImage: resolving backing store/file encoding failed. 80.
status proc called: attach
error code: 80
status proc called: cleanup
2008-05-12 18:11:41.081 diskimages-helper[1747:1603] DIHelperAttach performOperation: returning 80
2008-05-12 18:11:41.082 diskimages-helper[1747:1603] -decrementBackgroundThreadCount: _backgroundThreadCount is now 0.
2008-05-12 18:11:41.082 diskimages-helper[1747:10b] DIHelper reportresults: reporting {
payload = {
"result-code" = 80;
2008-05-12 18:11:41.083 hdiutil[1745:1c03] reportResultsToFramework: proxy has finished operation
2008-05-12 18:11:41.084 hdiutil[1745:1c03] reportResultsToFramework: results are: {
payload = {
"result-code" = 80;
2008-05-12 18:11:41.084 hdiutil[1745:1c03] reportResultsToFramework: _threadResultsError is 80
2008-05-12 18:11:41.085 hdiutil[1745:1c03] reportResultsToFramework: disconnecting from helper.
2008-05-12 18:11:41.186 hdiutil[1745:1c03] disconnectFromHelper: removing observers
2008-05-12 18:11:41.187 hdiutil[1745:1c03] disconnectFromHelper: terminating proxy
2008-05-12 18:11:41.189 diskimages-helper[1747:10b] DIHelper: terminateHelper: entry.
2008-05-12 18:11:41.190 hdiutil[1745:1c03] disconnectFromHelper: terminated proxy
2008-05-12 18:11:41.290 diskimages-helper[1747:10b] -DIHelperAgentMaster terminateUIAgentConnection.
DIHLDiskImageAttach() returned 80
2008-05-12 18:11:41.293 diskimages-helper[1747:10b] DIHelper dealloc.
2008-05-12 18:11:41.294 diskimages-helper[1747:10b] -DIHelperAgentMaster terminateUIAgentConnection.
hdiutil: attach failed - Authentication error
kevin:~ kevin$

Can't create encrypted disk image

With Leopard, I have repeatedly followed the instructions for using Disk Utility to make an encrypted disk. All appears to go well...all fields appropriately filled, including 128 encryption. But when I hit create, either nothing happens, or I get a second Disk Utility starting window. In any case, I am not asked to create a password, and am unable to find any trace of the disk I thought I'd just created. Would welcome your thoughts.

While creating, make sure that it's saved to the desktop so you will know where it is supposed to be, at least.. Was wondering if posssibly you lost them. Look for the named disks in your home folder and in HD on chance they are there somewhere.
I know you went to Help but just making sure you are creating disks this way (below). Everything worked fine for me--
If things still don't work, turn off DU and move to the desktop "com.apple.DiskUtility.plist" in your home folder/library/preferences. A new file will be created when disk utility is turned on again. Deleting plist files don't usually don't solve problems but sometimes they can become corrupted.
Good luck
RM
1 choose File > New > Blank Disk Image.
2 Type a name for the image, and choose where you want to save it.
3 In the Volume Name field, type a name for the volume that appears when you open the disk image.
4 Choose the size of the disk image from the Size pop-up menu.
5 Be sure you choose a size that’s large enough to hold any changes and new documents you might add.
6 Choose an encryption option from the Encryption pop-up menu.
7 Use the default settings for the rest of the options:
8 Choose “Mac OS Extended (Journaled)” from the Volume Format pop-up menu.
9 Choose “Single partition - Apple Partition Map” from the Partitions pop-up menu.
10 Choose “read/write disk image” from the Format pop-up menu.
11 Click Save.
Enter a password, and click OK.
Disk Utility creates the disk image and mounts its volume on your desktop.
Copy the documents you want to protect to the volume.
If you want to erase the original documents so they can’t be recovered, drag them to the Trash and choose Finder > Secure Empty Trash.

Alias to open a file in an encrypted disk image

Deleted.

There is a quick and simple test, could someone with Lion installed be so kind as to do this:
1. Use Disk Utility (or Knox if they own the app) to create an encrypted disk image on the Desktop called Test
2. Mount the image, open TextEdit and paste a page of text into the window, then save the file in the mounted disk image
3. Paste another page of text into the TextEdit window
Open Terminal, navigate to /Volumes/Test, view the hidden files in the directory & post the results here.
All you need to do to clean up is eject the disk image then drag the .sparsebundle file to the Trash.
Cheers

Using Encrypted Disk Images

When I create an encrypted sparse bundle disk image it starts small an grows when I add files. When I create a sparse disk image it starts at the size I set and never grows. I understand all this however, what I don't understand is gaining FREE space again. When I delete a file I don't get back the free space on the mounted virtual drive but the disk image is still the same size! I know that filevault (which basically just places your home folder in an encrypted Sparse bundle image) some how recovers space, is this possible with other ENCRYPTED disk images as well?
Thanks in advance,
Macguy3000

A sparse image file can expand but it does not automatically contract as data is removed. I believe I remember reading a hint at MacOSXHints.com about how to resize a sparse image file.

Expanding Encrypted Disks/Volumes

Similar Messages

Maybe you are looking for