SOLVED SFTP - Incorrect upload permissions

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
I have tried both the steps provided in this forum.
But still the files permission is not changing while uploding.
Could you let us know the specific steps you are taking when reproducing the issue? Also, please post the output from the following command:

Code:
rpm -qa|grep suphp
Thank you.
 

aztest

Registered
Apr 11, 2016
3
0
1
tamil nadu
cPanel Access Level
Root Administrator
I am just connecting my cpanel account via "SFTP" and uploading the files. The files are uploading on the same permission e.g"664" but not changing to "644".
~~~~~~~~~~~~
rpm -qa|grep suphp
ea-apache24-mod_suphp-0.7.2-17.17.12.cpanel.x86_64
~~~~~~~~~~~~
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
Hello,

The resolution from the referenced case should allow suPHP to run when the permissions are set to 0664. If you want to correct the actual permissions that are configured when uploading files via SFTP, you'd need to update the permissions assigned to the file on the server you are copying the files from, as SFTP is simply matching the permissions that are set on the source server.

Thank you.
 

chalupa

Member
Jul 15, 2014
14
0
51
cPanel Access Level
DataCenter Provider
I seem to still be having this issue uploading files on a server using Filezilla. I thought that this was fixed with a EA4 update? I see that's just a patch to allow suphp to actually use the files with the improper permissions though. On 2 different servers both running CentOS 7.3 with CloudLinux. I have attempted to upload files that are originally 644 and 664 and without that local masking they upload with the original 644 and 664 respectively but if I have the local mask they upload properly as 644. Also creating dir/file within Filezilla I am able to create with the proper 755/644 w/local mask but is created with 775/664 respectively in filezilla. Why is SFTP honoring the local mask but not the global one in /etc/bashrc?
server3 CPANELUSER]# grep umask /etc/bashrc

# By default, we want umask to get set. This sets it for non-login shell.
umask 022
umask 022

httpd -v
Server version: Apache/2.4.25 (cPanel)
Server built: Apr 14 2017 12:43:52

uname -a
Linux server2.domain.tld 3.10.0-427.36.1.lve1.4.44.el7.x86_64 #1 SMP Sun Apr 2 11:56:48 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

cat /usr/local/cpanel/version
11.64.0.19

cat /etc/redhat-release
CloudLinux release 7.3 (Yury Malyshev)

rpm -qa|grep suphp
ea-apache24-mod_suphp-0.7.2-16.el7.cloudlinux.x86_64

I used the workaround above as umask is supposed to change incoming file as 664 to 644 but is not. Because using Cloud Linux had to update the cage after the workaround in case someone else comes across the same thing. On the local machine

-rw-r--r-- 1 chris chris 561 Nov 18 15:37 image00001.png
-rw-rw-r-- 1 chris chris 2351 Jan 9 10:05 image007.png

After uploading.
-rw-r--r-- 1 CPANELUSER CPANELUSER 561 May 9 21:05 image00001.png
-rw-r--r-- 1 CPANELUSER CPANELUSER 2351 May 9 21:05 image007.png
 

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
Hi

Coming back to this thread as I've just installed a new server and this issue has come back again. CENTOS 7.3 x86_64 using EA4 and suphp.

I have checked etc/profile and the umask settings in there are incorrect

Code:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 002
else
   umask 022
fi
I have updated them to;

Code:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 022
else
   umask 022
fi
and restarted ssh but the same issue occurs - uploaded files are given 0664 in stead of 0644
 

rudtek

Member
Jul 19, 2017
24
2
3
Oregon
cPanel Access Level
Root Administrator
Hi

Coming back to this thread as I've just installed a new server and this issue has come back again. CENTOS 7.3 x86_64 using EA4 and suphp.

I have checked etc/profile and the umask settings in there are incorrect

Code:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 002
else
   umask 022
fi
I have updated them to;

Code:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 022
else
   umask 022
fi
and restarted ssh but the same issue occurs - uploaded files are given 0664 in stead of 0644
This is exactly what i did, but also in etc/bashc. It then worked fine. I was even having the problem without an ftp. For instance if i used the command wp core download. all files would be 664. After changing 002 to 022 in both these files, i was able to upload through ftp and through wp cli correctly.
 
  • Like
Reactions: abursill

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
@rudtek thank you for the contribution to this thread.

Just to clarify - the files to update are:

etc/profile
etc/bashrc (there was a type in what you wrote above).

After making the changes from 002 -> 022 re-uploading the file and then restarting SSH it works great! Now all folders upload as 0755 and files as 0644 when using e.g. filezilla

The question is - will these files change back at some point after an update?
 
  • Like
Reactions: abursill

WorkinOnIt

Well-Known Member
Aug 3, 2016
195
28
28
UK
cPanel Access Level
Root Administrator
Just to add to the above @cPanelMichael - I am using Filezilla from a Windows 7 machine. I get the same result when using Filezilla from a Mac also. I would have thought the uploaded file / folder permissions should be set by the server, not the originating machine.

However, modifying both the etc/profile & etc/bashrc files seems to have resolved the issue for now.
 

abursill

Member
Nov 8, 2019
17
3
3
Thailand
cPanel Access Level
Website Owner
This is exactly what i did, but also in etc/bashc. It then worked fine. I was even having the problem without an ftp. For instance if i used the command wp core download. all files would be 664. After changing 002 to 022 in both these files, i was able to upload through ftp and through wp cli correctly.
rudtek
thank you so much for the correct answer I have been banging y head against the wall for hours trying all the other suggestions on this forum and others. Changing both files was the only thing that worked. I am using coreftp and also WinSCP,so this is definately the correct answer anyone else should try first..
 

AndyB78

Well-Known Member
Oct 7, 2003
79
2
158
Romania
cPanel Access Level
Root Administrator
Hello,

A customer has just pointed out to me that files and folders uploaded through SFTP (only SFTP) get incorrect permissions (664 and 775) on a freshly installed cPanel server. I found this thread so I have modified /etc/profile and /etc/bashrc, I have restarted sshd but the problem continues.

I have also tried adding -u 22 to Subsystem as pointed out earlier in the thread but in this case I can't even connect through SFTP.

Can anyone help with a new functional workaround, or even better with a final solution?

Thanks!
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
3,074
387
243
cPanel Access Level
Root Administrator
@AndyB78 - there's a few different workarounds posted in this thread:


Can you try those and see if that gets things working? If not, it might be best to open a ticket with our team as it seems you've done a few things already to test this without getting positive results.
 

AndyB78

Well-Known Member
Oct 7, 2003
79
2
158
Romania
cPanel Access Level
Root Administrator
@AndyB78 - there's a few different workarounds posted in this thread:


Can you try those and see if that gets things working? If not, it might be best to open a ticket with our team as it seems you've done a few things already to test this without getting positive results.
Reporting back. In my case things went a little bit differently but it worked out in the end (though I was almost ready to give in and submit a ticket). After I have modified /etc/profile and /etc/bashrc (as many advises say) nothing happened on the spot. But the next day, it was working correctly. So I took it to the next server (we have migrated all our servers to freshly installed cPanel due to the CentOS6 EoL issue) and again, it hasn't worked. This made me think that maybe the nightly upcp made a difference so I ran upcp and after that it worked.

Also please note that in my case modifying /etc/profile was not necessary and it has not helped (apparently) but I don't think it hurts in any way. The /etc/bashrc modification followed by running /scripts/upcp was enough.
 
Last edited: