.lck files not automatically deleting

Do the lock files actually still exist?

If you're discovering them because FM is complaining on open, then yes they effectively still exist (although possibly only in server FS cache).

But if you're merely seeing them in a file browser, they may or may not be there. Doing a refresh may or may not clear up matters,

Browser currency is a fundamental, and probably intractable, problem in computer science. Many OS'es don't even attempt to keep track of multiple local and remote browsers that presently have a dir open, much less asynchronously force-refresh them when the dir contents change. Windows tries to, with an assortment of performance, nuisance and failure modes.

I blame Bill Gates.

Reboot the server .

We have the same issue, but ours is a bit more sporadic. When I open FM files on our server, and then save and close the file, it sometimes remains locked. The next day, I can be the one who attempts to open the file, and I see a message that says I am the one who has the file open. I cannot be 100% certain without placing a camera on my shoulder, but I am very confident that I *always* close the file in FrameMaker prior to closing FrameMaker.

I've seen it happen with a Vista machine in our operation too - I had just put it down to not closing the files the operator was working on first before closing FM. Their normal habit was just to close the application & say yes to the save prompt, but that seems to have left .lck and .auto files on the server. Taking their time to save & close each .fm seems to have fixed it.

I haven't run into this, but the first thing I'd check is the network / server permissions.

I suspect the local system, or the owner of the local copy of Frame, or the local user, doesn't have permission to delete system files on the server.

Related to this, you may want to confirm that your copies of Frame have preferences set to match whatever OS is running on the server, not the local machine.