Shirt Pocket Discussions

Shirt Pocket Discussions (
-   General (
-   -   Lacie Won't Unmount - Applications Running (

t3rockhall 08-25-2006 05:49 PM

Lacie Won't Unmount - Applications Running
I frequently get this sort of message after I backup, although the dock shows nothing running. Is it from youcontrol running in the background? I have to restart the Mac before I can unmount the external drive (or shut down, turn off the LaCie, and then boot again.).

dnanian 08-25-2006 06:26 PM

The only way to check this for sure is to see what's accessing the drive. To do this, open Terminal and run:

sudo lsof | grep "The-Volume-Name"

Where "The-Volume-Name" is the name of your external drive. That'll give you a list of every application with a file open on the drive...

t3rockhall 08-25-2006 07:50 PM

I just do not understand why ANYTHING should be running on a drive that I do not run apps from. I start and mount the drive only to back up to it.

IF I booted from the LaCie to restore my internal HD (or, in my case, to bring it up to date) I would understand it. But this is a drive that starts cold from an OFF setting.

Mind you, it's no big deal to say "shut down" -- I just don't get it.

As for TERMINAL, I'm afraid I'll screw something up if I hit a wrong key or something. No thanks.

dnanian 08-25-2006 08:29 PM

Well, that's why I've suggested how to determine what's accessing it. Without that information, it's hard to help.

By simply copying and pasting the command I provided, pressing Return, entering your password when prompted and pressing Return, you can't do anything to your system. There's no reason to be nervous about Terminal!

t3rockhall 08-26-2006 03:55 PM

The hangup only occurs if I do an erase and backup fully -- not if I do an update. It looks a bit like it may be NAV. The iCal line is a puzzle, to be sure (because I don't run iCal at all).

sudo lsof | grep "Backup HD"
NortonAut 226 root 8u VREG 14,6 9256 41 /Volumes/Backup HD (/dev/disk1s3)
NortonAut 226 root 9r VREG 14,6 848 24 /Volumes/Backup HD (/dev/disk1s3)
NortonAut 226 root 10r VREG 14,6 1880 42826 /Volumes/Backup HD/Applications/

dnanian 08-29-2006 06:27 PM

It certainly looks like Norton -- that's not a surprise. I'd encourage you to turn Norton off.

gmachen 02-11-2008 03:51 PM

I also have a LaCie HD that will not unmount.

Even immediately after a restart, even a Safe Boot.

It is partitioned into two; I can unmount one partition, but the other one that I cannot unmount is one to which I made a bootable backup with SD!

I did the

sudo lsof | grep /Volumes/[volumeName]

... but nothing whatsoever came up:

circulation-1:~ techservicesadmin$ sudo lsof | grep /Volumes/ServerHD\ backup\ 1\ of\ 3/
circulation-1:~ techservicesadmin$

(I thought maybe it wasn't working, so as a test I launched an app from it and did the lsof again, and I did see the process.)

Also, this is Mac OS X Server 10.4.11. But it also won't unmount from a regular Mac OS X client Mac.

Any other ideas why I can't umount the drive?

dnanian 02-11-2008 03:54 PM

Try just searching on "ServerHD backup 1 of 3" (with the quotes, no /Volumes, etc).

gmachen 02-11-2008 04:42 PM


Originally Posted by dnanian (Post 17395)
Try just searching on "ServerHD backup 1 of 3" (with the quotes, no /Volumes, etc).

I did so:

sudo lsof | grep "ServerHD backup 1 of 3"

... and still no hits.

I should mention that my earlier syntax would also seem to be correct, inasmuch as if I enter:

sudo lsof | grep

... with a space character after grep, then drag & drop my volume icon from the Finder to the Terminal window, I end up with:

sudo lsof | grep /Volumes/ServerHD\ backup\ 1\ of\ 3/

But as a test, I launched an app from the offending partition, and both of our syntaxes showed it.

Memo: I wonder what this means:
- After quitting that app, I still get two references to its path, even though it's not a running process:

circulation-1:~ techservicesadmin$ sudo lsof | grep "ServerHD backup 1 of 3"
Finder 1028 techservicesadmin 13r DIR 14,20 1054 2 /Volumes/ServerHD backup 1 of 3
Finder 1028 techservicesadmin 16r DIR 14,20 1088 190786 /Volumes/ServerHD backup 1 of 3/Applications
circulation-1:~ techservicesadmin$

gmachen 02-11-2008 04:45 PM

Hold the presses! It just unmounted.

But then I mounted the two partitions again in Disk Utility, and now I'm back to the same behavior: the data-only partition will unmount, but the bootable backup won't.

Chain of events:
- I had launched SD! as root and scheduled a Smart Update for five minutes later.
- I logged-out.
- Five minutes later SD! duly came up behind the login window and did the backup. (It was doing the backup as root.)
- I logged into my regular Admin account, and then I got the bootable backup partition to unmount from the Finder.
- I was so surprised that I promptly launched Disk Utility and re-mounted the two partitions.
- Now, as before, the data partition will unmount but the bootable backup partition will not unmount, complaining that it is "in use."

Does this provide a clue to anybody?

dnanian 02-11-2008 04:58 PM

I didn't mean to imply your syntax was wrong. Rather, I wanted to make sure the volumes prefix wasn't a factor.

I don't know why the drive would not unmount if no process has files open on it other than Finder...

gmachen 02-12-2008 09:23 AM

Does anyone else have an external hard drive that won't unmount?

My posts, especially #10 above, tentatively & loosely point to possible culprits:

- Only a volume or partition that has had a SD! bootable backup done to it won't unmount.
- The problem first surfaced after a bootable backup was done by SD! running logged-in under a normal Admin account.
- The only time it would unmount was with the Finder from within a normal Admin account immediately following a bootable backup when SD! was running as root.
- But once the HD subsequently was "touched" by a non-root account (re-mounting it with Disk Utility), it again became unmountable. Even with a sudo diskutil unmount.

Could SD! be setting some flag or something else that otherwise prevents unmounting, even when lsod reveals no open file or process associated with that drive?

(My drive has two partitions; I've never encountered this problem with a single-partition drive; perhaps that's a clue.)

gmachen 02-12-2008 01:20 PM

The plot thickens!

OK, after some more experimentation, it now appears that it's not SD! per se that has to "touch" the drive before it will unmount, but *any* app launched as root has to do something to the drive before it will unmount:

- Immediately after a bootable backup by SD! launched as root, I was able to unmount the offending partition from the Finder in my regular Admin account. Had I mounted it again by any means (e.g., Disk Utility, restart), it would not have been unmountable, as before.
- I promptly launched Disk Utility as root. Even it would not unmount it. But I "touched" the drive by merely doing a Verify Disk Permissions (which I would think is a read-only operation), quit, then lo & behold, I could unmount it from the Finder in my regular Admin account.
- But one time only! If I mounted it again, even in Disk Utility launched as root, it wouldn't unmount by any means until I had "touched" it again with another Verify Disk Permissions in Disk Utility launched as root (or presumably any other app launched as root that 'touches" the drive in some way).

This would seem to be an OS thing, not so much a SD! thing.

To review:
- Only a partition containing a bootable backup made by SD! (either launched normally or as root) will not unmount. The drive had been partitioned into two volumes with Apple's Disk Utility under 10.4.11.

I've not yet tried a single-partition HD containing a bootable backup made by SD! launched as root. (I'll try one and get back to you all here.)

Edit: P.S.: I can get it to unmount by doing a Verify Disk Permissions in Disk Utility launched in a normal Admin account, but that's probably a moot point, because I think all Disk Utility does is run the routine as a shell for the command line diskutil, which probably runs as root anyway.

gmachen 02-13-2008 02:11 PM

OK, I repartitioned a drive with a normal single partition, and it still won't unmount if it contains a SD! bootable backup. So I guess that rules out some peculiarity associated with a two-partitions drive.

It occurred to me that since it was a Mac OS X Server, maybe it was being shared, and that prevented it from being unmounted, despite no open files showing with lsof. But I put the FireWire drive on another Mac with the regular client OS, and it wouldn't unmount there, either.

Now I'm really thinking that a SD! Smart Update of a boot drive may be setting some flag or something that inhibits unmounting. (Recall that I earlier stated that I did a Smart Update to my destination drive's second partition of a data-only HD - no OS on it - and it would unmount.

But then again, if so, why isn't my problem happening to everybody?

H-E-L-P! We're running three rotating backups, and my people can't be shutting down a busy file server, just to unmount a frigging FireWire drive to take off-site.

milhous 02-14-2008 03:31 PM

Yes, this is an interesting situation. Here are my environment variables of my set-up.

1. Leopard clean install and update to 10.5.2 on Mac Book Pro.
2. Backup drive is 250GB external disc in a Metal Gear Box enclosure. Nothing to do with Lacie
3. The backup drive used to be a single partition. But because the laptop is 160GB and the external disc is 250GB, I created a backup partition to mirror the size of the internal disc and ~84GB partition for scratch.
4. The volumes are named a.Backup and a.Scratch. I decided to use an "a." prefix so I remember that both volumes are located on the same physical drive.
5. Leopard-compatible SuperDuper was downloaded and registered. It was also configured to SmartUpdate and repair the disc's permissions, even though the first-run would be a backup to an empty disc. I did this so that I wouldn't have to set it up later.
6. Unfortunately, I was working on my MacBook Pro during the initial backup. But the backup completed without error. I know this isn't ideal, but I wanted to have something than nothing. I plan on quitting everything and backing up again when I leave the office.

And the output from lsof:

Omega:~ jo$ sudo lsof | grep "a.Backup"
notifyd 11 root 14r DIR 14,5 1054 2 /Volumes/a.Backup 1
mds 19 root 56u REG 14,5 16777216 9629 /Volumes/a.Backup 1/.Spotlight-V100/Store-V1/Stores/AD960B6B-069A-4A3A-8AE2-8A784B44CBD9/1.indexPostings
mds 19 root 64u REG 14,5 16777216 9629 /Volumes/a.Backup 1/.Spotlight-V100/Store-V1/Stores/AD960B6B-069A-4A3A-8AE2-8A784B44CBD9/1.indexPostings
mds 19 root 65r REG 14,5 8917822 356239 /Volumes/a.Backup 1/.Spotlight-V100/Store-V1/Stores/AD960B6B-069A-4A3A-8AE2-8A784B44CBD9/0.indexPostings

I opened up Spotlight preferences and explicitly added both volumes so that they can't be indexed.

I'll have to restart for now to unmount the volumes. Hope this helps.

milhous 02-14-2008 04:29 PM

Update: Logging out of account didn't work. Restarting was the only way to eject the discs. I'll see what happens tomorrow after I SmartUpdate overnight.

gmachen 02-14-2008 04:53 PM


Originally Posted by milhous (Post 17544)
Update: Logging out of account didn't work. Restarting was the only way to eject the discs. ...

Mine won't unmount even following a restart. (I have to unplug them immediately following the restart chime sound, before they have a chance to mount again during the startup sequence.)

My lsof list, as described in my earlier post, did not include anything whatsoever, not to mention any Spotlight attachments. Curiously, I had thought of Spotlight, but it didn't let me add my drive to its "Privacy" list - I wonder why.

milhous, are you running Leopard Mac OS X Server, or regular client Leopard?

milhous 02-14-2008 10:18 PM

Client, 10.5.2

milhous 02-15-2008 10:38 AM

I SmartUpdated overnight and when I came back to the office, SuperDuper had finished and quit. I was also able to unmount the backup drive without any problems so it appears that in my situation, the inability to unmount the drive was a first-run occurrence. Still not pretty to see, but hopefully this can still be addressed in a future update. Good luck to all of you still having problems.

dnanian 02-15-2008 01:12 PM

I hope it's clear to people that there really is nothing we can do about this in SuperDuper! -- it'd have to be fixed in Leopard.

gmachen 02-15-2008 08:50 PM


Originally Posted by dnanian (Post 17593)
I hope it's clear to people that there really is nothing we can do about this in SuperDuper! -- it'd have to be fixed in Leopard.

Have you identified exactly what is the cause of the problem?

- It occurs both in Tiger & Leopard.
- It only occurs with bootable backups made by SD!
- It does not occur with Smart Updates made by SD! of drives not containing a blessed OS.

TMay 02-15-2008 09:44 PM

While you say it occurs in Tiger, am I correct that with Tiger CLIENT you have only tried it by plugging in a backup-containing FW drive to a client Tiger machine, but with the backup on the FW drive having been made from Tiger SERVER? That's what I think you were saying in your earlier post.

Is so, then I still wonder if it isn't something peculiar to your server and its setup (but not apparent) which when backed up as you have described is causing the problem?

If you have had the problem on a Tiger client with a backup made FROM a Tiger client (a Tiger client not running as client on what we will call the potential-problem server,) then I am at a loss, and can only revert to your question, "then why isn't everybody having the problem?"

gmachen 02-15-2008 11:07 PM

Yes, TMay, in retrospect how I phrased it was misleading. It is as you said. Apologies. Indeed, at home I've made a bootable Smart Update of my laptop Tiger client, and have had no problems unmounting, although it was to an expansion bay/ATA drive, not FireWire.

Nevertheless, milhous above indicates that he could not unmount after backing up Leopard client.

But the first fellow with the problem seems not to have gotten back to us whether disabling Norton solved his problem.

gmachen 02-16-2008 03:32 PM

I guess I ought to try making a bootable backup with Carbon Copy Cloner 3 and/or Apple Disk Utility, to try narrowing-down or ruling-out whether there's something peculiar with Mac OS X Server, or with SD!, that inhibits unmounting my FireWire drive. Stay tuned.

gmachen 02-25-2008 04:22 PM

OK, I've cloned one of my FireWire drive partitions as a bootable backup via a Restore with Apple's Disk Utility, and it exhibits the same difficulties unmounting as described throughout this thread as with one done via SuperDuper!

Therefore it now appears that there's nothing peculiar to SD! that causes the problem, but rather something peculiar to a cloned Mac OS X Server boot partition. (At least with Tiger.)

Is there anyone on this forum who's backed-up Mac OS X Server who *hasn't* had difficulties unmounting it?

gmachen 03-30-2008 01:37 PM


Am I the only person in the world who makes bootable clones of Mac OS X Server?

All times are GMT -4. The time now is 10:20 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.