Copied files - last modified date not being shown (or isn't copied) as it should be

Had a quick search but nothing obvious.

Using either cp on the new Truenas server or Teracopy on a windows client copying from old shares on Xigmanas to new shares on TrueNAS results in apparently random behaviour in terms of setting the last modified date for both directories and files.

Some are copied correctly, Some become the physical creation date/time on the new server.

I would obviously like to get to the bottom of this as it’s knocking my confidence in using TrueNAS going forward.

Has anyone experienced this and/or got a solution or workaround to this? Any help and advice gratefully received.


I have an old Xigmanas server that I’ve been meaning to transfer over for a while. As I’ve never done this before I thought I’d create a backup before attempting any other activities. Total data is somewhere around 26TB

To that end I created a new TrueNAS scale server, set up a Raidz1 pool, created datasets (SMB) - one for one almost from the existing, created users, set dataset owners to me and specific owner group so I have full read and write permissions. Then created the SMB shares.
All well and good. No issues accessing new or old drives either in Windows 10 client or from the servers.

Initially mounted the old SMB server shares via mount cifs to allow me to run copy operations on new server i.e. direct copy. relevant passwords given as prompted during mount.

Then ran a test copy using cp on new server to drag across a small share from the old. First run forgot -p so wasn’t surprised to see these were created with that day’s date/time. Deleted and re-ran. date and time still wrong??

Went a few times through loops of checking permissions were all OK, resetting dataset permissions and ACLs on SMB shares. Eventually copy started going OK, but I hadn’t really changed anything.

Started again. 2 shares copied OK, i.e. modified dates came across as per the originals, but third share didn’t.

Gave up this approach and decided to copy using a Windows client, i.e. use the cient to drag from old server and write to new. It’s slower but it should all be under Windows control so ACLs and attributes such as last modified should (I thought) be preserved. For this I use Teracopy as this does file verfication and shows up any issues in one long list. This time all the small shares came across OK. i.e. dates as I expected - at least based on random sampling.

Finally got to the point where all smaller shares were done and all appeared good so started the larger share with video files. There’s at least 3 days worth of copying when the network isn’t used for anything else.

All looked good after 1/2 an hour and 3 hours later.

Today (day 2) went in to check and at some point during the copy process overnight the dates and times started to be shown as yesterday and today’s date plus relevant creation time. This on both the directories and the files.

Went in to server using PuTTY session and terminal and “ls - l” on the directories shows creation dates that agree with the dates being shown in Win 10 explorer last modified date. I have to assume therefore that either the OS is reporting something wrongly or that part way through the copy process something is happening that causes a change in behaviour of either the OS or of ZFS, but that doesn’t seem likely.

Bit stumped to be fair and not sure what to try next.

What version of TrueNAS?

Do note that there’s a difference between a file’s creation (birth) time and its modified time. The former is immutable from userspace in SCALE, but the latter may be changed by applications. Since the former is immutable, Samba writes an application-specific mutable creation time in a user-namespace xattr user.DOSATTRIB. This will not be visible to external applications.

The situation is slightly different on Core (FreeBSD) as FreeBSD allows changing birth time from userspace.

1 Like


It’s TrueNAS-SCALE-23.10.2 - whatever was available a couple of weeks ago.

Rest of setup is:
Running on An Asus m/b with Intel(R) Core™ i7-3770K CPU @ 3.50GHz and 32Gb non-ECC mem.
Essentialy an old desktop repurposed with 4 new Toshiba 18GB MG series disks. These have been up and runnnig for 3-4 weeks with some limited testing and copying. This was meant to be the workout for the drives - bit of to and fro copying for backups until the old drives/pool are moved over successfully.
All new drives showing fine.
Networking - active is 10G SFP+ Broadcom NIC, also in there but inactive are 1GB onboard NIC and 10GBE Intel NIC.

Re. times,
Understood that create and modified are different and I also know that normally Linux doesn’t do this the same as Windows.
However what I am struggling with is that the same copy (actually the same run of the copy in this last instance) has copied over some files and directories so that what shows for the new file matches the old BUT some have been copied over and I’m seeing in the new the original date/time being replaced with the date time at which the copy occurred. In fact from whenever it “went wrong” all new directories are being written with the current date time.

I assume that this is the samba specific attribute that you refer to as an entry in user.DOSATTRIB

Not my area of expertise but it would seem that at some point the file operations behind the copy have changed from actually copying said attribute to not bothering, at least for directories.

I didn’t take notes on the first few failures but sometimes it’s just new directories that take the creation date/time and sometimes it’s both the new directories and files. I know this because one of the earlier failures was my photography share. I use the files modifed date in addition to metadata within the files to organise these files, so I had to repeat the copy until it worked for those!

If you can come up with an easy way to reproduce using built in Windows tools (not teracopy) then I can probably fix for next release.

Hmmm, it looks like this is a combination of complete lack of knowledge of linux copy commands and a misunderstanding of how teracopy performs its copying of directory attributes. - On my part.

I don’t understand why the cp -p method from server to server didn’t work but I couldn’t get it to work reliably and as I’m not sure whether as far as the OS was concerned I was doing zfs to zfs or smb to zfs or indeed smb to smb and I don’t know whether cp can cope with extended attributes either ZFS or NFS4 - well, that’s why I gave it up.

Teracopy I’ve used reliably for about 10 years and never had an issue with it. Locally or on 3 different types of NAS. - Zyxel, Netgear and Xigmanas.

What I didn’t appreciate until this afternoonis that it doesn’t actually write the new directory timestamps until the end of the copy.

It also has the ability to queue up copies for the same run, so I added the main subdirectories in 3 chunks. 3TB, 3TB and 20TB.

Clearly the queued copies are run as separate copies from a front end, rather than being one big copy. What I described as the apparent output was what I saw when the first two had completed but the third was mid copy.

As soon as I stopped the last copy, all the directories on the destination server (other than the top level) suddenly showed the correct timestamp. I wait to see whether when the verify phase has finished the top level gets updated or not.

So thanks for your assistance. It made me re-examine my assumptions.

…now all I need is to work out how to use Rsync across 2 Truenas servers for an effective backup once the recovery and migration from XigmaNAS is complete. but that’s for another day.

I don’t see reason to ever use rsync between TrueNAS. ZFS replication is generally vastly superior option if it is available.

1 Like

Ah, well in that case I’ll be reading up about that then. Thanks again.