Whilst the first answer did not apply to the opening post, I'll use the old bugs in Microsoft Office to exemplify how a file that is read-only in an Excel window is not an open file.
@AJ. (opening poster): given the available information, multi-platform use of different versions of Excel is the likeliest cause of problems in your case. Please see below, Persistence of temporary files …
Microsoft Excel 2011 problems with POSIX-compliant use of HFS Plus by OS X
Excel 14.4.7 (141117) allows the user to include the solidus character / (slash) within the name of a file in, for example, the Save dialogue:
Simply saving then closing the workbook with that file name will cause the file to be read-only, to Excel, for as long as there's a character that Excel can not handle.
Editing the saved workbook, before initial closure, may expose additional bugs – one of which is shown at end of this answer.
Other causes of Excel treating a workbook as read-only
Use Terminal with ls(1) and lsof(8) to tell whether any lock-related file is present for the affected workbook; and to tell whether anything other than Excel has the workbook open.
Please note that lsof is executed as the superuser.
Approaches to opening/locking
Not all apps use the same approach.
Example 1: a workbook file.xlsx opened first by NeoOffice then by Microsoft Excel:
Excel responds properly to the Mac OS X native file locking of NeoOffice:
- the Excel window to the workbook is read-only
- output from lsof confirms that the workbook is not open by Excel.
Also in the screenshot above
The COMMAND column shows that two processes have the file open:
Example 2: the same workbook file.xlsx opened first by Microsoft Excel then by NeoOffice:
NeoOffice responds properly to Microsoft's approach to locking:
- the NeoOffice window to the workbook is read-only
- output from lsof confirms that the workbook is not open by NeoOffice
- output from lsof confirms that lock file is not open by Excel.
Essentially
Use lsof to discover what has the workbook open. If not filecoordinationd then it might be a third party backup or synchronisation application, or a metadata-related process … and so on.
Persistence of temporary files
A temporary file may remain in the file system longer than necessary.
In example (2) above we see ~$file.xlsx – a companion to file.xlsx – such files are normally invisible to Finder.
If an (invisible) ~$….xlsx file is present following (for example) a crash of Excel on your own Mac, then Excel should behave properly when the (visible) workbook is next opened.
In contrast: if for any reason an ~$….xlsx file persists after closure of the workbook by another installation of Excel, then Excel on your Mac may respond strangely. With reference to the opening post –
… About a minute later, Excel opens another pop-up and this time says that the file is unlocked and asks if I want to edit it …
– that symptom is very familiar to me from shared use of a workbook served by Microsoft Windows Server to Windows and OS X clients.
(In my case, accepting the prompt to edit rarely allowed edition; there reappeared the alert about read-only access, then another prompt to edit, and so on … and that behaviour would persist after all users had closed the workbook. Resolved only by manual removal, from the server, of the invisible ~$….xlsx file.)
Back to the bugs in Microsoft Office
The solidus / in an existing file name prevents Excel from opening the file (the window to the file is read-only):
That's relatively innocuous.
However, edition following the initial save may present a succession of problems. Screenshots below show AutoSave/AutoRecover failure –
– the workbook is saved and remains open (confirmed with lsof) but the behaviours are disconcerting to the end user.
