Skip to main content

SFTP - Incorrect upload permissions

verdon
When uploading new files and directories to the server, via SFTP logged in as a normal cpanel user, on a brand-new server 'CENTOS 6.8 x86_64 standard WHM 58.0 (build 23)' it seems that default permissions are wrong. The original files/dirs are all 644/755. When I upload with my GUI client (Transmit on Mac) the directories are being made group writeable but the files are ok (644/775), causing problems with suphp of course. Anecdotally, I believe I have a client using WS-FTP Pro on Windows, where files and dirs are being made group writeable (664/775). I need to verify that again. I did some searching and had a look at /etc/bashrc and it looks correct. I sure haven't touched it. # By default, we want umask to get set. This sets it for non-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 ] && [ "`id -gn`" = "`id -un`" ]; then umask 002 else umask 022 fi Any suggestion where else I might look?

Comments

41 comments

Date Votes
  • verdon
    Sorry, I was wrong about that... both clients are uploading files correctly but are both adding the g+w to directories.
    0
  • cPanelMichael
    Sorry, I was wrong about that... both clients are uploading files correctly but are both adding the g+w to directories.

    Hello, Could you verify if you were able to determine if the issue is isolated to specific SFTP clients? If so, does the issue persist when using an alternate SFTP client such as FileZilla? Thank you.
    0
  • verdon
    Could you verify if you were able to determine if the issue is isolated to specific SFTP clients? If so, does the issue persist when using an alternate SFTP client such as FileZilla?

    I can verify that it is happening with Transmit on MacOS (all up to date) and with up to date WS_FTP Pro on Win7, with using SFTP protocol. I'll try FileZilla on Mac shortly and see if I can get someone to try FileZilla on Win for me, and report back asap. Thanks
    0
  • verdon
    I can verify that it is happening with Transmit on MacOS (all up to date) and with up to date WS_FTP Pro on Win7, with using SFTP protocol. I'll try FileZilla on Mac shortly and see if I can get someone to try FileZilla on Win for me, and report back asap.

    It is happening with FileZilla on Mac also... I'm waiting for a Windows tester.
    0
  • cPanelMichael
    Hello, It looks like this is a bug. Here's a quote from case EA-4868 regarding this issue: By default, the umask is set to 002 for any user with a uid greater than 002. This causes issues for users who use the SuPHP handler and use SFTP to upload files/directories since the new files/directories will have 664/775 permissions by default
    I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":
    # 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 ] && [ "`id -gn`" = "`id -un`" ]; then umask 022 else umask 022 fi
    Thank you.
    0
  • verdon
    I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":

    Thanks for this information. I've updated these values in /etc/profile and /etc/bashrc, restarted service sshd and started a new session in my sftp client, but am still getting 644/775 on files/dirs. Note that the files are correct. It's just the dirs. Am I missing anything? Thanks.
    0
  • verdon
    Note that the files are correct. It's just the dirs.

    Oops. I'm still getting inconsistent results on this. I am getting 644/775 when I test. My client is getting 664/775.
    0
  • verdon
    Just a quick update... with the patch above, and after waiting a couple hours, upload permissions are correct with both Mac clients I can test with. I'm waiting for someone else to report on their Window's clients test.
    0
  • verdon
    Tested and verified with a couple Window's clients now, that the work-around is doing the job.
    0
  • cPanelMichael
    Tested and verified with a couple Window's clients now, that the work-around is doing the job.

    I'm happy to see the workaround helped. I'll update this thread again when a resolution is published. Thanks!
    0
  • borayeris
    It happens to me after I upgrade EasyApache4. It has been 3 months and still not fixed. Shame on you cPanel.
    0
  • cPanelMichael
    Hello, There's no new update to report at this time, however this forum thread is linked to the case. I'll update this thread once the case is updated. In the meantime, let us know if you have any trouble with the recommended workaround. Thank you.
    0
  • borayeris
    Hello, It looks like this is a bug. Here's a quote from case EA-4868 regarding this issue: I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":
    # 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 ] && [ "`id -gn`" = "`id -un`" ]; then umask 022 else umask 022 fi
    Thank you.

    This doesn't work. I did sshd restart. Also tried reboot.
    0
  • borayeris
    I found the solution. In this file "/etc/ssh/sshd_config" I find this particular line : Subsystem sftp /usr/libexec/openssh/sftp-server Changed to Subsystem sftp /usr/libexec/openssh/sftp-server -u 022 After sshd restart it worked perfect.
    0
  • cPanelMichael
    Hello @borayeris, I'm happy to see you were able to find a suitable workaround. Thank you for updating this thread with the solution you used.
    0
  • cPanelMichael
    Hello, To update, in testing, we are finding the permissions of the files are matching the permissions assigned on the machine that's completing the upload via SFTP, which suggests it isn't an issue with the . EX: 1. Customer wants to copy 'hello.txt' to the cPanel server via SFTP. 2. hello.txt has permissions 0755 on the customer's machine. 3. After using sftp to copy the file to the cPanel server, the resulting file maintains 0755 permissions. Could anyone experiencing this behavior confirm if it's happening when the permissions are not matching what's configured on the machine uploading the files, and if so, let us know the specific OS and SFTP client used for uploading? Thank you.
    0
  • verdon
    I'm pretty sure I tested that when I made this initial post. I'd have to undo the patch suggested above, and run the tests again. If I get a chance in the next 24 hours I will... sadly, my snowblower will be taking all my attention tonight!
    0
  • cPanelMichael
    I'm pretty sure I tested that when I made this initial post. I'd have to undo the patch suggested above, and run the tests again. If I get a chance in the next 24 hours I will... sadly, my snowblower will be taking all my attention tonight!

    We've completed some additional testing and have now reproduced the issue. No further information is required at this time, but thanks for monitoring the thread! I'll provide more information on the status of this case as it becomes available. Thank you.
    0
  • cPanelMichael
    Hello, To update, an EA4 maintenance update planned for tomorrow includes an update to the mod_suphp package that will address the issue reported on this thread: mod_suphp 0.7.2-17 - EA-4868: Added new allow_file_group_writeable patch
    You can review the full EasyApache 4 change log at:
    0
  • aztest
    I have tried both the steps provided in this forum. But still the files permission is not changing while uploding.
    0
  • cPanelMichael
    I have tried both the steps provided in this forum. But still the files permission is not changing while uploding.

    Could you let us know the specific steps you are taking when reproducing the issue? Also, please post the output from the following command:
    rpm -qa|grep suphp
    Thank you.
    0
  • aztest
    I am just connecting my cpanel account via "SFTP" and uploading the files. The files are uploading on the same permission e.g"664" but not changing to "644". ~~~~~~~~~~~~ rpm -qa|grep suphp ea-apache24-mod_suphp-0.7.2-17.17.12.cpanel.x86_64 ~~~~~~~~~~~~
    0
  • cPanelMichael
    Hello, The resolution from the referenced case should allow suPHP to run when the permissions are set to 0664. If you want to correct the actual permissions that are configured when uploading files via SFTP, you'd need to update the permissions assigned to the file on the server you are copying the files from, as SFTP is simply matching the permissions that are set on the source server. Thank you.
    0
  • chalupa
    I seem to still be having this issue uploading files on a server using Filezilla. I thought that this was fixed with a EA4 update? I see that's just a patch to allow suphp to actually use the files with the improper permissions though. On 2 different servers both running CentOS 7.3 with CloudLinux. I have attempted to upload files that are originally 644 and 664 and without that local masking they upload with the original 644 and 664 respectively but if I have the local mask they upload properly as 644. Also creating dir/file within Filezilla I am able to create with the proper 755/644 w/local mask but is created with 775/664 respectively in filezilla. Why is SFTP honoring the local mask but not the global one in /etc/bashrc? server3 CPANELUSER]# grep umask /etc/bashrc # By default, we want umask to get set. This sets it for non-login shell. umask 022 umask 022 httpd -v Server version: Apache/2.4.25 (cPanel) Server built: Apr 14 2017 12:43:52 uname -a Linux server2.domain.tld 3.10.0-427.36.1.lve1.4.44.el7.x86_64 #1 SMP Sun Apr 2 11:56:48 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux cat /usr/local/cpanel/version 11.64.0.19 cat /etc/redhat-release CloudLinux release 7.3 (Yury Malyshev) rpm -qa|grep suphp ea-apache24-mod_suphp-0.7.2-16.el7.cloudlinux.x86_64 I used the workaround above as umask is supposed to change incoming file as 664 to 644 but is not. Because using Cloud Linux had to update the cage after the workaround in case someone else comes across the same thing. On the local machine -rw-r--r-- 1 chris chris 561 Nov 18 15:37 image00001.png -rw-rw-r-- 1 chris chris 2351 Jan 9 10:05 image007.png After uploading. -rw-r--r-- 1 CPANELUSER CPANELUSER 561 May 9 21:05 image00001.png -rw-r--r-- 1 CPANELUSER CPANELUSER 2351 May 9 21:05 image007.png
    0
  • cPanelMichael
    On 2 different servers both running CentOS 7.3 with CloudLinux.

    There's an open case with CageFS that's discussed on the following post: Incorrect upload File permissions 664 Thank you.
    0
  • WorkinOnIt
    Hi Coming back to this thread as I've just installed a new server and this issue has come back again. CENTOS 7.3 x86_64 using EA4 and suphp. I have checked etc/profile and the umask settings in there are incorrect
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then umask 002 else umask 022 fi
    I have updated them to;
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then umask 022 else umask 022 fi
    and restarted ssh but the same issue occurs - uploaded files are given 0664 in stead of 0644
    0
  • cPanelMichael
    uploaded files are given 0664 in stead of 0644

    Could you confirm how the files are uploaded? Thank you.
    0
  • rudtek
    Hi Coming back to this thread as I've just installed a new server and this issue has come back again. CENTOS 7.3 x86_64 using EA4 and suphp. I have checked etc/profile and the umask settings in there are incorrect
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then umask 002 else umask 022 fi
    I have updated them to;
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then umask 022 else umask 022 fi
    and restarted ssh but the same issue occurs - uploaded files are given 0664 in stead of 0644

    This is exactly what i did, but also in etc/bashc. It then worked fine. I was even having the problem without an ftp. For instance if i used the command wp core download. all files would be 664. After changing 002 to 022 in both these files, i was able to upload through ftp and through wp cli correctly.
    0
  • WorkinOnIt
    @rudtek thank you for the contribution to this thread. Just to clarify - the files to update are: etc/profile etc/bashrc (there was a type in what you wrote above). After making the changes from 002 -> 022 re-uploading the file and then restarting SSH it works great! Now all folders upload as 0755 and files as 0644 when using e.g. filezilla The question is - will these files change back at some point after an update?
    0
  • WorkinOnIt
    Just to add to the above @cPanelMichael - I am using Filezilla from a Windows 7 machine. I get the same result when using Filezilla from a Mac also. I would have thought the uploaded file / folder permissions should be set by the server, not the originating machine. However, modifying both the etc/profile & etc/bashrc files seems to have resolved the issue for now.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post