Last week, my Synology was running out of space, so I decided to make a HexOS machine.
It worked pretty quickly, but I wanted to use rsync to pull all the data from Synology, to make them communicate directly, and also preserve the “Last modified” of the directories, which HexOS doesn’t provide yet.
So with ChatGPT, I went into TrueNAS and Synology to setup rsync. It took a while, but it worked in the end…somewhat. It’s 8TB of data, 2 days later it hasn’t even finished creating the directories, probably because I checked “compressed”?
Doesn’t matter, the point is, almost all the directories still has the current time as “Last Modified”…aside some directories did preserve the old date, for some reason.
Spent a morning switched the requester as root turns out doesn’t change anything, I’ve given up asking AI for help at this point.
Did some Googling, seem like it can be a thing for SMB share folder…? Maybe some HexOS preset caused the behaviour? I have no idea.
Anyway, I deleted the HexOS’s SMB share and created a new dataset…Yap, same thing. It’d have the “Just now” or “few minutes ago” as last modified, and somehow 1 or 2 directories perfectly stayed at 2017 or so.
Just what’s going on here? Do I just give up the modified date information? Is it actually going to be set correctly if I let it run to the end, which would take days? It’s driving me crazy.
Thanks for reading.
That’s out already?
I assume you mean their web UI? The underlying OS (TrueNAS) not only has Rsync Tasks in the GUI, but it can also be used in an SSH session / command-line.
Nice. 
Awe. 
Not sure.
How did you setup the Rsync Task? Did you use the GUI or command-line?
Are you trying to do this transfer to an actual SMB share on the network, or directly to TrueNAS from Synology via SSH?
It’s combination of GUI to setup the task, and a password file with Auxiliary Parameters.
I’m going through Module mode instead of SSH. I know it’s still end-to-end because it still runs while my main PC is shut down, but do you think switch to SSH would make a difference?
Those only exist on TrueNAS Core.
You have HexOS managing a TrueNAS Core server?
I didn’t think that was possible, let alone supported.
HexOS is just a wrapper for TrueNAS Scale. I went into TrueNAS GUI to do all these, that’s why I didn’t post in HexOS forum.
Those only exist on Core. Unless you’re using an old version of SCALE?
The version is ElectricEel-24.10.0, provided by HexOS.
Not updating since someone said he broke his HexOS by doing so.
Where are you seeing Rsync Modules and Auxiliary Parameters in SCALE 24.10? Those have since been removed.
By Data Protection → Rsync Tasks → Add Rsync Task, or Datasets → Manage Rsync Tasks, and use the pen icon to edit. It creates a side bar on the right which lists out options including the ones I mentioned.
Can you share the parameters and options you used for this task?
Where are the modules configured? On the Synology side? You’re doing a “pull” task?
Can I ask what you’re looking for?
As I stated, the transfer itself went without errors, which was after 15 failures with constant tweaking.
The Remote Host and Module name these basic stuffs are all at least functional enough that it successfully pulled the directories from Synology.
But anyway, the options checked are (The forum doesn’t allow me to paste image):
Times, Archive, Delay Updates
The Unchecked Options are:
Compress, Delete, Quite, Preserve Permisions, Preserve Extended Attributes
Also, I browse the files with Dolphin on Fedora 42 KDE, which shouldn’t matter, but might as well mention.
Even after the rsync transfer finished (did it finish?), the directories still have the wrong modified time? What about the files inside the directories?
Good question…
As I stated in the beginning, I never actually let it run all the way, so I don’t actually know if it’d get override when all tasks is done. (ChatGPT said it wouldn’t, but you know LLM.)
By the time I pull the plug, it hadn’t transfer a single actual file yet…Now I’m pretty sure it’s because the compressed was checked, and both NAS has really bad CPU.
Anyway, I checked all the options besides Compress now, and I’m just letting it run and see what happens. If it still fails, whatever, I’ll just accept the overrided metadata at that point.
Recently, I’ve managed to transfer some TBs of data from my old NAS to my shiny new truenas. Modified date preserved. The creation date didn’t (which drove windows backup & restore a bit crazy but nothing critical).
My course of action was:
- Create an SMB share on truenas.
- Ssh to my old nas.
- Mount truenas’s share on my old nas.
cporrsyncdesired directories to the mounted share. Either option preserved the modification date.
Some notable extras:
- Disabling the forcing of smb encryption speeds up things a tad (old NAS’ cpu is 9 years old).
- Mount the smb share command:
mount -t cifs -o user=<user-for-old-nas>,domain=<my-ad-domain> //<truenas-netbios-or-ip>/<share-name> /mnt/<some-name>. Do not forget tomkdir /mnt/<some-name>. - rsync command:
nohup rsync -aP -update --timeout=60 --log-file=./rsync.log <dir-i-want-to-transfer>/ /mnt/<some-name> &. You can validate the transferred files list beforehand by runningrsync -anv -update <dir-i-want-to-transfer>/ /mnt/<some-name> > dryrun.log. - Unmount smb share:
umount -a -t cifs -l - Speed was ~300Mbps over 1GbE. My old NAS has 2 ports, so mounting two shares with different IPs brought the combined speed to ~500Mbps. Perhaps multichannel would do, but I don’t bother (yet). Mb those pathetic speeds are caused by severe fragmentation of old nas raid.
- That was the first time in my life I’ve used rsync. Double-check provided commands before running.
Not sure if this helps or not.
Beyond the incorrect timestamps, something else is not right.
Perhaps you might want to try over SSH instead. By all means, it shouldn’t stall without transferring a single file, let alone with the wrong modification times.
I thought that they removed all Auxiliary Parameters by the time of 24.10’s release.
I should’ve clarified, it’s not that no file was transferred, but no file was available for SMB share to see aside from directories.
Checking the pool status, it clearly has a lot of data. I believe it’s just the data chunk hasn’t been labelled with where the files are.
What if you SSH into the TrueNAS server and use the ls -l command to check the filenames and timestamps?
Okay, the transfer is now done, annnnnnnd the directories modified date are all correct.
So…it WAS just the initial creation of the directories having the different metadata that’d eventually get overridden. I only got freaked out because the “Compress” option made the transfer that much longer, if I had let it be, I’d probably still be fine once it’s done.
Now, since I redid the transfer, changed the pool setting and changed rsync option, I can’t say for sure that’s the case, but given the identical behaviour between the last and the first pull, it’s pretty likely the case.
Moral of the story: Use small files to do test runs.