![Sharepoint excel locked for editing Sharepoint excel locked for editing](/uploads/1/2/5/4/125499297/398328961.png)
We are using Excel 2010 and sometimes users are working from a network share. When a user on the network opens the file in Excel, the file is locked for editing - this is the expected behavior. When another user tries to open the file, Excel gives the message [filename] is locked for editing by 'John Doe'.
I have a spreadsheet (.xlsx) file that, when I open it on my MBP running Excel 2011 14.3.6, I get a pop-up telling me the file is locked and can only be opened in read-only mode. 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.
I've triple-checked permissions on the file and it's definitely editable by me. I've also verified in Get Info - General that it's not locked. The file is located on a USB flash drive. I created a copy of this file on the local drive (/Users/aj) and it will open fine without the warning. Other Excel files saved on the USB flash drive open without this warning. A copy of this file on the USB drive still has the warning.
What can I do to remove the warning? I use this file all the time and it's super-annoying. Whilst 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. (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 and 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:. 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:. soffice.bin – here, that's NeoOffice. filecoordinationd – for.
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.