FileZilla Forums

Hello all,

My non-root Filezilla users are getting errors like this when they SFTP upload a file that already exists on the server *and* they do not own the existing file:

Error: set attrs for /www.example.com/index.html: permission denied

Apparently this error has something to do with the failure to change or set permissions?

If the user actually owns the corresponding server file his upload never displays this error. When he uploads a new file he never sees this error either. So this error seems to occur only when the user does NOT own the server file he is trying to overwrite.

In fact the existing file gets overwritten even though this error appears. However, the original owner of the server file still owns it after it has been overwritten. I suspect that this is why the error is generated: Filezilla tries to reset the owner of the file after it is overwritten, but it fails with the specified error message.

This situation came about because I gave several users SFTP access to a single website's document root folder and its subfolders. They work as a team to maintain the website, but they complain frequently about seeing this error. It would be nice if they never had to see it again!

So ... I am looking for a way to avoid or suppress this particular error message. Can it be suppressed or removed, perhaps by editing a Filezilla configuration file, or some other way?

Or if there's a specific way to reconfigure my Ubuntu Linux 14.04.2 server to prevent this error in the first place, please tell me how -- or point me to a reference that explains how -- because I have yet to find a suitable solution to this problem online, and yes I have Googled it for many hours already, with no luck so far.

*bump* because I'm interested too.

What is the action/command Filezilla is trying to perform after the chmtime? Apparently that next action is the one triggering the "permission denied".

From there, I can look for a solution. My sftp user is in the group of the file being overwritten, the file gets overwritten successfully because it has group write permission, still the red error message of the op appears, so I'm not sure what's going on.

Part of the upload is replicating permissions (the file mode bits), something that can only be changed by the file owner.

Easiest workaround is to ensure that the one uploading is the file owner.

I found a workaround: first delete the file on the server, then upload the new copy.

Apparently group write access allows the member of the group to delete the file. Then new file is uploaded, with a different owner, and FileZilla can set the timestamp. I did need to manually set the group write access on the new file, though.

Newly created files on the server should be assigned either the configured values in the FTP server software, or they inherit owner and UMASK from the directory /parent itself.
*NIX permission in FTP servers is often very limited, as it is not FTP (but custom) functionality.