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.

Incorrect upload File permissions 664

Discussion in 'General Discussion' started by WorkinOnIt, May 1, 2017.

Tags:
  1. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    I am starting a new thread as the previous one I started here has a solved tag (which is right, because it was for the opposite issue!)

    When using SFTP on a newly created user account, files are being uploaded with incorrect permissions. Files are being uploaded with 664 permission - which results in a 500 internal server error on front end. Folders are correct at 755.

    I am using FileZilla and I am uploading using the username and password for the account (not as root) and it is a newly created account. Therefore, I don't think FileZilla has anything that can be modified to affect uploaded files..... I believe it is a server config issue. Server is running;

    CLOUDLINUX 6.9 x86_64 kvm – cPanel & WHM 64.0 (build 18) and EA4.

    mod_mpm_prefork
    mod_suphp

    kernal:
    Linux myhostname.com 2.6.32-673.26.1.lve1.4.25.el6.x86_64 #1 SMP Wed Apr 5 16:33:01 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux


    Why would files be getting uploaded via SFTP as 664 ?

    Sure I can change them back using chmod - but that is a pain. When I do CHMOD the files back to 644, the 500 internal error is gone.

    How can I check in WHM / change in WHM the default file permission behaviour? Or is that something that needs to be changed via SSH - I have root access.

    Thank you for advice.
     
  2. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    15,745
    Likes Received:
    310
    Trophy Points:
    433
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
  3. ruzbehraja

    ruzbehraja Well-Known Member

    Joined:
    May 19, 2011
    Messages:
    392
    Likes Received:
    11
    Trophy Points:
    68
    cPanel Access Level:
    Root Administrator
  4. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    I tried this solution first - it didn't work: After restart sshd and attempting sftp upload, I receive the following error upon connection attempt:

    Error: Received unexpected end-of-file from SFTP server
    Error: Could not connect to server

    I'm going to try the other mention profile change.
     
  5. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator

    Hi, I have tried this method and so far it does not seem to have worked. I have restarted ssh, I have not restarted the server - there's not a clear instruction if server needs a restart once profile has been updated.

    Any other tips to try?


    suphp.conf
    ;Umask to set, specify in octal notation
    umask=0022
     
  6. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    Output as requested above;

    [root@server ~]# rpm -qa|grep suphp
    ea-apache24-mod_suphp-0.7.2-16.el6.cloudlinux.x86_64

    Steps to reproduce: using filezilla - files get uploaded with 664 and folders with (correctly) 755
     
  7. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    Thank you - I have followed the steps in the thread mentioned by @Infopro by neither suggestion appears to have worked for me.

    SOLVED - SFTP - Incorrect upload permissions

    @ruzbehraja I checked in var/cpanel/conf and I don't have any ProFTPD file. I Do have Pureftpd main conf file and in there, umask setting is:

    Umask: 133:022
     
    #7 WorkinOnIt, May 3, 2017
    Last edited: May 3, 2017
  8. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    15,745
    Likes Received:
    310
    Trophy Points:
    433
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Posts you made in the other thread, moved here. Please don't cross post to multiple threads.
     
  9. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    15,745
    Likes Received:
    310
    Trophy Points:
    433
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Is this correct or a typo?

    It's not supposed to be, 0022, it's 022
     
  10. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    I also logged into cpanel user account and installed software using the "Site Software" installer and installed WordPress.

    Upon checking the file permissions, all folders and files are 755. I've corrected this manually, but clearly something is wrong with global settings.
     
  11. ruzbehraja

    ruzbehraja Well-Known Member

    Joined:
    May 19, 2011
    Messages:
    392
    Likes Received:
    11
    Trophy Points:
    68
    cPanel Access Level:
    Root Administrator
    What are the file permissions on the source machine? i.e. the files which are getting incorrectly uploaded.

    Umask will simply strip out the existing permissions and mask the original permission with the mask value. It does not freshly add any permissions.

    It seems like it is using the umask 113 instead of 133.

    If you don't use SFTP and use only FTP does it work properly?
     
    cPanelMichael likes this.
  12. Havri

    Havri Well-Known Member

    Joined:
    Oct 28, 2013
    Messages:
    58
    Likes Received:
    14
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    Hello,

    I've recently had a similar problem too. Don't know if it's related and I hope I'm not putting you on the wrong path. In my case, the files created by accessing a PHP script (for example, PHP that created cache files) all had 664 permissions. Umask was set correctly, showing 0022:

    [root@server2 ~]# su - myuser -s/bin/bash -c "umask"
    0022

    After removing all the ACLs from /home directory, the problem was still there, so I uninstalled CageFS. After uninstalling CageFS and restarting Litespeed/Apache, the permissions for the newly created files were set correctly with 644 (so the umask was applied correctly).

    TL;DR:
    1. Remove all ACLs from /home (if you have them).
    2. Uninstall or reinstall CageFS (warning, this might break some Cloudlinux functionalities, so I recommend doing this outside of working hours).
    3. Restart web server.

    Check again if FTP/PHP/etc. creates files with the correct permissions.

    Let me know if it worked.

    Regards.
     
  13. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,658
    Likes Received:
    1,419
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello @WorkinOnIt,

    SFTP is simply matching the permissions on the files that are set on the source server. The best approach to address this issue is to use a SFTP client that will automatically set file permissions during the upload process, or to update the permission values on those files on the source server before uploading them.

    Additionally, you mentioned using FileZilla. This was brought up to FileZilla in the past as a bug in their application:

    https://trac.filezilla-project.org/ticket/10000

    Additionally, a similar case was opened at:

    https://trac.filezilla-project.org/ticket/11104

    You may need to submit a new case to FileZilla, or try a different SFTP client to see if the issue persists.

    Thank you.
     
    ruzbehraja likes this.
  14. Havri

    Havri Well-Known Member

    Joined:
    Oct 28, 2013
    Messages:
    58
    Likes Received:
    14
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    Hello,

    I'm updating this post as there actually is a problem with some umask within CageFS. Maybe that's why your permissions get modified on upload. I'll post my example below.

    If the user is inside CageFS, the cache files are created with 666 permissions, like below:

    Code:
    [root@myserver public_html]# find /home/myuser1/public_html/ -type f -mmin -2 -exec ls -al {} \;
    -rw-r--r-- 1 myuser1 myuser1 3820956 May  5 12:08 ./error_log
    -rw-rw-rw- 1 myuser1 myuser1 3383 May  5 12:08 ./journal-cache/1493978919_j2_module_journal_cms_blocks_54_3_content_bottom_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 229 May  5 12:08 ./journal-cache/1493978939_j2_module_journal_slider_1_1_top_fonts_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 3502 May  5 12:08 ./journal-cache/1493978939_j2_module_journal_slider_1_1_top_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 6885 May  5 12:08 ./journal-cache/1493978939_j2_module_journal_photo_gallery_52_1_content_bottom_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 2795 May  5 12:08 ./journal-cache/1493978939_j2_module_journal_cms_blocks_24_1_top_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 1727 May  5 12:08 ./journal-cache/1493978939_j2_module_journal_cms_blocks_42_1_content_bottom_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html

    If I take the user out of CageFS + empty the cache folder + access the site to regenerate the cache files, they get created with 644 permissions:

    Code:
    [root@myserver public_html]# find /home/myuser1/public_html/ -type f -mmin -2 -exec ls -al {} \;
    -rw-r--r-- 1 myuser1 myuser1 3637 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_slider_1_1_top_sk4_s0_l1_cRON_u0_mobile_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-r--r-- 1 myuser1 myuser1 229 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_slider_1_1_top_fonts_sk4_s0_l1_cRON_u0_mobile_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-r--r-- 1 myuser1 myuser1 2795 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_cms_blocks_24_1_top_sk4_s0_l1_cRON_u0_mobile_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-r--r-- 1 myuser1 myuser1 3383 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_cms_blocks_54_3_content_bottom_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_b58178deb37af32719f2b19d636b310e.cache.html
    -rw-r--r-- 1 myuser1 myuser1 6875 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_photo_gallery_52_1_content_bottom_sk4_s0_l1_cRON_u0_mobile_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-r--r-- 1 myuser1 myuser1 1739 May  5 12:12 ./journal-cache/1493979151_j2_module_journal_cms_blocks_42_1_content_bottom_sk4_s0_l1_cRON_u0_mobile_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html

    After that, if I put the user back into CageFS + empty the cache folder and reinitialize with "cagefsctl --reinit", the cache files are getting created with 666 permissions:

    Code:
    [root@myserver public_html]# find /home/myuser1/public_html/ -type f -mmin -2 -exec ls -al {} \;
    -rw-rw-rw- 1 myuser1 myuser1 640 May  5 12:27 ./journal-cache/1493980076_j2_config_secondary_menu_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 5915 May  5 12:27 ./journal-cache/57f9ca2bb691c972f746572fe573c196.css
    -rw-rw-rw- 1 myuser1 myuser1 11339 May  5 12:27 ./journal-cache/1af414b8ea2ad90dba2b244ed9d6e8e8.css
    -rw-rw-rw- 1 myuser1 myuser1 6082 May  5 12:27 ./journal-cache/1493980076_j2_config_footer_menu_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 669 May  5 12:27 ./journal-cache/1493980076_j2_config_primary_menu_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 26751 May  5 12:27 ./journal-cache/0555d724dbf179517d320bd2cee2baaa.css
    -rw-rw-rw- 1 myuser1 myuser1 21217 May  5 12:27 ./journal-cache/d4c852af1ff7a364924ce17988642937.css
    -rw-rw-rw- 1 myuser1 myuser1 3656 May  5 12:27 ./journal-cache/e857f6823354255bc72a248dc519aeb5.js
    -rw-rw-rw- 1 myuser1 myuser1 14650 May  5 12:27 ./journal-cache/2e4b401574c5fb5ba633781a3a49dc43.css
    -rw-rw-rw- 1 myuser1 myuser1 96497 May  5 12:27 ./journal-cache/journal-skin-4-desktop-1-2.9.1.css
    -rw-rw-rw- 1 myuser1 myuser1 20774 May  5 12:27 ./journal-cache/6ea48512e41943c183ba3498a99062a8.css
    -rw-rw-rw- 1 myuser1 myuser1 3714 May  5 12:27 ./journal-cache/dc8b69056778f94ff6df19949ae18943.css
    -rw-rw-rw- 1 myuser1 myuser1 37781 May  5 12:27 ./journal-cache/_35b7bde684e45e6f52e29a7a0d38b201.js
    -rw-rw-rw- 1 myuser1 myuser1 2443 May  5 12:27 ./journal-cache/123736bcfbf4b7e179abfeac62181b6d.css
    -rw-rw-rw- 1 myuser1 myuser1 7326 May  5 12:27 ./journal-cache/d105e01ef00c80d27ea3072b29c599d0.js
    -rw-rw-rw- 1 myuser1 myuser1 4322 May  5 12:27 ./journal-cache/a8503b48abc8c00f7b7f26ed70ea7ee3.js
    -rw-rw-rw- 1 myuser1 myuser1 4339 May  5 12:27 ./journal-cache/fe847b0bd4201e87e499590e02c3ee2c.js
    -rw-rw-rw- 1 myuser1 myuser1 47754 May  5 12:27 ./journal-cache/30c41dd4f366de5a950ab94d6fefcc95.css
    -rw-rw-rw- 1 myuser1 myuser1 17743 May  5 12:27 ./journal-cache/e8b278041cf332bb372b8804410b32f1.css
    -rw-rw-rw- 1 myuser1 myuser1 60050 May  5 12:27 ./journal-cache/8d1135c74b9743dafb8708b3d2c25476.css
    -rw-rw-rw- 1 myuser1 myuser1 1169 May  5 12:27 ./journal-cache/b7a0dc8a28758469177b2ff53892acc5.js
    -rw-rw-rw- 1 myuser1 myuser1 14993 May  5 12:27 ./journal-cache/1493980076_j2_config_mega_menu_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 4352 May  5 12:27 ./journal-cache/c3b2a49cbba11391dde917806c7b2dc0.css
    -rw-rw-rw- 1 myuser1 myuser1 14369 May  5 12:27 ./journal-cache/43f8bae84a37e79892ce9bdba395438e.js
    -rw-rw-rw- 1 myuser1 myuser1 2594 May  5 12:27 ./journal-cache/journal-skin-4-desktop-1-2.9.1.js
    -rw-rw-rw- 1 myuser1 myuser1 3383 May  5 12:27 ./journal-cache/1493980077_j2_module_journal_cms_blocks_54_3_content_bottom_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html
    -rw-rw-rw- 1 myuser1 myuser1 16157 May  5 12:27 ./journal-cache/a8af5ed5d5222f5be91d002ad6f49fcf.css
    -rw-rw-rw- 1 myuser1 myuser1 288046 May  5 12:27 ./journal-cache/1493980076_j2_settings_sk4_s0_l1_cRON_u0_desktop_price_2.9.1_3de987a00d69b16e06208222ef7222e3.cache.html


    It surely looks like a mount/CageFS + umask problem. I've reopened an older ticket with cPanel. I'll come back to update this post in case your situation is the same as mine.

    Regards.
     
    cPanelMichael likes this.
  15. Havri

    Havri Well-Known Member

    Joined:
    Oct 28, 2013
    Messages:
    58
    Likes Received:
    14
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    Hello,

    Just to update this issue, cPanel opened an internal case #CPANEL-13050. I'll come back when I have news.

    Regards.
     
    cPanelMichael likes this.
  16. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,658
    Likes Received:
    1,419
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

    To update, the internal case number has changed to EA-6248. The case was opened to report an issue on systems using CageFS where if a cPanel account is included in CageFS, and PHP is used to create files, the permissions that the files are created with are 0666 instead of 0644. I'll update this thread with more information on the status of this case as it becomes available.

    Thank you.
     
    ruzbehraja likes this.
  17. WorkinOnIt

    WorkinOnIt Well-Known Member

    Joined:
    Aug 3, 2016
    Messages:
    113
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    UK
    cPanel Access Level:
    Root Administrator
    Yes, sorry that was a typo - the correct entry is:

    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
    # 1/5/2017 modified to change umask to 022 from 002
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
        umask 022
    else
        umask 022
    fi
     
Loading...

Share This Page