File Permissions different using FTP over SSH

Hello,

This is my first post in the SmartFTP forums. Hopefully I can help someone else in future, but now I need some help!

I have just recently upgraded to Pro version, due to my server tech recommending that I transfer file using FTP over SSH.

I seem to connect to the server fine, and transferring files is fast and trouble free.

The problem comes when I try to install web applications I get a 500 Internal Server error. When I investigate, all file are given Group Writeable permissions causing the install process to fail.

If I reconfigure the connection to use basic FTP, then files seem to go up ok. with 644 rather than 664.

Is There some settings that I should be looking at?

Thanks in advance for your help.

Lucas

You can get the detailed error message in the http server's error log. Your web hosting provider can help you to find the log file.

If you think it's a permission problem you need to change the file permissions. You can do that using the FTP connection. Right-click on the files or folders you want to change the permission, select Properties from the context menu. Go to the Permissions tab and change the permissions.

Thanks you mb for your quick response.

I am familiar with the change of permissions tab, and used it to help diagnose the problem.

Unfortunately, some of the web apps that I am uploading contain at least a couple of hundred files, so chmodding them individually is not a valid solution.

Is there any overall setting that will change permissions for the uploaded files?

You can use the permissions dialog to change the permissions of all files/folders in a folder recursively.

Thanks mb,

I can change the permissions and everything works well.

However, I would like to try and get to the root of the problem.

I upload everything fine in FTP and all permissions are set without me changing them. As soon as I change the connection type (and the port number) all files get a Group Writeable permission - eg 644 to 664.

Can you think of anything that would cause this? Even though I am an experineced SmartFTP user for basic FTP, I am wading little out of my depth here...

Different servers may have different umasks. E.g. your FTP server (e.g. proftpd) has 644, your SFTP server (openssh) has 664.

Excellent. That has worked.

The server tech said that the umask setting was the problem and it is now uploading correctly.

Thank you very much.

Hello Again,

Though this may be unrelated I am getting an error during transfer.

Connection is fine, upload starts to work, but I am getting an error:

OpenSSL: FATAL
.\fips\fips.c(148): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE

SmartFTP then crashes.

Disable FIPS in SmartFTP and try again.

Still no go.

I presume you mean Settings > Connection > FIPS - System Default Disabled and SSL Disabled.

I thought it was because of the number of workers, but I have cut back to one and it still comes up with the error.

The error window pops up, I hit ok and a C++ Run Time error pops open, then the SmartFTP has stopped working window opens. Start all over again.

Please post the system information from the menu: Help->About "System Information" dialog.

Does this happen on every server?

Regards,
Mat

Hello Again.

I am going to reopen this topic, as I have a very similar problem that fits.

All of a sudden my new cpanel server accounts are uploading files with group permissions.

Older accounts are fine. I haven't changed any default settings, it is just that newer accounts are applying group permissions.

Can I submit you some ftp details and ask you to check if you can upload a file to a working and no working account?

My server tech is stating it is a FTP client issue, and I am three quarters crazy trying to prove otherwise.

If you can see a difference, maybe you can see what settings I have that are causing the permissions to be different.

Talking about permissions - I would like permission to use the software I purchased. SmartFTP licensing scheme is a SCAM. The application auto-updates to the next version. You are licensed for the previous version. They will not make previous version available. You need to buy new version. Sold as "perpetual license" but in effect it is not - you have to pay for every major version.

You are hijacking my thread dougr.

From memory they ask every time you have to do a major upgrade.

Plus I think it is a reasonable assumption that you would have to pay to receive a new version of a professional application. What is it - about 50 bucks?

Lucas

lucas: Are you using FTP or the SFTP protocol to upload the files? For FTP, SmartFTP does not set the permissions when uploading the files so I would think the umask that is configured on the server is applied.

Hello Matt,

Thank you for the reply.

Yes, I am using SFTP, or trying to.

When I upload with FTP, files upload correctly, with default 644 permissions on files.

If I switch to SFTP over SSH, then the same files are given a 664 permission.

So are you saying that SFTP does set permissions? Can I change them?

What SFTP protocol is being used? Can you post the log from the remote browser? Thanks.

Here is the log.

I have xxx'ed out the domain and IP and the name of the account. If you need these details please let me know.


[11:21:33] SmartFTP v4.0.1145.0

[11:21:33] Resolving host name "xxx.com.au"

[11:21:33] Connecting to 115.xxx.xxx.78 Port: 22351

[11:21:33] SSH-2.0-OpenSSH_4.3

[11:21:33] Starting SSH session. Remote Id: "SSH-2.0-OpenSSH_4.3"

[11:21:33] SSH protocol version reply. Client Id: SSH-2.0-SmartFTP

[11:21:33] Key Exchange Algorithm: diffie-hellman-group-exchange-sha1

[11:21:34] Key exchange completed.

[11:21:34] Host Key Algorithm: ssh-rsa

[11:21:34] Client to Server Encryption: aes128-ctr

[11:21:34] Server to Client Encryption: aes128-ctr

[11:21:34] Session MAC: hmac-sha1

[11:21:34] Client to Server Compression: zlib@openssh.com

[11:21:34] Server to Client Compression: zlib@openssh.com

[11:21:34] Requesting service "ssh-userauth".

[11:21:34] RTT: 156.345 ms

[11:21:34] Authentication request. Method: none

[11:21:34] Server supported authentications: publickey,gssapi-with-mic,password

[11:21:34] Authentication request. Method: password

[11:21:34] User authentication successful.

[11:21:34] SSH session established.

[11:21:34] Connected to xxx.com.au.

[11:21:34] Detected Server Software: OpenSSH

[11:21:34] Opening channel 0.

[11:21:34] Channel successfully opened (Local=0, Remote=0).

[11:21:35] SFTP protocol version 3

[11:21:35] Resolving path ".".

[11:21:35] Path successfully resolved to "/home/xxx".

[11:21:46] Getting attributes of "/home/xxx/public_html/wp-app.php".

[11:21:46] 2 No such file

[11:21:46] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.

[11:21:49] Getting attributes of "/home/xxx/public_html/wp-app.php".

[11:21:49] Attributes successfully obtained.

[11:21:58] Getting attributes of "/home/xxx/public_html/wp-app.php".

[11:21:58] Attributes successfully obtained.

The SFTP packet looks like this:

byte SSH_FXP_OPEN
uint32 request-id
string filename [UTF-8]
uint32 desired-access
uint32 flags
ATTRS attrs

The following values are used when a new file is uploaded:
nDesiredAccess = ACE4_WRITE_DATA | ACE4_WRITE_ATTRIBUTES;
nFlags = SSH_FXF_CREATE_TRUNCATE;

And for the attributes (attrs) the only valid attribute we are sending is the type which we set to:
SSH_FILEXFER_TYPE_REGULAR

The permission attribute (in the ATTRS structure) which would be relevant in your case is not set. This means that no permission value is sent to the server and the server uses the configured/default value.

The openssh source shows that it is using 0666 if the permissions attribute is not present:
File: sftp-server.c
mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm : 0666;

Now the openssh's umask (in your case 002) is applied and final permissions will be 0664.

Conclusion:
The openssh server must be started with a different umask (022 instead of 002). If you google for "openssh sftp umask" you will notice that it's a common question from users. There is a patch available for openssh to override the umask this: http://sftpfilecontrol.sourceforge.net/

Regards,
Mat

Hello Matt,

Thank you very much for the detailed response.

My insistence that it is the server techs not me was not going anywhere, but as soon as I forwarded your response, SFTP was working perfectly once more.

Thank you once again for your support. I am a loyal SmartFTP user and will continue to be.

Regards,
Lucas