SOLVED SFTP - Incorrect upload permissions

[aztest]

I have tried both the steps provided in this forum.
But still the files permission is not changing while uploding.

 

[cPanelMichael]

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:

rpm -qa|grep suphp

Thank you.

 

[aztest]

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]

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]

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

 

[cPanelMichael]

On 2 different servers both running CentOS 7.3 with CloudLinux.

There's an open case with CageFS that's discussed on the following post:

Incorrect upload File permissions 664

Thank you.

 

[WorkinOnIt]

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

if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 002
else
   umask 022
fi

I have updated them to;

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

 

[cPanelMichael]

uploaded files are given 0664 in stead of 0644

Could you confirm how the files are uploaded?

Thank you.

 

[rudtek]

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

if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
   umask 002
else
   umask 022
fi

I have updated them to;

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.

 

[WorkinOnIt]

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

 

[WorkinOnIt]

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]

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]

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]

@AndyB78 - there's a few different workarounds posted in this thread:

Files and Folders Uploaded By sFTP Have Incorrect Permissions

There is a previous thread regarding a similar issue that is marked "solved," but I'm having problems with this after the supposed update fixed it, so I'm starting my own thread. The issue is that when I upload folders and files via sFTP the folders are set with the permissions 775 instead of...

forums.cpanel.net

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]

@AndyB78 - there's a few different workarounds posted in this thread:

Files and Folders Uploaded By sFTP Have Incorrect Permissions

There is a previous thread regarding a similar issue that is marked "solved," but I'm having problems with this after the supposed update fixed it, so I'm starting my own thread. The issue is that when I upload folders and files via sFTP the folders are set with the permissions 775 instead of...

forums.cpanel.net

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.

 

[cPRex]

I'm glad that's working well now!

 

[morrow95]

Resurrecting this as I just noticed the same problem. I upload with sftp and files are being added as 664 and folders as 775. I didn't notice it at first because it was only happening for new files/folders. Existing files/folders that already had the correct permissions stay correct even after uploading a more recent version. In the thread it says to modify the etc/profile and etc/bashrc files. In both of these files it says the following at the top :

# It's NOT a good idea to change this file unless you know what you
# are doing. It's much better to create a custom.sh shell script in
# /etc/profile.d/ to make custom changes to your environment, as this
# will prevent the need for merging in future updates.

What is the correct procedure to do it that way so any future updates that should happen will not overwrite my changes? I've ran into that problem waaaay too many times in the past and don't want to see changes wiped out because I modified a file directly. Any help would be appreciated. Thanks!

 

[cPRex]

We don't edit that file automatically - that caution is just in there because doing the wrong thing can hurt the user's environment. Editing /etc/bashrc is still a valid workaround at this time.

 

[morrow95]

We don't edit that file automatically - that caution is just in there because doing the wrong thing can hurt the user's environment. Editing /etc/bashrc is still a valid workaround at this time.

Thanks for the reply. So is editing etc/profile not needed then? Just /etc/bashrc?

 

[cPRex]

Most users don't seem to need to edit /etc/profile in order to make this work.