When SCP'ing to my Fedora server, a user keeps getting errors about not being able to modify file timestamps ("set time: operation not permitted"). The user is not the owner of the file, but we cannot chown files to this user for security reasons. The user can sudo, but since this is happening via an SCP/FTP client, there's no way to do that either. And finally, we don't want to have to give this user root access, just to allow him to use a synchronization like rsync or WinSCP that needs to set timestamps.

The user is part of a group with full rw permissions on all relevant files and dirs. Any thoughts on how to grant user permission to touch -t these specific files without chowning them to him?

Further Info This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM). I'm trying to work with Eclipse or NetBeans to work on a local copy of the PHP-based (WordPress) site, while allowing the user to "instantly" preview his changes on the development server. The user will be working remotely. So far, all attempts at automatic synchronization have failed - even using WinSCP in "watch folder" mode, where it monitors a local folder and attempts to upload any changes up to the remote directory error out because it always tries to set the date/timestamp.

The user does have sudo access, but I have been told that it's really not a good idea to work under 'root', so I have been unwilling to just log in as root to do this work. Besides, it ought not to be necessary. I would want some other, non-superuser to be able to do the same thing - using their account information, establish an FTP connection and be able to work remotely via sync. So the solution needs to work for someone without root access.

What staggers me is how much difficulty I'm having. All these softwares (NetBeans, Eclipse, WinSCP) are designed to allow synchronization, and they all try to write the timestamp. So it must be possible. WinSCP has the option to turn off "set timestamp", but this option becomes unavailable (always "on") when you select monitor/synchronize folder. So it's got to be something that is fairly standard.

Given that I'm a complete idiot when it comes to Linux, and I'm the dev "server admin" I can only assume it's something idiotic that I'm doing or that I have (mis)configured.

Summary In a nutshell, I want any users that have group r/w access to a directory, to be able to change the timestamp on files in that directory via SCP.

  • 1
    Is your file system mounted with something funny? Are you using ACL's? Normally this would be possible with group membership. – Caleb Jun 14 '11 at 21:16
  • 4
    Basically your system is telling you, "You can't touch -t[his]." – boehj Jun 14 '11 at 23:38
  • @Caleb: No, you can only set to the current date unless you're the owner. @Tom: Is it important that the date be respected? Could you expand a bit on the requirements: if the user can write to the file, why does it matter if he might own them? Usually, in these situations, whoever last wrote to the file owns it. – Gilles Jun 15 '11 at 8:49
  • @Tom: There's an apparent contradiction between “we don't want to have to give this user root access” and “The user can sudo”, could you explain this part better? Regarding your use of the root group: the root group has no special permissions, only the root user does. – Gilles Jun 15 '11 at 9:36
  • 2
    @Tom: ACL = access control list – Gilles Jun 15 '11 at 15:34

Why it doesn't work

When you attempt to change the modification time of a file with touch, or more generally with the underlying system call utime, there are two cases.

  • You are attempting to set the file's modification time to a specific time. This requires that you are the owner of the file. (Technically speaking, the process's effective user ID must be the owner of the file.²)
  • You are attempting to set the file's modification time to the current time. This works if and only if you have permission to write to the file. The reason for this exception is that you could achieve the same effect anyway by overwriting an existing byte of the file with the same value¹.

Why this typically doesn't matter

  • When you copy files with ftp, scp, rsync, etc., the copy creates a new file that's owned by whoever did the copy. So the copier has the permission to set the file's times.
  • With rsync, you won't be able to set the time of existing directories: they'll be set to the time when a file was last synchronized in them. In most cases, this doesn't matter. You can tell rsync not to bother with directory times by passing --omit-dir-times (-O).
  • With version control systems, revision dates are stored inside files; the metadata on the files is mostly irrelevant.


This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM).

Ok, stop right there. Just because there's a single developer doesn't mean you shouldn't use SCM. You should be using SCM. Have the developer check in a file, and give him a way to press a “deploy” button to check out the files from SCM into the live directory.

There is absolutely no technical reason why you shouldn't be using SCM, but there may be a human reason. If the person working on these files styles himself “developer”, he should be using SCM. But if this is a non-technical person pushing documents in, SCM might be too complicated. So go on pushing the files over FTP or SSH. There are three ways this can work.

  • Do you really need to synchronize times? As indicated above, rsync has an option to not synchronize times. Scp doesn't unless you tell it to. I don't know WinSCP but it probably can too.
  • Continue doing what you're doing, just ignore messages about times. The files are still being copied. This isn't a good option, because ignoring errors is always risky. But it is technically possible.
  • If you need flexibility in populating the files owned by the apache user, then the usual approach would be to allow the user SSH access as apache. The easy approach is to have the user create an SSH private key and add the corresponding public key to ~apache/.ssh/authorized_keys. This means the user will be able to run arbitrary commands as the apache user. Since you're ok with giving the user sudo rights anyway, it doesn't matter in your case. It's possible, but not so easy, to put more restrictions (you need a separate user database entry with a different name, the same user ID, a restricted shell and a chroot jail; details in a separate question, though this may already be covered on this site or on Server Fault).

¹ Or, for an empty file, write a byte and then truncate.
² Barring additional complications, but none that I know of applies here.

  • Thanks Gilles, for the interesting explanation. I'm not sure how much more clear I can be about the use case however. NetBeans continues to throw "can't disconnect" errors whenever I sync (although the file is transferred correctly and verified on the server); WinSCP throws 'set time: operation not permitted' errors; when I untar a file I get warnings about unable to set timestamp to a time in the future. Beyond that I don't know where the issue lies. I simply want to be able to sync a local to a remote dir. via SCP/FTP and the problem seems to be timestamps. Does this help? Probably not. – Tom Auger Jun 15 '11 at 16:49
  • @Tom: I still don't understand why you can't just have the users own the files. – Gilles Jun 15 '11 at 17:14
  • Some of the files need to be owned by Apache (for example, the uploads directory) so I can't have the owner being changed, just because someone is working on some of the files in the directory. What you're saying doesn't make sense - when I over-write a file using FTP, the owner doesn't necessarily change. I don't see the need to alter this behaviour. – Tom Auger Jun 15 '11 at 19:10
  • @Tom: The owner doesn't change only because these are existing files. I don't understand why you don't let users upload files as apache — then they would be able to set times. See my revised answer for the right solution and a couple of suboptimal ones. – Gilles Jun 16 '11 at 7:26
  • Thanks for sticking with this question Gilles. Using SVN or some variant is suboptimal from a development perspective. Anyone that has done web development remotely can tell you that the process is usually micro-incremental - especially when visually styling - so you're doing commits about every 30-60 seconds. If you have to constantly exit your IDE, run a commit, and then preview your browser, you're adding a ton of overhead to what should be a simple process. SVN only makes sense in the context when multiple devs are working on the same part of a site. It's different from programming. – Tom Auger Jun 16 '11 at 13:23

You can setup rsync to use sudo on the remote end like this:

rsync -ave ssh --rsync-path="sudo rsync" /source/ user@host:/dest/
  • What would the sudo rule be? Simply allowing rsync would allow the user to overwrite arbitrary files. It's pretty hard to get argument limitations right, and anyway here I think you'd need to put restrictions on rsync's input, which is technically possible with a wrapper script but not easy. – Gilles Jun 15 '11 at 8:44
  • You are right, allowing sudo rsync is very difficult to restrict. I only suggested it because the OP said the user already had sudo access. – Caleb Jun 15 '11 at 9:29
  • Thanks - this is interesting, although the developer is on a Windows box, so I'm not sure rsync is the best way to go. Again, as I mentioned in the edit to my post, I want this solution to work for any average user, not some priviledged users, beyond someone belonging to the group that owns that particular directory. – Tom Auger Jun 15 '11 at 12:13
  • I think the next thing to look into is setting up ACLs (Access Control Lists), but I have little experience in this area so maybe some guru can add an answer and explain if and how this can be done. – Caleb Jun 15 '11 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.