Help “____” is already in use by “____” on “mac-pro.local”.

<Updated version to clarify a few points>

How do you know the library is corrupted? What circumstances led to it? Was the drive disconnected? Was the library on a shared network drive or a NAS? Was the library copied to another machine while FCP on the first machine had it open? Was the library being synced by Dropbox? Any of those cases can damage the library.

The specific error you posted is intended for cases where the FCP library is on a network share (e.g, NAS) and two FCP users try to use that library at the same time. FCP disallows that due to data integrity risks and the 2nd person gets the error. Here's an example of the complete syntax: 'The document "6.25.2024 ASCG Trails Dog Park Golf" could not be opened. Permission denied "6.25.2024 ASCG Trails Dog Park Golf" is already in use by "charlotteisimac" on "charlotteiss-imac.local"'.

Unlike Windows, Unix-derived operating systems do not typically have "mandatory" file locking but "advisory" locking. In that scheme each app must manage hidden lock files on disk to signal other cooperating apps that a file or folder is locked. There is software code in the FCP FFFileLock class which manages the "advisory" locks, and attempts to clean up various anomalous scenarios. That evidently is not working correctly in this case.

Only FCP knows those lock files are present, so a Finder copy or a Dropbox sync of an in-use library can read the library while it is being updated by FCP. That can result in an inconsistent copy of the library, although it will not normally damage the original copy. If you copy libraries back and forth between machines, each time it is copied without shutting down FCP, the destination library could be damaged. Then if FCP on the 2nd machine has that library open and it's copied back to the 1st machine, the damage can get worse. One damage scenario is if a certain "atomic" sequence is required such as writing to lock files then updating various SQL tables in the library. If a Finder copy comes along during that, it could grab a copy of the library that is partially updated with respect to the lock files.

The lock files are hidden files in the library root. You can see them by using Finder to right-click on the library and picking "Show package contents", then doing SHIFT+CMD+. (Shift key, Command key and period key) at the same time. The filenames are .lock-info, .lock, and .lock-dir. Make sure FCP is not running during these tasks.

In some cases those lock files can be deleted, FCP launched and the software code in FCP will recreate the lock files as required. In other cases this will not work and the error message will be printed, only with "(null)" as the "In use by" and "on" names.

Do not try anything like that without first making a file-level copy of the entire library.

If deleting the lock files doesn't work, that implies some library info is out of sync with the lock files, and that case (whatever it is) was not envisioned by the FFFileLock methods which handle locking.

Your best bet is evaluating the FCP auto-backups for that library, which by default are in /Movies/Final Cut Backups.localized. There should be several backups of that library. First make a safety copy of all those by copying them to another drive. Then you can double-click on each one to try and launch FCP using that library. Going by the date and time in the library filename, try successive ones and see how close to the failure point you can reach with a working library.

If you were working with the same library on two different machines, each machine will have its own series of FCP auto-backups in that same folder. Safeguard both groups of those backups on another drive, in case working with the original backups somehow damages them.

How do you know the library is corrupted? What circumstances led to it? Was the drive disconnected? Was the library on a shared network drive or a NAS? Was the library copied to another machine while FCP on the first machine had it open? Was the library being synced by Dropbox? Any of those cases can damage the library.

The specific error you posted is intended for cases where the FCP library is on a network share (e.g, NAS) and two FCP users try to use that library at the same time. FCP disallows that due to data integrity risks and the 2nd person gets the error. Here's an example of the complete syntax: 'The document "6.25.2024 ASCG Trails Dog Park Golf" could not be opened. Permission denied "6.25.2024 ASCG Trails Dog Park Golf" is already in use by "charlotteisimac" on "charlotteiss-imac.local"'.

Unlike Windows, Unix-derived operating systems do not typically have "mandatory" file locking but "advisory" locking. In that scheme each app must manage hidden lock files on disk to signal other cooperating apps that a file or folder is locked. There is software code in the FCP FFFileLock class which manages the "advisory" locks, and attempts to clean up various anomalous scenarios. That evidently is not working correctly in this case.

Only FCP knows those lock files are present, so a Finder copy or a Dropbox sync of an in-use library can read the library while it is being updated by FCP. That can result in an inconsistent copy of the library, although it will not normally damage the original copy. If you copy libraries back and forth between machines, each time it is copied without shutting down FCP it could be damaged. Then as the library ping-pongs back and forth the damage can get worse. One damage scenario is if a certain "atomic" sequence is required such as writing to lock files then updating various SQL tables in the library. If a Finder copy comes along during that, it could grab a copy of the library that is partially updated with respect to the lock files.

The lock files are hidden files in the library root. You can see them by using Finder to right-click on the library and picking "Show package contents", then doing SHIFT+CMD+. (Shift key, Command key and period key) at the same time. The filenames are .lock-info, .lock, and .lock-dir. Make sure FCP is not running during these tasks.

In some cases those lock files can be deleted, FCP launched and the software code in FCP will recreate the lock files as required. In other cases this will not work and the error message will be printed, only with "(null)" as the "In use by" and "on" names.

Do not try anything like that without first making a file-level copy of the entire library.

If deleting the lock files doesn't work, that implies some library info is out of sync with the lock files, and that case (whatever it is) was not envisioned by the FFFileLock methods which handle locking.

Your best bet is evaluating the FCP auto-backups for that library, which by default are in /Movies/Final Cut Backups.localized. There should be several backups of that library. First make a safety copy of all those by copying them to another drive. Then you can double-click on each one to try and launch FCP using that library. Going by the date and time in the library filename, try successive ones and see how close to the failure point you can reach with a working library.

If you were working with the same library on two different machines, each machine will have its own series of FCP auto-backups in that same folder. Safeguard both groups of those backups on another drive, in case working with the original backups somehow damages them.

What is Waldorf 24? An FCP library?

what Mac and OS is this? Try booting into safe mode.