SMB: Deleting large folders fails from macOS Finder

[anodos]

Hello folks,
This is the end of 2021 and I am having this same issue on TrueNAS 12 with clients on macOS Mojave. It is getting so annoying. Trying to delete folders with lots of files (or not even that much) regularly fails with the same issue. If I go into TrueNAS command line and delete by hand, I can always do it, but deleting out of the Finder always runs into these .smbdelete files mysteriously appearing and stopping macOS from deleting the folders.
I wouldn't assume that macOS is creating .smbdelete files while traversing the folder structure to delete its contents.
Where do these come from and why are they not getting deleted? Sometimes if I wait a bit and retry the delete operation, something else will be deemed unremovable and some of the inner folders can be deleted, but others.
Looks like some background task is doing a very lousy job at keeping up with deleting files for SMB.
My TrueNAS box is doing almost nothing so it is definitely not a performance issue, it is not in a VM either.

What's output of "testparm -s"?

 

[Andreaux]

Here's the output. I left in only one share as others have the same attributes.
Thx.

root@fractal[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
lpcfg_do_global_parameter: WARNING: The "client ntlmv2 auth" option is deprecated
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE

# Global parameters
[global]
aio max threads = 2
bind interfaces only = Yes
client NTLMv2 auth = No
disable spoolss = Yes
dns proxy = No
enable web service discovery = Yes
kernel change notify = No
load printers = No
logging = file
max log size = 5120
netbios aliases = FRACTAL
nsupdate command = /usr/local/bin/samba-nsupdate -g
ntlm auth = ntlmv1-permitted
registry shares = Yes
restrict anonymous = 2
server role = standalone server
server string = Fractal NAS
unix extensions = No
username map = /usr/local/etc/smbusername.map
username map cache time = 60
workgroup = OURHOME
idmap config *: range = 90000001-100000000
fruit:nfs_aces = No
idmap config * : backend = tdb
directory name cache size = 0
dos filemode = Yes

(...)

[Backups]
access based share enum = Yes
ea support = No
path = /mnt/Volume_1/Backups
read only = No
vfs objects = fruit streams_xattr shadow_copy_zfs ixnas aio_fbsd
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true

(...)

 

[anodos]

What is output of `getfacl /mnt/Volume_1/Backups`?

 

[Andreaux]

root@fractal[~]# getfacl /mnt/Volume_1/Backups
# file: /mnt/Volume_1/Backups
# owner: gabriel
# group: workers
everyone@:--x---a-R-c---:-------:allow
group@:rwxp-daARWc--s:-------:allow
owner@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

 

[anodos]

What is the acl on the .smbdelete file?

 

[Andreaux]

I'm afraid I'll have to watch out next time, I didn't check :(
I would assume something different as my user is unable to delete it when it happens and Finder shows it greyed out (Forklift in fact since they're invisible to Finder).
I'll get back with the answer as soon as I run into another one.

 

[anodos]

root@fractal[~]# getfacl /mnt/Volume_1/Backups
# file: /mnt/Volume_1/Backups
# owner: gabriel
# group: workers
everyone@:--x---a-R-c---:-------:allow
group@:rwxp-daARWc--s:-------:allow
owner@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

Oh, sorry, I overlooked a problem here. You have no inheriting permissions for the `workers` group. Maybe set an explicit (group, not group@) entry granting them MODIFY permissions with INHERIT flag set (and do it recursively).
As things are set here, only the file owner will be able to modify things below Backups directory (so going one deep may fail for anyone other than directory owner).

 

[Andreaux]

Honestly, I'm the only one using that share and when I ran into the issue, I was deleting directories owned by me. I will try however and get back with results. Thanks!

 

[Andreaux]

This issue is still happening, despite all the advice in here, whenever a large folder is being deleted, the operation hangs with a ".smbdelete(whateverrandomnumber)" file being in use. Seems to me like deletions are deferred and that files are only "marked for deletion" until some process effectively removes them. Which makes removing the folder impossible.
Can anyone effectively look into this issue?
It's been going on for years and is still there and many are having similar issues.

 

[awasb]

Did You - just for testing purposes - disable icon preview and preview pane in finder? While generating thumbs from media files, macos causes file locks.

 

[XStylus]

This issue is still happening, despite all the advice in here, whenever a large folder is being deleted, the operation hangs with a ".smbdelete(whateverrandomnumber)" file being in use. Seems to me like deletions are deferred and that files are only "marked for deletion" until some process effectively removes them. Which makes removing the folder impossible.
Can anyone effectively look into this issue?
It's been going on for years and is still there and many are having similar issues.

I've continued to experience the same issue as well with MacOS Finder. However, I've managed to work around this issue by using Finder alternatives, such as Commander One or PathFinder. I have not ran into the issue with those apps.

 

[Nicolas_Studiokgb]

Sorry. I misread the post. There's a separate issue that causes deletes to be extremely slow (Mac clients rescan directories after each delete causing performance issues).

Hello I think it is clearly the issue i meet actually, is there something about that since ?
Thanks

 

[Andreaux]

Sadly no. I'm still constantly getting this issue if I'm deleting folders with lots of files and subfolders and it's annoying to a level I can't even describe. Looks like some .smbdelete file is created in those directories and the delete process fails, with time, that .smbdelete file vanishes and attempting to delete the files, the process will go for a while, then break again, and again, and again, and again until the last file is gone.
And this thread is 4 years old.

 

[Nicolas_Studiokgb]

Hello Andreaux. I not sure it's the same issue for me, Deletion works but it takes ages to achieve because metadata overload the server.
Anodos seems to talk about a finder issue that would slow deletion (or file replacement) to an extreme point. I was wondering if there was some update on this as I can't find how to solve the problem.

 

[Nicolas_Studiokgb]

Sadly no. I'm still constantly getting this issue if I'm deleting folders with lots of files and subfolders and it's annoying to a level I can't even describe. Looks like some .smbdelete file is created in those directories and the delete process fails, with time, that .smbdelete file vanishes and attempting to delete the files, the process will go for a while, then break again, and again, and again, and again until the last file is gone.
And this thread is 4 years old.

I know this issue with Mojave and on AFP shares, We had this issue of file is locked, in use or whatever and you have to go manually in each folder to delete files. But with monterey with smb on Truenas I don't have this issue for now. but deletion or overwrite of large folders take ages... (55k items is about more than 1hour)