Had a quick search but nothing obvious.
Summary
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.
Details:
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.