I wish to backup data mounted on an NTFS partition of a linux machine to the NTFS partition of another linux machine. The local NTFS drive is mounted with all files owned by root.root, but the remote NTFS drive is mounted using plugdev (so file ownership is root.plugdev).

rsync can apparently not copy owner/group and permission info in this situation, so I have been trying to run

sudo rsync -rltDvO --delete /ntfs/src/ [email protected]:/ntfs/dest/

However, every time I run this command, it re-copies ALL the files, rather than just transferring the changed files. I have tried using the --modify-window flag, but that hasn't helped either.

Update: it is not recopying all the files, rather it is recalculating the checksums (or doing some other processing, causing the filename to be printed) for each file. This is opposed to what happens between to e2fs drives, where no filenames are printed if no changes have been made to the source and destination since the last rsync. I am guessing this processing is because the timestamps are not available on NTFS(?)

Next update: Permissions certainly seem to be a part of it: first, also using -u as an rsync flag stopped the processing of all the files on the destination, but this is not what I want. Secondly, if I use an account with root access (and rsync flags -avz) on the remote machine, I can actually change the timestamps on files and directories. However, some files continue to be recopied, and the --modify-window seems to help for that somewhat (but not completely, it seems - I'm still experimenting to find out why.)

  • 1
    Is there a reason you are omitting directory times (-O) ?
    – Paul
    Jul 22, 2011 at 13:07
  • When using -t, rsync generates errors like rsync: failed to set times on "/windows/backups/media/Folder_name": Operation not permitted (1) for each folder. The -O flag prevents rsync trying to set these times. Aug 30, 2011 at 10:01

4 Answers 4


As per my second update, the permissions of my user did not allow me to set times. Running the rsync using the root account on the destination machine, along with --modify-window=5 gave me suitable behaviour. (If you don't have root access on the destination, the -u flag could help, but only if you're sure no-one will change the files on the remote system.)

  • Alternatively, make the current user the owner of the partition so it's not necessary to run as root. askubuntu.com/a/207290
    – user202729
    Aug 14, 2020 at 2:32

Ideally you always want to use robocopy as it handles variations in timestamps (upto 2 seconds for FAT). You can run in inside Wine but connecting to the remote host might be inconvenient.


edit: per Steve's comment, this feature appears to now be in rsync 3.0:


When comparing two timestamps, rsync treats the timestamps as being equal if they differ by no more than the modify-window value. This is normally 0 (for an exact match), but you may find it useful to set this to a larger value in some situations. In particular, when transferring to or from an MS Windows FAT filesystem (which represents times with a 2-second resolution), --modify-window=1 is useful (allowing times to differ by up to 1 second).

  • 2
    rsync does support timestamp variations using the --modify-window flag. Aug 30, 2011 at 10:16

An additional tidbit I've found in cases like this: Standard vs. Daylight time. I had a bunch of files in an rsync start syncing right after time zone change one year. I used --modify-window=3605 and it fixed the problem. The downside is that it would ignore files with a modification date within an hour of each other. In my case the files weren't expected to change except every few days or weeks, so that was fine.


I had the same issue using "rsync -av" between a local ext3 drive and a local NTFS drive on my raspberry pi. I was able to avoid the recopying of the files using the following command (you can leave out the "--delete-during" if you don't need it):

rsync -crv --no-perms --delete-during /path/to/source/* /path/to/destination/

The command using -c is much slower, but it does the trick. Note, that in my case the "/path/to/source/" contains only a set of subdirectories (i.e., no files, just directories); if you're not using the "--delete-during flag", this note will not matter.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .