Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Files and Folders Uploaded By sFTP Have Incorrect Permissions

Discussion in 'EasyApache' started by linux4me2, Sep 8, 2017.

Tags:
  1. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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:
    Code:
    /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:
    Code:
    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.
     
  2. rpvw

    rpvw Well-Known Member

    Joined:
    Jul 18, 2013
    Messages:
    301
    Likes Received:
    88
    Trophy Points:
    28
    Location:
    Spain
    cPanel Access Level:
    Root Administrator
    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.
     
    #2 rpvw, Sep 8, 2017
    Last edited: Sep 8, 2017
  3. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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.
     
  4. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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.
     
  5. rpvw

    rpvw Well-Known Member

    Joined:
    Jul 18, 2013
    Messages:
    301
    Likes Received:
    88
    Trophy Points:
    28
    Location:
    Spain
    cPanel Access Level:
    Root Administrator
    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 ?
     
    #5 rpvw, Sep 8, 2017
    Last edited: Sep 8, 2017
  6. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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:

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

    Code:
    # override default of no subsystems
    Subsystem sftp  /usr/libexec/openssh/sftp-server -u 0022
    
    Then, restart SSHd to enable the change:

    Code:
    /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.
     
  7. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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:
    Code:
    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?
     
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
  9. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    I have to go through my host before I can submit a cPanel support ticket. I'll do that and report back.
     
  10. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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:
    Code:
    # 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.
     
Loading...

Share This Page