Created date removed from all files copied to Truenas from Mac

[readynas_refugee]

Hi community,

I am a novice Truenas user and this is my first install and first post. As the title says, when I copy files to my TrueNas from my Mac, the created date of the file disappears. I still have modified date, but that's just the same as the time of the copy. This varies from being annoying to being quite serious. I dont have the same problem from Windows. Apart from this I have not experienced any problems with TrueNas.

TrueNAS Version: TrueNAS Scale 12.02.2.1
Mac Version: Mac OS 12.4
Share Type: SMB. I have ticked "Enable Apple SMB2/3 Protocol Extensions" on the service but don't have any other parameters entered. When I created the share, under the "Purpose" field I have used "Default share parameters".

Has anyone else had this issue? Have I maybe missed a step on the configuration? Any help would be appreciated.

 

[readynas_refugee]

Noone using a Mac and Truenas?

 

[winnielinnie]

when I copy files to my TrueNas from my Mac, the created date of the file disappears.

As far as I'm aware, "creation date" is too low-level to override. We only have control over "modification time".

I still have modified date, but that's just the same as the time of the copy.

I don't have a Mac to test this with, but from a Linux client or Windows client, the modification time stays preserved (down to the very second) when I copy a file to an SMB share on TrueNAS.

 

[EMP-Tea]

when I copy files to my TrueNas from my Mac, the created date of the file disappears.

I also ran into this problem in TrueNAS Core 12.0-U8.1 over SMB. I tried using AFP instead but it has its own issues. Switching to 13.0-U1 and using AFP preserved metadata— like created date— but macOS rebooted from what I assume was a kernel panic in the middle of one transfer so I don't know how stable it is. Plus I was told AFP has been removed from Scale, so that doesn't help your situation.

 

[anodos]

Hi community,

I am a novice Truenas user and this is my first install and first post. As the title says, when I copy files to my TrueNas from my Mac, the created date of the file disappears. I still have modified date, but that's just the same as the time of the copy. This varies from being annoying to being quite serious. I dont have the same problem from Windows. Apart from this I have not experienced any problems with TrueNas.

TrueNAS Version: TrueNAS Scale 12.02.2.1
Mac Version: Mac OS 12.4
Share Type: SMB. I have ticked "Enable Apple SMB2/3 Protocol Extensions" on the service but don't have any other parameters entered. When I created the share, under the "Purpose" field I have used "Default share parameters".

Has anyone else had this issue? Have I maybe missed a step on the configuration? Any help would be appreciated.

Can you send me a PCAP of the behavior or a debug? Does the issue occur if you don't use the apple extensions?

FreeBSD does allow modification of file create time (and this is generally required for proper SMB protocol support). When MacOS clients see this error, what is output of `stat -x /path/to/file` from shell on TrueNAS?

 

[Volts]

Can you confirm that Enable ACL is enabled on the share?
Can you share the output of testparm from the shell?

I notice weird behavior on TrueNAS CORE if Enable ACL isn't enabled on the share.
When Enable ACL is enabled, vfs objects includes ixnas.
When Enable ACL is not enabled, vfs objects includes noacl.

When Enable ACL is not enabled, the file attribute st_birthtime / Create time isn't preserved. It seems like it's just dropped.

(This isn't related to the Apple protocol extensions or fruit module AFAICT. The problem occurs when that's disabled, and it occurs when trying to modify st_birthtime / Create time from a variety of client types.)

I was using SetFile on the Mac and Attribute Changer from a Windows machine. Working on a minimal pcap now.

 

[anodos]

Sorry, I glossed over your configuration and didn't realize this was SCALE. On SCALE the create time should be synthesized in a special DOS attribute xattr (user.DOSATTRIB) (actual inode birth time isn't changed).

 

[anodos]

Ah, it looks like an issue with vfs_fruit when `fruit:nfs_aces = true` and the fchmod() op fails. We basically end up with a bogus timestamp in the user.DOSATTRIB xattr. You can check by setting fruit:nfs_aces = false as an auxiliary parameter in Services->SMB.

 

[anodos]

Hmm... not quite a bogus timestamp. It's the HFS+ epoch. It looks like MacOS initializes create time to the value and then sets it to an appropriate one after finishing copying the file over. This may take me some time to investigate, but for mitigation, you can set the auxiliary parameter.

Do note that the timestamp actually exists, it's just set to 1903, which Finder interprets in a special way to make it hidden.

 

[readynas_refugee]

Does the issue occur if you don't use the apple extensions?

I have just disabled/unticked "Enable Apple SMB2/3 Protocol Extensions" from the SMB service. Created date is now working. I can't really detect any performance degradation either and if anything I would say mounting shares and general browsing with Finder is now quicker. I wasn't expecting this.

Eventually I would have liked to create a share for TimeMachine for which I believe that checkbox is necessary. TM is not a deal breaker though and I would rather have solid NAS performance. I'm going back to do more testing now to see if the problem is really gone and if any new problems have appeared.