SOLVED Incorrect upload File permissions 664

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
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.
 

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
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

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
.... In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":

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 ] && [ "`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

Well-Known Member
Aug 3, 2016
195
28
28
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.
 

ruzbehraja

Well-Known Member
May 19, 2011
392
11
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?
 
  • Like
Reactions: cPanelMichael

Havri

Well-Known Member
Oct 28, 2013
86
19
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:

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

Administrator
Staff member
Apr 11, 2011
47,910
2,213
363
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.
 
  • Like
Reactions: ruzbehraja

Havri

Well-Known Member
Oct 28, 2013
86
19
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:
[[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:

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

Code:
[[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.
 
  • Like
Reactions: cPanelMichael

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,213
363
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.
 
  • Like
Reactions: ruzbehraja

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
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:

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
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,213
363
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.