When a user runs into a refusal to make changes to a file or folder, the first thing to consider is whether or not the volume is in Project Locking mode, in which case the behavior may actually be expected.
For shares in the Project Locking mode, EVO will watch for predefined file types, and lock these automatically to the first user to access them with Read/Write privileges. This protection allows other users to simultaneously access the file with Read Only permission, but prevents them from making changes that would undo the first user's work.
While this behavior is by design, there are some situations that arise where users may be surprised to see a "permission denied" message.
Here are some common scenarios where expected behavior may appear to be unexpected:
1. It may not be immediately obvious if nobody is actively editing, but content migration could be the culprit. As a protection, the Project Locking logic applies whether or not ShareBrowser Client is used, so a bulk transfer to a Project Locking share using another method such as Finder or Explorer will still result in generated locks associated with the machine that performed the copy, since this is a write operation.
Additionally, these locks may not be visible to clients since the operation has taken place outside of the ShareBrowser database.
If ShareBrowser Client is instead used to copy or move files, the database is aware of the operation and can make the distinction between editor access and a copy/move, and locks will be immediately released afterwards by default (the available settings are Always, Ask, or Never).
2. There may be a locked file buried somewhere within the path. For example, a locked project file may reside at /Volumes/Projects/2019/B_Roll/shoot/offload/April/Untitled.prproj, but this isn't obvious when viewing the contents of any of the parent folders above the "April" directory. Attempting to move or rename any of the parent directories would change the path to all files contained within, and is prevented as a protection for the locked contents.
3. Locks will persist until the owner clears them or the NAS session expires. While EVO can detect when a file is opened with Read/Write access, it cannot safely determine when a file is no longer in use, since the application does not provide this feedback.
If users' workstations are idle, but they still have volumes mounted with active locks, the locks will remain until they're intentionally released, the volumes are unmounted (and the session times out), or the user logs out of ShareBrowser Client and chooses to release all locks (the available settings are Always, Ask, or Never).
4. If working with Photoshop, see this article!
5. If working with Sony cards, see this article!
To remove unwanted project locks, use one of the following methods:
a. Identify the workstation that owns the locks and release them in ShareBrowser Client on that machine.
b. Unmount the share(s) from the machine that's applied the locks and give it a few minutes. The EVO will release locks after it safely determines a volume is no longer in use, and that it's not just a temporary network interruption. SMB sessions are share-specific, so each mounted share has its own session, while AFP is global, meaning all EVO volumes would need to be unmounted for the session to expire.
c. Log in as admin to the EVO administrative web interface and navigate to the NAS & Project Sharing page, select the share, and click "Clear all locks" -- take care to check that no locks are required for the share before performing the global unlock operation!
If "permission denied" messages persist and are not explained by any of the above, here are some other things that may be happening:
1. Both SMB and AFP protocols are used on the share, which can lead to metadata conflict. We recommend allowing only one protocol per share. The default and recommended protocol is SMB. Mixing the two can have undesirable effects (example).
2. A file may be seen as still in-use by an application. Some applications will create temporary files while the primary file is in use, and remove them when done. These temp files can become orphaned (such as if the share is suddenly disconnected while the application has the file opened), and the temp files will serve to protect the primary file from being altered. While this situation is never desired and should be avoided, removing orphaned temp files first will typically allow for the main file to be deleted.
3. For Mac, .DS_Store files can be problematic when working with any network shares. More information about this is found here.
4. The EVO and workstation clocks are too far out of sync. These should match as closely as possible, with an NTP server (network time) configured on each system to prevent clock drift.
5. Files may be protected as a result of third-party locks being copied with the content. For example, Sony and GoPro cards may include write-protected files that prevent modification unless permissions are manually changed.
Open a support case if you encounter any permission conflicts outside of what's described here!