Why Do .smbdelete Hidden Files Appear After Deleting on Mac SMB Shares? Causes & Ultimate Solutions

# Why Do .smbdelete Hidden Files Appear After Deleting on Mac SMB Shares? Causes & Ultimate Solutions When mounting an SMB share (like a Synology NAS) on macOS via Finder, many users encounter a frustrating issue: after deleting a large file (such as an MP4 video), the file disappears from view, but a hidden file named something like `.smbdeleteAAA2800b3` appears in its place. This hidden file takes up the exact same amount of space, meaning the storage hasn't actually been freed. This article delves into the technical mechanisms behind this phenomenon and provides comprehensive solutions—from software tweaks to network hardware fixes—based on troubleshooting experiences from the `wiki.lib00.com` community. ## The Core Mechanism: macOS "Rename-on-Delete" The appearance of `.smbdeleteXXXX` files is a protective mechanism employed by macOS when handling SMB shares, known as **Rename-on-Delete**. In Unix-like systems (including macOS and the Linux core of Synology), if a file is currently "open" or "in use" (i.e., a process holds its File Handle), the system cannot physically erase it from the disk. To respond to the user's "delete" command gracefully, the macOS SMB client takes a workaround approach: 1. **Rename**: It renames the original file to a hidden file starting with `.smbdelete`. 2. **Hide**: It removes the file from the user's Finder view (though it still occupies physical space). 3. **Standby for Deletion**: It waits until all processes holding the file handle close it, after which the system sends the actual deletion command to the server. --- ## Common Triggers and "Suspect Processes" ### 1. macOS Local Background Processes Before you hit delete, local macOS services might be reading the file: * **QuickLook**: Pressing the spacebar to preview, or Finder generating a thumbnail. * **Spotlight Indexing**: The system is scanning the video's metadata. * **Lingering Media Players**: You just closed the video, but the player process hasn't fully released the file handle yet. ### 2. Docker Container Locks (Very Common) If you have mapped this SMB volume as a `Volume` or `Bind Mount` into a Docker container, the apps inside are highly likely the culprits. Author DP@lib00 notes that during similar troubleshooting, the following apps frequently cause file locks: * **Media Servers**: Plex, Jellyfin, or Emby scraping metadata or generating previews in the background. * **Download Clients**: Transmission or qBittorrent still verifying or seeding the file. * **Sync Tools**: Nextcloud or automated organization scripts scanning the directory. As long as the program inside the Docker container doesn't "let go," the `.smbdelete` file will persist. ### 3. Unstable Network Connections (The Ultimate Hidden Cause) This is the most easily overlooked factor. If the network connection between your Mac and the NAS is unstable (e.g., weak Wi-Fi, switch packet loss, faulty NIC), it can result in **Ghost Sessions** in the SMB protocol. When the network briefly drops and reconnects, the NAS might think the old session is still active, maintaining a lock on the file. When your Mac sends the delete command, the "network ghost handle" prevents immediate deletion, triggering the `.smbdelete` mechanism. --- ## Solutions To completely resolve this issue, you can take the following steps: ### Solution 1: Fix Network Hardware Issues (Highly Recommended) If this happens frequently and you've ruled out software locks, **check your network connection first**. Try changing your network connection method (e.g., switching from Wi-Fi to a wired Ethernet connection) or replacing hardware like routers/switches. Once the network connection becomes rock-solid, "ghost handles" caused by network drops will cease to exist. The user who originally reported this confirmed that after fixing their network hardware, the `.smbdelete` files disappeared immediately upon deletion. ### Solution 2: Inspect and Stop Docker Containers If you know the folder is used by Docker: 1. Go to the Docker manager in Synology DSM and temporarily stop containers that might access the path (like Jellyfin). 2. Once stopped, the handles are released, and the `.smbdelete` file usually vanishes automatically. 3. *Pro Tip*: If the container only needs to read files, check the **"Read-only"** box when configuring the volume mount. This drastically reduces write/delete conflicts. ### Solution 3: Force Delete via NAS File Station If you don't want to troubleshoot networks or processes, the most straightforward method is to bypass the SMB protocol entirely: Log into Synology DSM, open **File Station**, and delete the file directly from the NAS's local file system. The local file system (Btrfs/EXT4) has the highest priority and will forcefully cut connections and free up space. ### Solution 4: Terminal Cleanup (Advanced) If you have a massive buildup of these files, you can clean them up via the Mac Terminal (replace the path with your actual mount point, e.g., `/Volumes/lib00_share/`): ```bash # Find and delete all .smbdelete files in the specified SMB mount rm -rf /Volumes/YourSharedFolder/.smbdelete* ``` **Conclusion:** The appearance of `.smbdelete` is not a failed deletion, but rather the SMB protocol's self-protection mechanism in multi-process or unstable network environments. By optimizing your network hardware or managing Docker permissions, you can eliminate this annoyance for good.