Matching files will no longer move to Trash?

Just updated from Hazel 5.2.x to 5.3.3 and my rules now fail when trying to move from a network share (macOS SMB) to the Trash. If I modify the rule to move from the Network Share to the local Desktop, it works fine. It's just when trying to move to the Trash that it fails.

I can manually move to the Trash via Finder, without issue.

Both machines are running Monterey 12.7.4.

I've rebuilt a simple version of the rule and same results.

Code: Select all: 2024-03-29 11:12:45.019 hazelworker[1455] Running worker (v5.3.3) for folder with identifier: 905969668-766271. 2024-03-29 11:12:45.020 hazelworker[1455] ###Arch: x86_64 2024-03-29 11:12:45.021 hazelworker[1455] ###main load address: 0x10b66f000 2024-03-29 11:12:45.021 hazelworker[1455] ###Hazel Core load address: 0x10b93a000 2024-03-29 11:12:45.021 hazelworker[1455] ###Noodle load address: 0x10bc3e000 2024-03-29 11:12:45.021 hazelworker[1455] ###CK load address: 0x10b82c000 2024-03-29 11:12:45.061 hazelworker[1455] Processing folder TESTFOLDER 2024-03-29 11:12:47.183 hazelworker[1455] Untitled.txt: Rule Delete TXT matched. 2024-03-29 11:12:47.194 hazelworker[1455] [Error] Move failed: Could not move file Untitled.txt from folder /Volumes/Macintosh HD/Users/xxx/Desktop/TESTFOLDER to folder /Users/admin/.Trash. 2024-03-29 11:12:47.201 hazelworker[1455] Done processing folder DOWNLOAD

Is there any way to get more details on my it can't move the file? I've had this rule running for years without issue?

Thanks,
Kristin.

Can you turn on debug logging as described here? https://www.noodlesoft.com/kb/hazel-debug-mode/

After that, post updated logs.

Ah, debug definitely helps!

Code: Select all: 2024-04-03 11:35:58.995 hazelworker[48852] DEBUG: Error moving file /Volumes/NetworkShareNameRemoved/Untitled.txt to trash: Error Domain=NSCocoaErrorDomain Code=3328 "“Untitled” couldn’t be moved to the trash because the volume “NetworkShareNameRemoved” doesn’t have one." UserInfo={NSURL=file:///Volumes/NetworkShareNameRemoved/Untitled.txt, NSUserStringVariant=( Trash ), NSUnderlyingError=0x6000014322b0 {Error Domain=NSOSStatusErrorDomain Code=-120 "dirNFErr: Directory not found"}}

Looks like Hazel is looking for the Trash on the remote server (where the files/folders are that Hazel is watching), but can't find it. Does that help?

Thanks,
Kristin.

The issue is that the network share does not have a trash folder. Each drive should have a trash local to it. Try checking out your remote server to see if it can provide that.

Mr_Noodle wrote:The issue is that the network share does not have a trash folder. Each drive should have a trash local to it. Try checking out your remote server to see if it can provide that.

The network share is just a macOS (Catalina) shared folder mounted (via SMB) on the Mac running Hazel. I've been running this setup for a long time (started with Hazel 3 in 2012). Versions of macOS and Hazel have been upgraded over the years, to where I am today (two machines, both running Catalina, Hazel 5), but the basic setup/rules have remained the same.

The issue only started after I did the Hazel 5.3.3 update (from 5.2.x).

Not really sure where to go from here in terms of why there wouldn't be a local trash associated with the server share (if that's how it was working before)?

Just as a follow up, I've made some changes which have resolved the issue; not sure why the old setup stopped working, and the fix required a change in my sharing setup, so wouldn't be ideal in all circumstances, but it works.

Under the old setup, when I select "Move to the folder: Trash", if I looked at what Hazel was setting as "Trash" it was:

[Local machine running Hazel] Macintosh HD > Users > MyUsername > Trash [hidden folder, without a period in the name]

For whatever reason, this was now causing Hazel to fail (previously the file would just be deleted, since it was moving a file from a network share to the Trash, which doesn't put it in the Trash, but instead fully deletes the file from the network share). As the network share was just a shared folder on another Mac, there was no associated Trash (associated with that network share). So, rather than mounting just that shared folder, I'm now mounting the entire home folder of the user on the remote Mac; and in Hazel, I've now manually set the "Move to:" folder to:

[Network share; the entire home folder on the remote machine] .Trash (hidden folder in the root of the network share/user's home folder, with the period in the name)

This now works (the downside being, I'm now having to share the entire home folder of the user on the remote Mac).

Not sure what's changed that's caused this issue? And not sure how to get around having to mount the entire user folder so I can manually move the files to .Trash on the remote Mac?

Hazel used to have its own routine to move stuff to the trash. Sonoma screwed up a few things with regards to doing that with files in cloud services (iCloud, Dropbox, etc.). Instead of trying to emulate that and deal with some internal bugs/inconsistencies on Apple's part, I decided to switch to using Apple's code in 5.3 which does work but it's more strict about having a local trash available to each volume.

Are there are options/solutions available for moving files to the trash on remote share points, without sharing an entire user directory? I'm unsure how one would go about adding a local trash to a specific shared (macOS) folder? Either way, this means I won't be able to use a single instance of Hazel to delete files from share points as, even with the workaround of sharing the entire user folder to access local trash, the files end up sitting in trash on the remote server vs deleting them; which means I'll need to run a second instance of Hazel (or other automation software/scripts) on the remote machine to empty the trash.

I guess I could write a script that's triggered by Hazel to then run to delete the files from the server (vs moving to Trash), but hoping for a built in solution (though that's not looking likely with the 5.3 updates?

Usually there's a .Trash directory at the top level of the volume. That said, depending on the host of the drive, it may have its own location.

Mr_Noodle wrote:Usually there's a .Trash directory at the top level of the volume. That said, depending on the host of the drive, it may have its own location.

Understood, and there is. There's a number of different hidden trash files throughout the OS that are used depending on the user, etc. But none of those help under most sharing situations (unless you are, in fact, sharing the entire volume, or the entire user home folder); for regular share points created from a directory within one of those locations, there is no .trash (and an alias or symlink won't work either).

Anyway, I think the short of it is, "Move to Trash" no longer works under 5.3.x when the source is a macOS share point (that isn't the root of the volume/user home directory). I wrote a quick alternate rule, though, that gives the same results in the end, so maybe this will help some someone in the future with the same issue...instead of running "move to trash" on the matched files/folders, I'm running an embedded shell script that deletes the files/folders instead.

On files:

Code: Select all: rm $1

On folders:

Code: Select all: rm -r $1

That does the trick.

Mr_Noodle wrote:The issue is that the network share does not have a trash folder. Each drive should have a trash local to it. Try checking out your remote server to see if it can provide that.

Windows network share certainly do not have a .trash directory. Hazel is pretty useless until you revert this change. Can't delete files, can't move files (and "replace")...

If anyone is running into this problem and is willing to test, please email in to support as I have a test build to try. The quicker I can get people testing, the sooner I will be able to release it.

More than happy to test a possible update to the issue. Email sent to support.

Thanks,
Kristin.

Mr_Noodle wrote:If anyone is running into this problem and is willing to test, please email in to support as I have a test build to try. The quicker I can get people testing, the sooner I will be able to release it.