249

I'm getting a confusing error from rsync and the initial things I'm finding from web searches (as well as all the usual chmod'ing) are not solving it:

rsync: failed to set times on "/foo/bar": Operation not permitted (1)
rsync error: some files could not be transferred (code 23) 
  at /SourceCache/rsync/rsync-35.2/rsync/main.c(992) [sender=2.6.9]

It seems to be working despite that error, but it would be nice to get rid of that.

lindhe
  • 806
  • 2
  • 14
  • 32
dreeves
  • 26,430
  • 45
  • 154
  • 229
  • no, just a normal directory as far as i can tell. – dreeves Mar 20 '09 at 21:07
  • Just encountered a similar problem, although my error code was 22: rsync: failed to set times on ... Invalid argument (22). After some checking it turns out my files were dated as last modified in 1956! Solution: touch all files, problem solved. :) "find . -print0 | xargs -0 touch" – KIAaze Aug 10 '12 at 18:17
  • I find that if you have also set up a cron job to the same destination, this error wil show up. Changing the time for the cron job(crontab) will help go around it. In my case, I only get this error if I do a manual rysnc if I have also set up a cron job. – NelsonGon Sep 23 '19 at 03:56

12 Answers12

335

If /foo/bar is on NFS (or possibly some FUSE filesystem), that might be the problem.

Either way, adding -O / --omit-dir-times to your command line will avoid it trying to set modification times on directories.

Mathias Bynens
  • 144,855
  • 52
  • 216
  • 248
Jon Bright
  • 13,388
  • 3
  • 31
  • 46
  • This answered helped me to sync between my mac and network storage. Thank you. – cocoafan Aug 19 '10 at 08:39
  • 9
    Funny thing is I'm syncing ext3 to ext3 both OSes are linux. I've never had to use this switch before. -O did the trick, but I wish I didn't have to use it. – d-_-b Dec 14 '10 at 08:48
  • 4
    Thanks! It turns out some VPS hosts (e.g. xlshosting.nl) use this internally, which can give problems with rsync. – Frederik Jan 17 '12 at 10:02
  • 2
    I've the same problem rsyncing from Linux ext4 to Linux ext4: a "cannot set times: operation not permitted" for *symlinks*, not directories. `-O` doesn't help, obviously. This didn't used to happen when my backup partition was ext3 instead of ext4. – Marius Gedminas Dec 12 '12 at 06:30
  • @paleywiener, that sounds like a different problem to the original question. You should probably pose your own question (and it should probably be on superuser.com) – Jon Bright Dec 19 '13 at 22:07
  • I have the same error message and I use LVM(not NFS) - is this related? Or should I seek for other causes to this error message? – user1876484 Dec 18 '14 at 10:37
  • 26
    I was using rsync -avc, and adding -O was not helping. I then read that -a was the equiv to -rlptgoD which includes -t which I guess is overriding -O. So for me the fix was to use -rlpgoDvc – dlink Sep 21 '16 at 20:17
  • @dlink Did you add -O before -avc or after -avc, I think there are different. – Yggdroot Feb 01 '18 at 08:38
  • 15
    @dlink you can add `--no-t` to remove the implied option. – Noam Nelke Dec 17 '18 at 11:29
  • 2
    @dlink: `-t` is for `preserve modification time` and `-O` is for "omit directories from `-t`" . If you're not using `-t`, you might as well drop the `-O`. – Sindarus Aug 05 '19 at 16:58
101

The issue is probably due to /foo/bar not being owned by the writing process on a remote darwin (OS X) system. A solution to the issue is to set adequate owner on the remote site.

Since this answer has been voted, and therefore has been hopefully useful to someone, I'm extending it to make it clearer.

The reason why this happens is that rsync is probably trying to set an arbitrary modification time (mtime) when copying files.

In order to do this darwin's system utime() function requires that the writing process effective uid is either the same as the file uid or super user's one, see opengroup utime's page. Check this discussion on rsync mailing list as reference.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
anddam
  • 1,322
  • 1
  • 12
  • 12
  • 11
    Same on Linux (Debian Squeeze in my case)... If I'm not the owner of the target directory, rsync gives the "failed to set times" error message. (Having write permission on the directory is not enough.) – ddekany Aug 03 '12 at 10:37
  • 1
    I trapped in same issue. Until mount NTFS with uid=user. – gavenkoa Oct 05 '12 at 22:08
  • 3
    This error went away for me when I changed the owner of the directory I was trying to affect (on the remote server) using the rsync command to the same user as the one trying to log in via rsync on my local Bash script. In other words: I was trying to write to `/remote/path/to/foo/bar` on the remote server with this command: `rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar ` and got the same error messages which went away when I made `user1` the owner of `/remoe/path/to/foo/bar` like this: `$ chown -R user1 /remote/path/to/foo/bar` – racl101 Jun 28 '15 at 02:15
  • 3
    If you share your files with other users in a group, for example you use the sticky bit then changing owner isn't really the solution. We don't use -t and add -O to prevent this warning. – R. van Twisk Jun 29 '15 at 13:56
  • Thank you for supplying an answer that isn't a work around like so many other posts are... :) – xpros Mar 10 '16 at 18:57
  • You're welcome, it happened to me and I was interested in understanding the reason why along with fixing the issue. That's why I proposed "a solution" rather than "the solution", there are many different setups and various means to avoid the error, as you can see from other answers and comments. – anddam Mar 13 '16 at 16:19
  • An alternative way of dealing with this is with `rsync -a --no-t ...` which disables setting modification times. That potentially slows down the rsync, though (but necessary for me because I need to control access to the target tree via group permissions). Also: FreeBSD 11.x is another OS which has these careful `utime` semantics. – Norman Gray Sep 26 '17 at 20:01
  • 1
    Can you expand the answer to elaborate on if a user is part of a group that owns the file/dir if that should OR should not work? – Elijah Lynn Aug 21 '19 at 22:43
  • @ElijahLynn I agree that the man page is not clear. To me "process has appropriate privileges" should include group `rw` permissions, but apparently not: «Changing timestamps is permitted when: either the process has appropriate privileges, or the effective user ID equals the user ID of the file, or times is NULL and the process has write permission for the file.» – Alexis Wilke Jan 17 '20 at 19:45
10

As @racl101 has commented on an answer, this problem might be related to the folder owner. The rsync command should be done by the same user as the folder owner's one. If it's not the same, you can change it.

chown -R userCorrect /remote/path/to/foo/bar
Lud Akell
  • 151
  • 1
  • 3
6

I had the same problem. For me the solution is to delete the remote file and let rsync create again.

shintaroid
  • 1,556
  • 3
  • 20
  • 34
3

The problem in my case was that the "receiver mountpoint" was incorrectly mounted. It was in read-only mode (for some extrange reason). It looked like rsync was copying the files, but it was not. I checked my fstab file and changed mount options to default, re-mount file system and execute rsync again. All fine then.

ripah
  • 31
  • 1
2

I've seen that problem when I'm writing to a filesystem which doesn't (properly) handle times -- I think SMB shares or FAT or something.

What is your target filesystem?

David Wolever
  • 148,955
  • 89
  • 346
  • 502
  • I'm on a mac, rsync'ing to linux (a slicehost machine). – dreeves Mar 20 '09 at 21:20
  • Ah, strange... Since you're using rsync on the mac, though, I should warn you: it doesn't properly preserve all OS X file attributes, so Bad Things could happen. See, eg: http://blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful/ – David Wolever Mar 21 '09 at 01:14
  • You can, however, use the most recent version from MacPorts (`sudo port install rsync`) and it will break less. To check it: `rsync --version`: rsync version 3.0.5 protocol version 30 ... append, ACLs, xattrs, iconv, symtimes, file-flags ... (ACLs and xattrs are the important ones) – David Wolever Mar 21 '09 at 01:16
  • The Apple-provided rsync (at least on 10.5 and 10.6) has an `--extended-attributes` option that copies file attributes across. – mjs Nov 13 '09 at 23:32
  • 1
    rsync on Macintosh does indeed set all file attributes and has done so for quite some time, please note the URL referencing "Bad Things could happen" is dated 2006! – tgunr Jul 09 '13 at 07:52
  • 2
    Answers really shouldn't include questions. This would be more appropriate as a comment. – Engineer2021 Dec 03 '13 at 16:44
1

This happened to me on a partition of type xfs (rw,relatime,seclabel,attr2,inode64,noquota), where the directories where owned by another user in a group we were both members of. The group membership was already established before login, and the whole directory structure was group-writeable. I had manually run sudo chown -R otheruser.group directory and sudo chmod -R g+rw directory to confirm this.

I still have no idea why it didn't work originally, but taking ownership with sudo chown -R myuser.group directory fixed it. Perhaps SELinux-related?

Sam Brightman
  • 2,831
  • 4
  • 36
  • 38
  • The man page says the the UID of the app. has to match the UID of the file for `utime()` to work. You can also run as root and do it. But if the UID of the file is different they don't let you change the time to anything else than "now". – Alexis Wilke Jan 17 '20 at 19:49
  • Can you link to such a man page? None of mine mention `utime()`. – Sam Brightman Jan 18 '20 at 20:20
  • 2
    https://linux.die.net/man/2/utime The pertinent paragraph: _"Changing timestamps is permitted when: either the process has appropriate privileges, or the effective user ID equals the user ID of the file, or times is NULL and the process has write permission for the file."_ – Alexis Wilke Jan 18 '20 at 20:41
1

I came across this problem as well and the issue I was having was a permissions issue with the root folder that contained the files I was trying to send over. I don't care about that root folder being included with rsync I just care what's in it. The error was coming from my command where I need to specify an additional / at the end. If you do not have that trailing slash rsync will attempt to set times the folder.

Example:

This will attempt to set times on html

rsync /var/www/html/ ubuntu@xxx.xxx.xxx.xxx:html

This will not

rsync /var/www/html/ ubuntu@xxx.xxx.xxx.xxx:html/
Cesar Bielich
  • 4,754
  • 9
  • 39
  • 81
0

This error might also pop-up if you run the rsync process for files that are not recently modified in the source or destination...because it cant set the time for the recently modified files.

Gurdeep Singh
  • 69
  • 1
  • 1
0

I ran into this error trying to fix timestamps on a new MacOS Monterey, after the Migration Assistant decided to set all of them to the time the copy operation occurred, instead of the original file's.

anddam's answer did not help me, as the remote user used in the rsync command did match the directories and files owner.

After further research, I realised that I had no access to the Mac's Documents directory over SSH (error ls: Documents: Operation not permitted).

I managed to fix the problem by opening System Preferences on the Mac, then selecting Security & Privacy, go to Privacy tab select Full Disk Access and check the box next to sshd-keygen-wrapper.

dregad
  • 1,150
  • 8
  • 21
0

File path: Pods -> Targets Support Files -> Pods-<PROJECT_NAME> -> Pods-<PROJECT_NAME>-frameworks

Replace the below line:

source="$(readlink "${source}")"

to

source="$(readlink -f "${source}")"

Note: If not able to find the file then do Xcode Search "source="$(readlink "${source}")""

Shelly Pritchard
  • 10,777
  • 4
  • 18
  • 17
-1

It could be that you don't have privileges to some of the files. From an administrator account, try "sudo rsync -av " Alternately, enable the root account and sign in as root. That should allow you to completely hose your system and brute force your rsync! ;-) I'm not sure if the above mentioned --extended-attributes will help, but I threw it in too, just for good measure.

captain
  • 15
  • 1