"The operation can’t be completed because the item is in use."

TrueNAS General
1

Testing deploying a TrueNAS CE v25 server at the company, we’re 90% Mac and 10% Windows.
I created a test SMB share, 2 users with RW permissions. Minutes into testing whether both users can modify each other’s files on the share (as it should be), I get macOS Finder errors:

“The operation can’t be completed because the item (…) is in use.”

This can still happen if I navigate away from that folder, etc. on the system that presumably still has the lock, and give it many minutes.
I don’t have any files open from the share on either client.

To reproduce:

  1. User1 create a folder, then navigates away from it.
  2. User2 navigate to the folder and attempts to delete it
    Sometimes it works, sometimes it errors. The error can stick for even half an hour.

Looking this up brought up a discussion from 9 years ago, back when everyone was editing smb.conf all the time. Now that option is nearly gone, and TN is adamantly against editing smb.conf and denied submittals on why one would need this capability.

I do see that the default smb4.conf has “vfs objects = fruit streams_xattr”, but not catia, and not strict locking=off and other parameters that have been recommended as optimizing SMB for macOS.

  • What should I do to fix this behavior? Whether in the GUI, or with cli > service smb update smb_options…
  • Is this a valid example of a missing capability to submit

Thanks!

(PS I sorely wish it was possible to pay to get official support for TrueNAS software on non-TrueNAS hardware, but alas…)

2

Can you be more specific on how you were testing? Were the users both on Apples or did you do one Mac and one Windows? Did you test with more than one combo and it still happens?

I notice my Windows 11 likes to keep files open in Photos app even when closing the picture. It takes a while before I can delete items, even just on the Windows computer itself. Trying to narrow down what is causing the issue.

3

There’s literally a checkbox for the share to do the catia thing (apple name mangling). C.f. documentation.

The closed tickets were often because either:

  1. User was requesting something in the UI already
  2. User was requesting things that are already implemented in different ways but didn’t match up with the results of what google (and now AI) show up.

The SMB protocol does not allow deletions of directories while a client holds a file open. There are UI features to view a list of open files in the SMB share so you can look at what client is doing the dirty.

Historically, there were some issues with old, buggy MacOS clients not properly closing alternate data streams on files.

4

All Apples.

M3 Pro MBP, macOS 14.7.8
M1 Studio Ultra, 13.7.5
I also tested with a 3rd system, M2 Studio Max, 13.7.8 - same behavior

It’s interesting that 3rd time’s a charm, every time. The problem reproduces the 3rd time I try it (per smbd restart).

Complete steps to reproduce:

  1. Open Finder on two Macs, on the same share.
  2. Ensure both SMB users have RW permissions to the share.
  3. User1 create a folder, “User1A”. User2 delete it — no problem.
  4. User2 create a folder, “User2A”. User1 delete it — no problem.
  5. User1 create a folder, “User1B”.
  6. User2 delete it — “the operation can’t be completed because the item User1B is in use”.

No Photos app, no files, no any app, no Windows.
It appears that Finder is causing the issue.

5

There are no files involved (insofar files being distinct from directories). I only made it as far as testing with empty directories.

However, when digging deeper it appears that TrueNAS isn’t doing anything to stop the Macs from deleting; macOS / Finder is bringing it all upon itself.

sudo smbstatus | grep <share> -A5 shows all Oplocks are NONE. Only lsof on the Mac shows that the directory is locked.

Furthermore, the same behavior happens with a Synology NAS.

I tried to coax the client into letting go by setting

fruit:locking = none
durable handles = no
delete veto files = yes
smb2 leases = no

(and restarting smbd each time). None of that helped, the behavior stayed the same. Maybe there are client-sided nsmb / Finder settings that could help, I haven’t gone there.

So I’m not blaming TrueNAS here, and I’m not surprised Apple does…this But I’m surprised this basic macOS permissions behavior bug hasn’t seen more exposure.