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

 

[Infopro]

This thread may be useful:
SOLVED - SFTP - Incorrect upload permissions

 

[ruzbehraja]

You can set the umask in your config file.

More on umask: ProFTPD: Umask


More on FTP Config editing see FTP FAQ - Documentation - cPanel Documentation

 

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

 

[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

 

[WorkinOnIt]

Output as requested above;

[[email protected] ~]# 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

 

[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

 

[Infopro]

Posts you made in the other thread, moved here. Please don't cross post to multiple threads.

 

[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

 

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

 

[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?

 

[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:

[[email protected] ~]# 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.

 

[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:

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.

 

[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:

[[email protected] 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:

[[email protected] 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:

[[email protected] 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.

 

[Havri]

Hello,

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

Regards.

 

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

 

[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

 

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