Skip to main content

Incorrect upload File permissions 664

WorkinOnIt
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.

Comments

17 comments

Date Votes
  • Infopro
    This thread may be useful: SOLVED - SFTP - Incorrect upload permissions
    0
  • ruzbehraja
    You can set the umask in your config file. More on umask: ProFTPD: Umask More on FTP Config editing see
    0
  • WorkinOnIt
    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.

    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.
    0
  • WorkinOnIt
    .... 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.

    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
    0
  • WorkinOnIt
    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
    0
  • WorkinOnIt
    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
    0
  • Infopro
    Posts you made in the other thread, moved here. Please don't cross post to multiple threads.
    0
  • Infopro
    Any other tips to try? suphp.conf ;Umask to set, specify in octal notation umask=0022

    Is this correct or a typo? It's not supposed to be, 0022, it's 022
    0
  • WorkinOnIt
    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.
    0
  • ruzbehraja
    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?
    0
  • Havri
    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.
    0
  • cPanelMichael
    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: You may need to submit a new case to FileZilla, or try a different SFTP client to see if the issue persists. Thank you.
    0
  • Havri
    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:
    [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:
    [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:
    [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.
    0
  • Havri
    Hello, Just to update this issue, cPanel opened an internal case #CPANEL-13050. I'll come back when I have news. Regards.
    0
  • cPanelMichael
    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.
    0
  • WorkinOnIt
    Is this correct or a typo? It's not supposed to be, 0022, it's 022

    Yes, sorry that was a typo - the correct entry is:
    # 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
    0
  • cPanelMichael
    Hello, To follow up, this was solved via a CageFS update. Let us know if you encounter any additional problems with the file permissions. Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post