I have an rsync service that syncs files from remote machine to a machine that drops them on a network drive.

I need the copied files to take on the native permissions of the destination folder.

The sync process runs fine, but after it is finished, I cannot access some of the folders -- Permission Denied.

I am logged in as domain admin; it won't allow me to modify any permissions on said folders, either. What gives?

run command:

rsync.exe  -v -rlt -z --delete "src_path" "dst_path"
  • what command are you currently using to sync?
    – user1931
    Nov 12, 2009 at 17:10

8 Answers 8


(from http://www.samba.org/ftp/rsync/rsync.html)

In summary: to give destination files (both old and new) the source permissions, use --perms.

To give new files the destination-default permissions (while leaving existing files unchanged), make sure that the --perms option is off and use --chmod=ugo=rwX (which ensures that all non-masked bits get enabled).

If you'd care to make this latter behavior easier to type, you could define a popt alias for it, such as putting this line in the file ~/.popt (the following defines the -Z option, and includes --no-g to use the default group of the destination dir):

    rsync alias -Z --no-p --no-g --chmod=ugo=rwX
  • thx a lot. I couldn't remember the right flags to use ... Jan 5, 2010 at 18:31
  • 5
    This is relevant to rsync on Linux, but does not always resolve the issue when rsync'ing to a Windows drive, which is what the original post is asking.
    – Simon E.
    May 29, 2017 at 4:14
  • 1
    Just to extend this quite old answer, it may help people. I use Windows 10 as main OS, and installed a Kali Linux under the WSL (Windows Subsystem for Linux), because we are using some Linux tools. By default, with the same script as some Linux users colleagues, rsync worked but permissions and group were overriden each time : rsync -az -e 'ssh' --progress --delete --perms --chmod=u=rwx,g=rwx,o=,Dg+s ./source /dest. Just removing --perms and adding --chown=username:group, let us to force the user:group mapping when file are copied on the server.
    – Alex
    Jan 27, 2020 at 8:58

Cygwin's "posix" security has caused me lots of problems with Windows NTFS file permissions - even using --no-perms with rsync.

I found that newly-created files/folders don't properly inherit default permissions, but every file/folder ends up with lots of <not inherited> entries in the Windows file/folder Advnanced security tab. (And this problem is not just rsync-related).

I found this related post and this link both very helpful in how to resolve these problems using the noacl option in cygwin's /etc/fstab file. The downside of this solution is that cygwin loses the ability to set file/folder permissions, but in many cases this is not important.

(Googling this topic you'll probably find references to setting the CYGWIN=NONTSEC environment variable, but this is for cygwin v1.5 and doesn't work in cygwin v1.7 onwards.)

  • Editing the /etc/fstab file fixed it for me. I had to use rsync within cygwin instead of another deployment such as DeltaCopy to do this. Jan 21, 2013 at 2:27
  • 1
    If you're just using the cwrsync package (and not cygwin) where do you put the fstab file?
    – Simon E.
    May 29, 2017 at 4:15
  • I do not use cygwin. I take a regular NTFS drive, mounted on OS X, and rsync files to it. Then, these files within Windows have completely screwed up permissions. Looking for a solution.
    – Steven Lu
    Dec 12, 2017 at 21:19
  • looks like i have been using the "risky" method of mounting NTFS on macOS using the built-in driver, which is supposed to be much less stable than paragon/tuxera and FUSE drivers. So keep that in mind if you're in the same boat
    – Steven Lu
    Dec 12, 2017 at 21:30
  • Warning: Don't use the noacl fstab option for Cygwin! I used it before, and very later found that Cygwin's find & grep commands is many times (I think at least 4x) slower with noacl! Use the --chmod=ug=rw,o=r,Da+x solution instead, like Wernight mentioned. Feb 7, 2020 at 8:46

On Windows with DeltaCopy I could make it work with:

rsync --perms --chmod=a=rw,Da+x ...

It worked even with --recursive

  • This mostly worked, however, I had to change the --chmod option to include a=rwx so that batch files, etc. would properly execute. Oct 3, 2012 at 18:38
  • 1
    This is the only option that worked for me. Tried the --no-perms suggested above and the fstab to no avail. This one gave me only some <not inherited> permissions, which were kind of the permissions I wanted and included no Deny permission for the executing user. Thanks! Oct 17, 2012 at 10:23
  • DeltaCopy also contains a chmod executable that can fix the permissions afterwards, e.g. chmod -R 777 /cygdrive/g
    – jnnnnn
    Nov 13, 2012 at 0:25
  • 1
    --perms is what was missing for me, to solve the copy as readonly issue. Aug 16, 2018 at 13:21

In the past I have just re-assigned the permissions in Windows to my current user afterwards using takeown at an elevated command prompt as:

takeown /f <NameOfFolder> /r /d Y

Of course, if you used the correct rsync flags in the first place then this is unnecessary but if you didn't want to rerun rsync for files you have already copied then I would recommend this.

  • 1
    Welcome to Super User! Please read the question again carefully. Your answer does not answer the original question.
    – DavidPostill
    Dec 21, 2016 at 13:22
  • 1
    Given that the question is "what gives?" I would say its answer is not even a solution but an explanation so most of the answer on here don't answer the question. This is a still a useful and contextually appropriate addition to the issue but I can move it to a comment if more appropriate. Dec 21, 2016 at 16:40
  • Oh wait, I can't add comments because I don't have a reputation of 50+ so this will have to stay here. Dec 21, 2016 at 16:42
  • correct rsync flags > and what would those be?
    – oldmud0
    Dec 27, 2016 at 5:54
  • @oldmud0 see the answers that preceded mine for appropriate combinations of flags which set the permissions during the copy. My solution is ideally suited for those who have already copied the files and didn't want to delete them an copy them again to ensure the permissions are correct. Dec 29, 2016 at 10:38

rsync, at least on Cygwin has the following switch:

-A, --acls preserve ACLs (implies --perms)

My Cygwin version is:

CYGWIN_NT-6.3 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin

Hope this helps!

  • 1
    Welcome to Super User!  Whilst this may theoretically answer the question, for the sake of improvement it would be preferable to include details of how this answers the question (citing a source to back up your claim is a plus). Apr 26, 2015 at 1:28
  • When I try --acls with cwrsync (which AFAIK is just a standalone build of rsync for cygwin), it says rsync: ACLs are not supported on this client. Jan 9, 2023 at 15:43

The top rated answer only works if you're using rsync over ssh into windows. If you're using the cygwin rsync daemon just using noacl in /etc/fstab doesn't help, for whatever reason it doesn't honor inheritance even if you get rid of user and try noacl,override, etc. This seems to happen if you're rsyncing into a top level drive and use path = /cygdrive/whatever in /etc/rsyncd.conf. Instead, you need to make a separate mount point in /etc/fstab and use that in your rsyncd.conf instead :

D:\     /d_drive  ntfs    binary,posix=0,noacl,user,override      0 0

in /etc/rsyncd.conf, you'd have something like this :

use chroot = yes

path = /d_drive
comment = d_drive
auth users = someUser
secrets file = /etc/rsyncd.secrets
read only = false
write only = false
list = false
uid = someUser

Then I had to reboot the windows system, just restarting the rsync service alone didn't seem to help, it kept throwing chroot and chdir errors (even though /d_drive was mounted and use chroot = false and I could write to it). Then when you rsync into the windows system use :

cd /local/path/to/copy
rsync -rltD --no-p --no-g --no-o  ./ rsync://someUser@localhost:remotePort/d_drive/

Tried a few of the solutions above and none worked. Finally solved it with wsl:

wsl rsync -avz ... --exclude='\*/'

Now I can freely use -a without worrying the directory is messed up. Note that you need to escape '*' in filter patterns.


I had this problem with rsnapshot, which uses rsync for backup. I overrided it removing --relative from rsync_long_args. After that folder c for disk itself with weird permissions does not creates.

You must log in to answer this question.

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