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 macOS Finder
macOS and most Linux distributions 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 Day 1 and it remains that way, 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 Finder from the directory /A/B/C. This is because macOS can read that their is a Trash located at /.Trashes/UID and assumes it can send more data there, even though it is R/O. Deletions from Finder will fail. Deletions from terminal, with rm, will work as they bypass the Trash.
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 on Linux).
Alternative: Disable Trash functionality on the Filespace by following this KB article: https://support.lucidlink.com/hc/en-us/articles/11666020428685
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. So in an environment of multiple macOS Users, for example, it's highly likely there will be people on different Macs with the same UID (501, 502 etc). Because of this, the .Trashes and written to and read from ./Trashes/501 and /.Trashes/502 for example to keep the Trash persistent following Filesystem disconnects.
Herein lies the caveat on a collaborative Filesystem, if multiple users share the same UID then their Operating Systems will all think that they own the same Trash. So opening your macOS 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, freelance workflows and BYOD (Bring Your Own Device) scenarios.
Alternative: Disable Trash functionality on the Filespace by following this KB article: https://support.lucidlink.com/hc/en-us/articles/11666020428685