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
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.
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
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.