rsync error: failed to set times on "/foo/bar": Operation not permitted

rsync file-transfer

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.

no, just a normal directory as far as i can tell.

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"

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.

Mathias Bynens

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.

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.

Thanks! It turns out some VPS hosts (e.g. xlshosting.nl) use this internally, which can give problems with rsync.

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.

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 you can add --no-t to remove the implied option.

Alexis Wilke

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.

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.)

I trapped in same issue. Until mount NTFS with uid=user.

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

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.

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?

Lud Akell

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

ripah

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.

shintaroid

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

David Wolever

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?

I'm on a mac, rsync'ing to linux (a slicehost machine).

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: blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful

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)

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!

Answers really shouldn't include questions. This would be more appropriate as a comment.

Sam Brightman

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?

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".

Can you link to such a man page? None of mine mention utime().

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."

Gurdeep Singh

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.

Cesar Bielich

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/

captain

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.

Follow WeChat

Success story sharing

Want to stay one step ahead of the latest teleworks?

Subscribe Now

rsync error: failed to set times on "/foo/bar": Operation not permitted

Follow WeChat

Want to stay one step ahead of the latest teleworks?

Platform

Support

Links

Contact US