Knox Image don't eject

yannis.asp

Hello,

i have found that when i play a movie

wich is inside a Knox Image i can't eject

it afterwards i have closed every application

and quicktime pro of course.

Only if i logout i can eject it.



I tried to make a disk image using DiskUtility

to see if this is a Knox problem but it

does the same thing.



OSX 10.6.3



any ideas?

Nik

Welcome to the forums, yannis.asp! I have this problem on OS X, also. It applies to all mounted volumes, whether it is a disk image or an external drive. OS X just seems to have trouble "letting go" of processes sometimes.

jxpx777

To follow up on what Gita said, this is a problem for some disks and disk images going back to 10.5. This link might be of some help: [url]http://www.macosxhints.com/article.php?story=20080518161338583[/url]

cmyers

I just ran into this. The culprit is Knox itself. It appears to get information on any mounted volume and doesn't remove it from its open file list until Knox is shut down.



How to tell what process(es) are locking the volume from ejecting can be done from terminal.

Type "mount". This command by itself will return a list of all volumes. You're looking for the one in /Volumes that is the name of the volume you are trying to eject.



Next, do "lsof <volume>". This will return two or more numbers. Those numbers are the process ids that are doing something with the volume.



Last, do "ps -p <process id>" for each number lsof returned. That will return the details on the processes and is where you can see what the actual process is that is preventing you from ejecting. One of the ones you will find is Finder. That one is fine, it should be there. It's the other ones that are causing a problem.



Here's an example showing the steps on my machine and how I am certain that Knox is the culprit.

[code]

[/Users/cmyers]

cmyers@lain-> mount

/dev/disk0s2 on / (hfs, local, journaled)

devfs on /dev (devfs, local, nobrowse)

map -hosts on /net (autofs, nosuid, automounted, nobrowse)

map auto_home on /home (autofs, automounted, nobrowse)

afp_2MOVwB0jIDsf4Elw7k0mr3av-3.2d000006 on /Volumes/Applications (afpfs, nodev, nosuid, mounted by cmyers)

afp_2MOVwB0jIDsf4Elw7k0mr3av-6.2d000009 on /Volumes/Library (afpfs, nodev, nosuid, mounted by cmyers)

afp_2MOVwB0jIDsf4Elw7k0mr3av-1.2d00000a on /Volumes/Public (afpfs, nodev, nosuid, mounted by cmyers)



[/Users/cmyers]

cmyers@lain-> cd /Volumes/



[/Volumes]

cmyers@lain-> fuser Applications/

Applications/: 1974 2463



[/Volumes]

cmyers@lain-> ps -p 1974 -p 2463

PID TT STAT TIME COMMAND

1974 ?? S 3:16.49 /Applications/Knox.app/Contents/Knox/Knox.app/Conten

2463 ?? S 0:36.78 /System/Library/CoreServices/Finder.app/Contents/Mac

[/code]



After shutting down Knox, this is what I got:

[code]

[/Volumes]

cmyers@lain-> fuser Applications/

Applications/: 2463

[/code]



Only Finder was accessing it and now and I could happily eject the volume.



I'm guessing Knox is reading information on all volumes when it launches and then doesn't close the file descriptor that was used to get that information.

MartyS

Thanks for the research, cmyers!



We are looking into why Knox has this volume polling taking place. I'm sure it's important but this is a bit of a surprise that it's not "letting go". My hunch is that the polling has something to do with keeping any Knox vaults "checkmarked" in the Knox menu.

cmyers

May have been a bit premature as I can't reproduce that behavior on my system with anything except the Library and Applications network volumes. If I have them connected Knox will open a file descriptor in each of them for read access even though there is nothing in them. Probably keying off of the name. Not using any secure volumes yet so can't test those.



Steps to determine what's causing the lock are valid though.

MartyS

[quote name='cmyers']May have been a bit premature as I can't reproduce that behavior on my system with anything except the Library and Applications network volumes. If I have them connected Knox will open a file descriptor in each of them for read access even though there is nothing in them. Probably keying off of the name. Not using any secure volumes yet so can't test those.



Steps to determine what's causing the lock are valid though.[/QUOTE]



We appreciate the update!