Consistent modification time preservation in Samba shares between Debian 12.5 and macOS Sonoma requires disabling legacy Unix extensions and enabling the VFS Fruit module. This configuration ensures that SMB2/SMB3 protocols handle file metadata correctly, preventing timestamp discrepancies during file transfers.
The Root Cause of Timestamp Drift
The inconsistency you are experiencing stems from how different versions of the Server Message Block (SMB) protocol handle file attributes. When macOS clients connect to a Samba server running on Debian 12.5, the default configuration often prioritizes backward compatibility over strict POSIX compliance or modern Apple-specific extensions. The primary culprit is usually theunix extensions parameter. If this is set to yes, Samba attempts to map Unix ownership and permissions directly through SMB commands. However, macOS relies heavily on extended attributes (xattrs) to store metadata like creation dates and modification times. These two systems conflict, leading to files appearing with incorrect timestamps after copying.
Furthermore, older configurations might explicitly enforce smb2 or smb3_00 dialects. It is critical to note that smb3_00 is deprecated in modern Samba releases. Using it can cause negotiation failures or fallback to less stable connection states. Instead, you should allow Samba to negotiate the highest available protocol version, which is typically SMB3.1.1 on Debian 12.5. This higher protocol version includes better support for directory leases and efficient attribute handling, which are essential for maintaining data integrity across heterogeneous environments.
Configuring Samba for macOS Compatibility
To resolve the issue, you must modify the/etc/samba/smb.conf file on your Debian server. The goal is to disable the legacy Unix extensions globally or per-share and enable the Virtual File System (VFS) module specifically designed for Apple clients.
First, locate your share definition within the configuration file. It likely looks something like this:
[my_share]
path = /srv/samba/my_share
browseable = yes
read only = novfs objects to include fruit. This module intercepts file operations and translates them into formats that macOS Finder understands natively. Additionally, you must ensure that ea support is enabled, as the Fruit module depends on Extended Attributes to store the necessary metadata.
Here is the corrected configuration snippet:
[my_share]
path = /srv/samba/my_share
browseable = yes
read only = no
vfs objects = fruit streams_xattr
ea support = yes
fruit:encoding = native
fruit:metadata = stream
fruit:veto_appledouble = no
create mask = 0664
directory mask = 0775fruit:encoding = native setting ensures that filenames are encoded using UTF-8, which prevents corruption issues on macOS. The fruit:metadata = stream directive tells Samba to store metadata in separate stream files rather than trying to embed it in the main file data, which improves performance and reliability. By removing any reference to unix extensions = yes, you force Samba to rely on the standard SMB protocol for basic operations and let the Fruit module handle the Apple-specific requirements.
After making these changes, you must restart the Samba services to apply the new configuration. Run the following command on your Debian server:
sudo systemctl restart smbd nmbdVerifying the Fix
To confirm that the configuration is working correctly, perform a simple test. Create a new file on your macOS desktop and copy it to the Samba share. Then, immediately check the file's properties in the Finder by pressing Command+I. Compare the "Modified" date with the actual system time. Next, copy the file back to your desktop and verify that the timestamp remains unchanged. If you still experience issues, check the Samba logs located at/var/log/samba/. Look for entries related to fruit or vfs errors. Common mistakes include typos in the vfs objects line or forgetting to enable ea support. Without Extended Attribute support, the Fruit module cannot function properly, regardless of other settings.
For more information on resolving general permission conflicts that might accompany timestamp issues, you may find the guide on Resolving Samba Permissions Inconsistency Across Multiple Systems helpful. Permission mismatches often exacerbate metadata problems, so ensuring correct ownership is a vital secondary step.
Performance Considerations
Enabling the Fruit module adds a slight overhead to file operations because Samba must process additional metadata streams. However, this overhead is negligible on modern hardware and is far outweighed by the benefits of seamless integration with macOS features like Spotlight indexing and Time Machine backups. If you notice significant slowdowns, ensure that your Debian server has sufficient I/O throughput. Using an SSD for the share path can mitigate any latency introduced by the extra metadata writes. Additionally, avoid mixing clients that do not understand Apple metadata. If Windows clients access the same share, they will simply ignore the extended attributes created by the Fruit module. This is safe and does not corrupt the files; Windows will just see the standard NTFS timestamps derived from the Unix timestamps. For a deeper dive into cross-platform authentication issues that often plague mixed environments, consider reading about Clients Trying to Log into Samba Root: A Common Issue for Small Debian Linux Servers. While distinct from timestamp issues, proper user mapping is essential for overall share stability.Frequently Asked Questions
Does disabling unix extensions break Linux client access?
No, Linux clients continue to work normally because they rely on standard SMB/CIFS protocols for file transfer. They do not depend on the Unix extensions for basic read/write operations, though some advanced permission mapping features might behave differently if explicitly configured elsewhere.
Can I use this configuration for Time Machine backups?
Yes, enabling the Fruit module is actually required for reliable Time Machine backups over SMB. The module provides the necessary sparse bundle support and metadata handling that macOS expects for backup volumes.
Why are my filenames showing as ._ files?
This indicates that AppleDouble files are being generated. Setting fruit:veto_appledouble = no in your configuration prevents this behavior, allowing Samba to store all metadata in streams instead of creating separate resource fork files.
Is SMB3.1.1 supported on Debian 12.5?
Yes, Debian 12.5 ships with a version of Samba that fully supports SMB3.1.1. You should allow automatic negotiation to ensure both the client and server agree on the highest secure protocol version available.
What if I cannot edit smb.conf directly?
If you lack root access, you cannot fix this issue permanently. However, you can sometimes influence client-side behavior by ensuring your macOS system preferences have "Mount as network volume" checked, though server-side configuration is the only reliable solution for timestamp consistency.