Share

Question

When I connect to my Linux server through Filezilla only the stock WordPress themes show up. Other themes that are installed and visible in the WordPress theme panel do not show up on the server. I’m trying to create a child theme. Do you know any possible reasons these other themes are not showing up? Is there another way I can create a child theme, through the Linux command line maybe? Thank you and I hope to hear back from you soon.

Answer 1

jtittle1 November 17, 2015

@alexandratepp

One possible reason would be permissions. Specifically, if permissions on Themes A, B and C are set to user1 and Themes D, E and F are set to user2, then user1 may not be able to see them (where user1 would be the user you’re logging in as via SFTP).

The web server often has escalated privileges, so it would most likely be able to read both users data, though when you log in as a specific user (via SFTP), you’re logging in with limited privileges (specific to that user), which most likely does not have permission to view another users data.

It would really depend on your setup. Are you using DigitalOcean’s WordPress image or your own custom setup? If custom, how did you set things up?

Reply Report

alexandratepp November 22, 2015

I set this machine up following the tutorials here on Digital Ocean, using the LAMP Stack, but that was a few months back so I don’t remember everything I setup.
It could be a permissions issue. I can’t see the Biancaa folder under wordpress\wp-content\themes with either my dedicated WordPress user or the user I set the machine up with. I tried using Putty and the folder still doesn’t show even when running sudo ls -a. I also tried running ls with grep ‘Biancaa’ I made sure to try capitalization combinations as well.
I can’t login to the root user as (per the setup tutorial here) I made sure it was disabled. Shouldn’t sudo give me the permissions I need anyway?
Reply Report
- jtittle1 November 23, 2015
  
  @alexandratepp
  
  If, when you login to the CLI as root or a sudo user, you’re unable to view the folder, it doesn’t exist. The root user has the highest allowed permissions and the sudo user is allowed to utilize those permissions when sudo is called, thus giving the sudo uses the same permissions for the duration of the command. If either or both fail to see a folder, it simply does not exist on the system (unless there’s something majorly wrong with the current permissions - i.e. something has really messed things up).
  
  As for logging in as root, you should still be able to execute su - to escalate. Simply because you’ve disabled root login doesn’t mean that you can’t regain access :-).
  
  That said, ideally, for security, you should (as you’ve done) disable root login, though you should also create two additional users in the following format:
  
  a). A sudo user, which you’ve done.
  b). A new user for each account/domain.
  
  The sudo user is who you login as when you need to perform escalated commands (i.e. updates, upgrades, package installation etc). The “new” user, which is associated with a specific account or domain is who should “own” the directories, files etc - this is also who you should be logging in to SFTP with.
  
  This user should not have any sort of escalated permissions, only the basics that allow them to read, write and execute from directories and/or files they own (thus preventing one user from being able to read, write and execute another users files or from their directories).
  
  –
  
  That said, what would appear to be the case here is that while you’re being led to believe that a theme or file is uploaded, it’s not, otherwise you’d be able to see it at the very least. This boils down to permissions and the fact that the user that is actually handling the uploading does not have permissions to write to the directories in your home directory.
  
  If we take a basic directory structure such as:
  
  /home/domains/yourdomain.ext/htdocs/public_html
  
  Then:
  
  /home/domains
  
  … should be owned by root and:
  
  /home/domains/yourdomain.ext
  
  … and all directories & files below it should be owned by user where user = the user of your choice - i.e:
  
  /home/domains/yourdomain.ext/.... /home/domains/yourdomain.ext/htdocs/.... /home/domains/yourdomain.ext/public_html/....
  
  … where .... would be files & directories.
  
  Reply Report

Answer 2

alexandratepp November 22, 2015

I set this machine up following the tutorials here on Digital Ocean, using the LAMP Stack, but that was a few months back so I don’t remember everything I setup.
It could be a permissions issue. I can’t see the Biancaa folder under wordpress\wp-content\themes with either my dedicated WordPress user or the user I set the machine up with. I tried using Putty and the folder still doesn’t show even when running sudo ls -a. I also tried running ls with grep ‘Biancaa’ I made sure to try capitalization combinations as well.
I can’t login to the root user as (per the setup tutorial here) I made sure it was disabled. Shouldn’t sudo give me the permissions I need anyway?
Reply Report
- jtittle1 November 23, 2015
  
  @alexandratepp
  
  If, when you login to the CLI as root or a sudo user, you’re unable to view the folder, it doesn’t exist. The root user has the highest allowed permissions and the sudo user is allowed to utilize those permissions when sudo is called, thus giving the sudo uses the same permissions for the duration of the command. If either or both fail to see a folder, it simply does not exist on the system (unless there’s something majorly wrong with the current permissions - i.e. something has really messed things up).
  
  As for logging in as root, you should still be able to execute su - to escalate. Simply because you’ve disabled root login doesn’t mean that you can’t regain access :-).
  
  That said, ideally, for security, you should (as you’ve done) disable root login, though you should also create two additional users in the following format:
  
  a). A sudo user, which you’ve done.
  b). A new user for each account/domain.
  
  The sudo user is who you login as when you need to perform escalated commands (i.e. updates, upgrades, package installation etc). The “new” user, which is associated with a specific account or domain is who should “own” the directories, files etc - this is also who you should be logging in to SFTP with.
  
  This user should not have any sort of escalated permissions, only the basics that allow them to read, write and execute from directories and/or files they own (thus preventing one user from being able to read, write and execute another users files or from their directories).
  
  –
  
  That said, what would appear to be the case here is that while you’re being led to believe that a theme or file is uploaded, it’s not, otherwise you’d be able to see it at the very least. This boils down to permissions and the fact that the user that is actually handling the uploading does not have permissions to write to the directories in your home directory.
  
  If we take a basic directory structure such as:
  
  /home/domains/yourdomain.ext/htdocs/public_html
  
  Then:
  
  /home/domains
  
  … should be owned by root and:
  
  /home/domains/yourdomain.ext
  
  … and all directories & files below it should be owned by user where user = the user of your choice - i.e:
  
  /home/domains/yourdomain.ext/.... /home/domains/yourdomain.ext/htdocs/.... /home/domains/yourdomain.ext/public_html/....
  
  … where .... would be files & directories.
  
  Reply Report

Related

Question

Linux server, Filezilla and child themes

Leave a comment

Looking for something else?

Share

Share your Question

Related

Question

Linux server, Filezilla and child themes

Leave a comment

Related

question

How can I host another wordpress domain on the same droplet?

question

How to fix: "The link you followed has expired", when installing Wordpress.

question

nginx 404 error on all wordpress posts and pages except homepage

question

Running a web-based video game on a droplet

Looking for something else?

Almost there!