Overview

By default, macOS and many Linux distributions support a per-volume "Move to Bin" and "Move to Trash" function. Whereby files that are marked for deletion from the UI go to the dedicated .Trashes or .Trash-1000 folder. These folders are hidden directories on the volume where the file originally resided. This means that files and folders are not immediately deleted, rather they are moved to a temporary holding area before you "Empty the Bin".

Commands like 'rm' bypass the Bin/Trash as they do not just mark files for deletion, but delete them right away.

Since LucidLink is mounted like any other Filesystem, the "Move to Bin" functionality is present "out of the box", which is great in most situations, but certain caveats do exist.

Known Caveats

Unable to Delete via File Manager UI

Most Linux distributions and other operating systems store the Trash folder at the root of a filesystem in a hidden directory such as .Trashes or .Trash-1000. For full operation, this directory needs to be writable to all users of the filesystem. In the case of a LucidLink filespace, there are situations where you may only want to give R/W (Read/Write) permissions to a sub-folder on a per-user basis, but provide R/O (Read-Only) permissions to the rest of the filespace.

A typical permissions structure may look like this:

/      - Read-Only  - Everyone
/A/B/C - Read/Write - GroupA

If these permissions are present from the start, you likely won't encounter any issues. But if GroupA has R/W to / at some point and a User in GroupA sends a file to their Trash, and subsequently goes back to R/O permissions, macOS can have issues deleting files via the file manager UI from the directory /A/B/C. This is because the system may read that a Trash is located at /.Trashes/UID and assume it can send more data there, even though the root is now R/O. 

Deletions from the file manager UI will fail. Deletions from the terminal, using the rm command, will work as they bypass the Trash mechanism.

Workaround: With R/O on / and R/W on a sub-directory you can still use the built-in Trash functionality by giving Everyone R/W to /.Trashes or .Trashes-UID.

Alternative: Disable Trash functionality on the Filespace by following this KB article:

Disabling the Bin/Trash function on a Filespace on Linux

Trashes visible to all Users

Most Operating Systems handle Trashes per-filesystem and assume a locally attached Filesystem. Because of this the Trashes are separated per User, based on their UID (User ID).

In environments with multiple users, it's highly likely that people on different machines may have the same UID (e.g., 501, 502, etc.). The .Trashes folder is written to and read from folders like ./Trashes/501 and /.Trashes/502 to keep the Trash persistent following filesystem disconnects.

Herein lies the caveat on a collaborative Filesystem: if multiple users share the same UID, their operating systems will all think that they own the same Trash. This means that opening your Trash may show files that you never sent to the Trash or have never seen before.

Workaround: Ensure all macOS/Linux users have unique UIDs. Although this is typically not feasible in most deployments, especially in freelance workflows and BYOD (Bring Your Own Device) scenarios.

Alternative: Disable Trash functionality on the Filespace by following this KB article:

Disabling the Bin/Trash function on a Filespace on Linux

"Move to Bin" functionality on macOS

The macOS Bin/Trash functionality does not work in New LucidLink. Files and folders deleted from the filespace will be permanently removed unless they were captured in a previous filespace snapshot.