[SOLVED] Wrong perms when installing Apache2

Usalabs · 02-13-2020, 07:30 PM

OK, here's the big problem, I've installed headless Ubuntu server 18.04 LTS on a home server (Dell PowerEdge T710), and when I installed Apache, then PHP and all the needed modules, I noticed that apt installs Apache as root and when it configures Apache, the Apache root directories and all other sub-directories are root:root so when I upload any web files, either as HTML or PHP, they too are changed to root:root, then when I try to use a php site installer (such as SMF) which checks specific file permissions during install and does the changing via FTP, the PHP error log shows an error:-

chmod 777 attachments - Operation not permitted

So after hours of investigations, I found it's because of the user:group set to root:root of Apache's document root directory, is not allowing the FTP module to change perms, but if I manually change the user:group of the directory and it's sub-directories to www-data:www-data (using chown -R www-data:www-data /var/www/html) then it all works fine.

When apt installs and configures Apache, why doesn't is change Apache's document root directory to the proper user:group of www-data:www-data?

rnturn · 02-14-2020, 07:02 AM

Quote:

Originally Posted by Usalabs

OK, here's the big problem, I've installed headless Ubuntu server 18.04 LTS on a home server (Dell PowerEdge T710), and when I installed Apache, then PHP and all the needed modules, I noticed that apt installs Apache as root and when it configures Apache, the Apache root directories and all other sub-directories are root:root so when I upload any web files, either as HTML or PHP, they too are changed to root:root, then when I try to use a php site installer (such as SMF) which checks specific file permissions during install and does the changing via FTP, the PHP error log shows an error:-

chmod 777 attachments - Operation not permitted

So after hours of investigations, I found it's because of the user:group set to root:root of Apache's document root directory, is not allowing the FTP module to change perms, but if I manually change the user:group of the directory and it's sub-directories to www-data:www-data (using chown -R www-data:www-data /var/www/html) then it all works fine.

When apt installs and configures Apache, why doesn't is change Apache's document root directory to the proper user:group of www-data:www-data?

I've noticed the same sort of thing. I'm pretty certain that it should be possible for the installation process to do this -- $DIETY knows I've seen enough zypper sessions issue messages about correcting permissions -- but I'm not sure why it isn't being done. On the positive side, you only need to change the ownership once, right?

Cheers...

scasey · 02-14-2020, 01:43 PM

If the DocumentRoot of the server is /var/www/html it should be owned by root, which is the way the installation sets it up. It is "world readable" (chmod 755) so it can be read by the web server user, www-data in your case.

To set up a user-writeable place to which to upload content, make a sub-directory, say: /var/www/html/user1 which is owned by user1 and is also chmod 755 Files therein will be chmod 644. Point a domain name at that subdirectory with VirtualHost.

With a couple of exceptions, the publicly accessible spaces in a web server setup should never be writable by the web server user.

Usalabs · 02-14-2020, 06:11 PM

Quote:

Originally Posted by scasey

If the DocumentRoot of the server is /var/www/html it should be owned by root, which is the way the installation sets it up. It is "world readable" (chmod 755) so it can be read by the web server user, www-data in your case.

To set up a user-writeable place to which to upload content, make a sub-directory, say: /var/www/html/user1 which is owned by user1 and is also chmod 755 Files therein will be chmod 644. Point a domain name at that subdirectory with VirtualHost.

With a couple of exceptions, the publicly accessible spaces in a web server setup should never be writable by the web server user.

If I setup a user at /var/www/html/<user> and Apache's document root is at /var/www/html, and the domain name points to my web server, by typing www.domain.com/<user> in a browser would serve up those web files, because all files and directories starting from /var/www/html is world readable (755), that's how I make a web site, by placing all the main files in /var/www/html then using sub-directories of of the doc root for other things then place links to them on the main page.

EG.
www.domain.com would show the main front page
www.domain.com/<other site> would serve up what's in the sub-directory of the same name

But if I wanted something that's completely separate, then I would place the files outside the doc root, in /var/www then use Apache's document redirect to point to that directory.

EG.
A web site is loaded at /var/www/gallery but typing www.domain.com/gallery will show a not found error, but using Apache's doc redirect, typing www.domain.com/gallery would point to /var/www/gallery and show up the web site.

But anything placed in or above the doc root, for some reason, has to be set to www-data:www-data otherwise Apache can 't serve it, I even tried <user>:www-data, didn't work, root:www-data didn't work, it HAS to be www-data:www-data for any HTM/HTML files to be served, or PHP scripts to be executed.

OK, as a test I have set up Apache using defaults, and temporarily using a DDNS host name from noip, and I created and installed Simple Machines Forum in maintenance mode on /var/www/html/SMF if you were to click on this link:- http://home-regions.no-ip.org you will see the Apache default page, but if you were to click on this:- http://home-regions.no-ip.org/SMF you will see the maintenance page for Simple Machines Forum installed in the exact same name directory. there is no redirect in place, this is to show that anything placed in any sub-directory inside the doc root will get served by Apache, as for permissions and ownership, var/www and any sub-directories within it are all 755 and www-data:www-data

scasey · 02-14-2020, 07:44 PM

I didn't say what you were doing wouldn't work, only that your method wasn't the best way to do it, given your concern (complaint) about the way the server is installed by default.

Using VirtualHosts, each with their own DocumentRoot, we serve more than 70 domains, each from their own sub-directories under the server's DocumentRoot. The server's DocumentRoot is never accessed directly and contains no content. We're using no re-direction.

Sub-directories under a domain's DocumentRoot (or the server's) will each require an index.htm(l) to avoid a Not Found error. Absent one, the browser will either display an index of the files or a 404, depending on the setting of Option Indexes.

An example VirtualHost container (from the httpd.conf file)

Code:

<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/html/example
    ServerName example.com
    ErrorLog logs/example.com-error_log
    CustomLog logs/example.com-access_log common
</VirtualHost>

a request for example.com will return the index.html in /var/www/html/example
A separate VirtualHost container with

Code:

    DocumentRoot /var/www/html/widget
    ServerName widget.com

will return content from /var/www/html/widget when widget.com is requested.

The content of those two sub-directories are independent of each other, but both run under and are served by the same web server.

Usalabs · 02-14-2020, 09:56 PM

Thanks to everyone's help, but after trying this and that and screwing up the other, all I'm getting now when using any other directory than /var/www/html and /var/www/html/SMF is Error 500, with nothing to show in any of the Apache or PHP error logs, soooo, I've come to the conclusion, that Apache is the most impossible system to setup and use, one needs a university degree just to configure it, as a result, I'm not wasting my time with this, and I've reformatted the server and installed a NAS system which works out-of-the-box, no messing with configuration files, no remembering 1000s of commands and settings, just use the browser interface, and done.

scasey · 02-14-2020, 11:08 PM

There’s definitely a learning curve, but one certainly doesn’t need a degree to configure and use it; just a willingness to read and understand how to make it work.
I’m sorry I wasn’t able to help you. I don’t understand how a NAS system would replace an Apache web server. Maybe we just didn’t understand what you were trying to accomplish. Maybe take a peek at the X Y Problem link in my sig, for the next time.

Usalabs · 02-15-2020, 03:39 AM

I've completely done away with any sort of web serving, and now just use the server as a NAS, for storing all my VHS tapes I backed up to PC, and also as a central backup for the other computers in the house, as each one has it's own little space on the NAS server.

Luckily, I didn't go head first and buy a domain name, before realizing the huge time consumption used in installing and setting up Apache.

As you said it's a learning curve, and I learnt, that if I want to run and manage a web site, then I would have to pay a professional hosting company to host the site, at least they don't have people that are fumbling around with a tower of books and manuals and taking months to get it right, they ARE professionals and probably went to university to major in web server installation and configurations, much the same as I have a masters degree in digital electronics, which means I can design, build and troubleshoot digital circuitry, now, if (when I was a lot younger) I went to university and majored in the installation and configuring of web servers, it wouldn't take months to set one up.

I'm marking this as solved.