Files and Folders Uploaded By sFTP Have Incorrect Permissions

[linux4me2]

There is a previous thread regarding a similar issue that is marked "solved," but I'm having problems with this after the supposed update fixed it, so I'm starting my own thread.

The issue is that when I upload folders and files via sFTP the folders are set with the permissions 775 instead of 755, and files intermittently get permissions of 664 instead of 644.

If I create a folder or file with cPanel's File Manager, the permissions are correctly set. If I upload folders and files with regular FTP, the permissions are correct.

The problem with incorrect permissions for folders and files uploaded with sFTP occurs both for sites using suPHP and those using PHP-FPM. As a test, I set all sites to PHP-FPM, uninstalled suPHP using EA4, restarted sshd, and still the problem with the folder and file permissions occurred.

My environment is:

/etc/redhat-release:CentOS release 6.9 (Final)
/usr/local/cpanel/version:11.66.0.18
/var/cpanel/envtype:standard
CPANEL=release

The relevant section of /etc/profile on the server is:

if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 002
else
    umask 022
fi

I am on a Linux box running 4.12.10-1-ARCH, and I have confirmed that the folder and file permissions on my machine are set to 755 and 644, respectively, so it's not the permissions of my source files that is causing the issue.

 

[rpvw]

v66.0.18

I just ran some tests with FileZilla from a CentOS box up to a Cloudlinux server running Pure-FTPD.

The folders were set at 755 and the files in the folders at 644 on the CentOS box before starting the upload, and after upload, I can confirm that the permission on the server are :

Plain FTP:
Uploaded Folders are 755
Uploaded Files are 644

SFTP
Uploaded Folders are 775
Uploaded Files are 664

Hope this helps.

 

[linux4me2]

Yes it does. I'm glad it's not just me. I should have mentioned I, too, am using Filezilla and logging in as the cPanel user in each test I've done.

 

[linux4me2]

Just to eliminate Filezilla as the source of the problem, I used sftp from a Terminal session and created a folder in the /public_html folder on one of my cPanel accounts. It was given incorrect permssions (775) using sFTP directly, as well, so it doesn't appear that the sFTP client is the issue.

 

[rpvw]

I also ran some additional tests using the Files transferred over Shell protocol (FISH) protocol that uses SSH, and the folder and file permissions were not altered during the upload.

SFTP from the Dolphin file manager corrupted the folder upload to 775, but curiously left the file permission at 644
FTP from the Dolphin file manager uploaded both the folder and files to 755 and 644 respectively.

My brain is beginning to hurt............ Whiskey time ?

 

[cPanelMichael]

Hello,

This was recently brought up in a support ticket and the workaround was to update the following entry in the /etc/ssh/sshd_config file:

# override default of no subsystems
Subsystem sftp  /usr/libexec/openssh/sftp-server

To:

# override default of no subsystems
Subsystem sftp  /usr/libexec/openssh/sftp-server -u 0022

Then, restart SSHd to enable the change:

/scripts/restartsrv_sshd

Note that since this behavior stems from the configuration of the OpenSSH package with CentOS as opposed to a cPanel setting, you'd need to open a bug report with CentOS if you want to see a change to the default behavior:

Main - CentOS Bug Tracker

Thank you.

 

[linux4me2]

I followed your instructions for modifying /etc/ssh/sshd_config to the letter, restarted sshd, and tried uploading a test folder to a site using Filezilla while logged in as the cPanel user. It still got 775 permissions, so the workaround didn't fix it.

I also tried signing on as the cPanel user via SSH, cd'd into the public_html folder, and created a directory as follows:

mkdir test_folder

That folder also got 775 permissions, so it does appear to be an issue with OpenSSH.

Did the workaround you suggest work for the person who submitted the support ticket?

 

[cPanelMichael]

Hello,

Yes, the workaround worked in that case. Feel free to open a support ticket using the link in my signature and reference ticket number 8708973 to see if the same workaround can be applied to your system.

Thank you.

 

[linux4me2]

I have to go through my host before I can submit a cPanel support ticket. I'll do that and report back.

 

[linux4me2]

Thanks to some help from my web host, my file permission problem with sFTP seems like it's fixed.

While the workaround above didn't do the trick, I still have that in place, and had to change the umask in both conditions of the conditional statement in the following section of /etc/profile to 022 as noted in the other post about this issue to get things working again:

# By default, we want umask to get set. This sets it for login shell
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 022
else
    umask 022
fi

I would feel a lot better if I knew why this problem started happening all of a sudden, but it does seem to be resolved for now.

 

[weetabix]

# override default of no subsystems
Subsystem sftp  /usr/libexec/openssh/sftp-server -u 0022

If I do this I can't connect to SFTP without adding shell access to the account. If I leave as before, SFTP works as normal even with shell inactivated for the account.

 

[cPanelMichael]

If I do this I can't connect to SFTP without adding shell access to the account. If I leave as before, SFTP works as normal even with shell inactivated for the account.

Those steps are provided as a workaround only. You could try the other workarounds referenced in this thread, however note that this behavior stems from the configuration of the OpenSSH package with CentOS as opposed to a cPanel setting.

Thank you.

 

[abursill]

I just had the same problem in Nov 2019 and the correct answer is on another thread here solved umask 022 answer