Still can't get NC installed

I now have no “data” directory in /var/www/html/nextcloud upon a fresh reload.
So there is no nextcloud log.
There is no “config.php” file, and “CAN_INSTALL” does exist
I get a 404 page not found when attempting to access the page, but NGINX shows no errors or access attempts. MYSQL shows no errors at the attempt, but does show a previous error about Access Denied for user “root@localhost”
When attempting to setup NC via command line, I get a “Too many arguments” message or that I’m missing arguments.

I’m on my dozenth iteration of NC, can’t even count the number of edits and attempts to get each running… and I’ve tried this on two different Pi units with 3 different SD cards on 5 different fresh loads of the OS over the past five months or so (roughly). I don’t want to give up as I keep learning things, and often get different errors or results. I got the Installation Wizard to appear once, but it didn’t allow me to install. I think it was user error, and by the time I think I figured out what it was looking for… well, the Wizard disappeared.

I’m beginning to think that maybe I’m just doing something totally weird…

System is Raspberry Pi 4
OS is Ubuntu Server 20.04 (headless / no GUI)
NGINX, MariaDB, PHP
sub.domain.dom to /var/www/html/nextcloud (with data in /opt/nextcloud/data )
SSH is enabled for site
DB is mysql “nextcloud” - user=“username”; admin=“adminname”; host=“localhost”

I don’t know… there’s lots I don’t know - I’m learning this webserver stuff as I go. I thought that was the problem, so I had a buddy who knows more about webservers (but nothing about NC) look over a few of my setups and he was confused too (as to why NC didn’t work). But we’re not ruling out that he may have missed something that NC needs.

Start by giving detailed steps of your installation procedure. I don’t even know what installation type you’re using based on the above.

Sure. Thanks KarlF12.

Prepare Installation
Flash Ubuntu Server 20.04 (for Raspberry Pi 4) Image to Micro-SDXC card
Insert Micro-SDXC card into Raspberry-Pi
Connect & Boot Raspberry Pi
Log In to Router to determine Raspberry Pi’s MAC address
Configure Router to Assign static IP to Raspberry Pi (192.168.1.100)
Log Out of Router
Reboot R-Pi
Prepare Server
SSH into Pi (ubuntu@192.168.1.100)
change default password from “ubuntu”

sudo apt-get update
sudo apt-get upgrade
sudo reboot

sudo adduser Admin1
sudo usermod -aG sudo Admin1
sudo adduser Admin2
sudo usermod -aG sudo Admin2
sudo reboot

sudo deluser –remove-home ubuntu

cd /opt
sudo mkdir nextcloud
cd nextcloud
sudo mkdir data
cd …
sudo chown -R www-data:www-data nextcloud

sudo apt install nginx

Now here’s where I had my friend step in (Admin2) to help me set up SSH & Certificates for:
domain.dom
and
sub.domain.dom (which is where NextCloud installation will be)

We set the server to allow access to ports 80 and 443, and then redirect port 80 HTTP to 443 HTTPS. We checked that everything was working okay, and both sites were working correctly.

sudo apt install mariadb-server

sudo apt install php-fpm php-mysql

sudo reboot

Again, my friend took over and set up for PHP test on sub.domain.dom and PHP was working fine.

Then:

sudo /etc/init.d/mysql start
sudo mysql -uroot -p

CREATE USER ‘username’@‘localhost’ IDENTIFIED BY ‘password’;
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES ON nextcloud.* TO ‘username’@‘localhost’;
FLUSH PRIVILEGES;

Note that I did use the NextCloud username instead of “username” here.

quit;

Next:

cd /var/www/html
sudo wget https://download.nextcloud.com/server/releases/nextcloud-19.0.3.tar.bz2
sudo wget https://download.nextcloud.com/server/releases/nextcloud-19.0.3.tar.bz2.sha256
sha256sum nextcloud-19.0.3.tar.bz2
cat nextcloud-19.0.3.tar.bz2.sha256

I verified that the checksums matched.

sudo tar xjfv nextcloud-19.0.3.tar.bz2
sudo chown -R www-data:www-data nextcloud

On the first attempt to get started… Where did I go wrong... again?

And then… Still having issues getting NextCloud installed - "Can’t create or write into the data directory opt/nextcloud/data”

And now after stopping NGINX and MYSQL and MYSQLD then:

cd /var/www/html
sudo mv nextcloud nextcloud.old
sudo tar xjfv nextcloud-19.0.3.tar.bz2
sudo chown -R www-data:www-data nextcloud
sudo reboot

And that’s where I am now.

/var/www/html/nextcloud/index.html
> [!DOCTYPE html]
> [html]
> [head]
> [script] window.location.href=“index.php”; [/script]
> [meta http-equiv=“refresh” content=“0; URL=index.php”]
> [/head]
> [/html]

/var/www/html/nextcloud/index.php

[?php
/**

  • @copyright Copyright © 2016, ownCloud, Inc.
  • @author Christoph Wurst [christoph@winzerhof-wurst.at]
  • @author Joas Schilling [coding@schilljs.com]
  • @author Jörn Friedrich Dreyer [jfd@butonic.de]
  • @author Lukas Reschke [lukas@statuscode.ch]
  • @author Morris Jobke [hey@morrisjobke.de]
  • @author Robin Appelman [robin@icewind.nl]
  • @author Roeland Jago Douma [roeland@famdouma.nl]
  • @author Sergio Bertolín [sbertolin@solidgear.es]
  • @author Thomas Müller [thomas.mueller@tmit.eu]
  • @author Vincent Petry [pvince81@owncloud.com]
  • @license AGPL-3.0
  • This code is free software: you can redistribute it and/or modify
  • it under the terms of the GNU Affero General Public License, version 3,
  • as published by the Free Software Foundation.
  • This program is distributed in the hope that it will be useful,
  • but WITHOUT ANY WARRANTY; without even the implied warranty of
  • MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  • GNU Affero General Public License for more details.
  • You should have received a copy of the GNU Affero General Public License, version 3,
  • along with this program. If not, see [http://www.gnu.org/licenses/]

*/

require_once DIR . ‘/lib/versioncheck.php’;

try {
require_once DIR . ‘/lib/base.php’;

    OC::handleRequest();

} catch (\OC\ServiceUnavailableException $ex) {
\OC::$server->getLogger()->logException($ex, [‘app’ => ‘index’]);

    //show the user a detailed error page
    OC_Template::printExceptionErrorPage($ex, 503);

} catch (\OC\HintException $ex) {
try {
OC_Template::printErrorPage($ex->getMessage(), $ex->getHint(), 503);
} catch (Exception $ex2) {
try {
\OC::$server->getLogger()->logException($ex, [‘app’ => ‘index’]);
\OC::$server->getLogger()->logException($ex2, [‘app’ => ‘index’]);
} catch (Throwable $e) {
// no way to log it properly - but to avoid a white page of death we try harder and ignore this one here
}

            //show the user a detailed error page
            OC_Template::printExceptionErrorPage($ex, 500);
    }

} catch (\OC\User\LoginException $ex) {
OC_Template::printErrorPage($ex->getMessage(), $ex->getMessage(), 403);
} catch (Exception $ex) {
\OC::$server->getLogger()->logException($ex, [‘app’ => ‘index’]);

    //show the user a detailed error page
    OC_Template::printExceptionErrorPage($ex, 500);

} catch (Error $ex) {
try {
\OC::$server->getLogger()->logException($ex, [‘app’ => ‘index’]);
} catch (Error $e) {
http_response_code(500);
header(‘Content-Type: text/plain; charset=utf-8’);
print(“Internal Server Error\n\n”);
print(“The server encountered an internal error and was unable to complete your request.\n”);
print(“Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.\n”);
print(“More details can be found in the webserver log.\n”);

            throw $ex;
    }
    OC_Template::printExceptionErrorPage($ex, 500);

}

/etc/nginx/sites-available/sub.domain.dom

upstream php-handler {
server 127.0.0.1:9000;
#server unix:/var/run/php/php7.4-fpm.sock;
}

server {
listen 443 ssl;
server_name sub.domain.dom;
root /var/www/html/nextcloud/;

    location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            fastcgi_pass   unix:/var/run/php/php7.4-fpm.sock;
    }

added 2020 sep 05 - attempt to fix Cant create or write into the data directory opt/nextcloud/data Error message

location /data/ {

root /opt/nextcloud/data/;

}

commented above out 2020 sep 05 - unsuccessful

location / {

try_files $uri $uri/ =404;

}

managed by Certbot

ssl_certificate /etc/letsencrypt/live/domain.dom/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/domain.dom/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    }

#}
server {
if ($host = sub.domain.dom) {
return 301 https://$host$request_uri;
} # managed by Certbot

    listen 192.168.1.100:80;
    server_name sub.domain.dom;
return 404; # managed by Certbot

    #}

# HTTP response headers borrowed from Nextcloud `.htaccess`
add_header Referrer-Policy                      "no-referrer"   always;
add_header X-Content-Type-Options               "nosniff"       always;
add_header X-Download-Options                   "noopen"        always;
add_header X-Frame-Options                      "SAMEORIGIN"    always;
add_header X-Permitted-Cross-Domain-Policies    "none"          always;
add_header X-Robots-Tag                         "none"          always;
add_header X-XSS-Protection                     "1; mode=block" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Default Cache-Control policy
expires 1m;

# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
    if ( $http_user_agent ~ ^DavClnt ) {
        return 302 /remote.php/webdav/$is_args$args;
    }
}

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
    # The following 6 rules are borrowed from `.htaccess`

    rewrite ^/\.well-known/host-meta\.json  /public.php?service=host-meta-json  last;
    rewrite ^/\.well-known/host-meta        /public.php?service=host-meta       last;
    rewrite ^/\.well-known/webfinger        /public.php?service=webfinger       last;
    rewrite ^/\.well-known/nodeinfo         /public.php?service=nodeinfo        last;

    location = /.well-known/carddav     { return 301 /remote.php/dav/; }
    location = /.well-known/caldav      { return 301 /remote.php/dav/; }

    try_files $uri $uri/ =404;
}

# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)              { return 404; }

# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    set $path_info $fastcgi_path_info;

    try_files $fastcgi_script_name =404;

    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $path_info;
    fastcgi_param HTTPS on;

    fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
    fastcgi_param front_controller_active true;     # Enable pretty urls
    fastcgi_pass php-handler;

    fastcgi_intercept_errors on;
    fastcgi_request_buffering off;
}

location ~ \.(?:css|js|svg|gif)$ {
    try_files $uri /index.php$request_uri;
    expires 6M;         # Cache-Control policy borrowed from `.htaccess`
    access_log off;     # Optional: Don't log access to assets
}

location ~ \.woff2?$ {
    try_files $uri /index.php$request_uri;
    expires 7d;         # Cache-Control policy borrowed from `.htaccess`
    access_log off;     # Optional: Don't log access to assets
}

location / {
    try_files $uri $uri/ /index.php$request_uri;
}

}

I hope this is all helpful.

The expected behavior as I recall (mine is different because I typically use Docker and Apache for Nextcloud) is that you should be presented with the first-time setup wizard the first time you access the page. What is it you see when you go to /nextcloud on your server?

Only saw that once out of the dozen or so installation / installation reconfigurations/edits that I did… but that’s not what I’m getting now.

Currently get ( https://sub.domain.dom/index.php ):

File not found.

Strangely… when I went to list the logs here… /var/www/html/nextcloud/data directory now exists… as do both index.html and nextcloud.log files in that directory.

Both index.html and nextcloud.log are empty.

/etc/log/nginx/error.log

2020/09/15 15:16:13 [error] 2288#2288: *53 open() “/var/www/html/nextcloud/owa/auth/logon.aspx” failed (2: No such file or directory), client: 192.241.234.146, server: sub.domain.dom, request: “GET /owa/auth/logon.aspx?url=https%xx%xx%xxx%xxxxx%xx HTTP/1.1”, host: “xxx.xxx.xxx.xxx”
2020/09/15 20:27:29 [error] 2288#2288: *72 FastCGI sent in stderr: “Primary script unknown” while reading response header from upstream, client: 192.168.1.1, server: sub.domain.dom, request: “GET /index.php HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.4-fpm.sock:”, host: “sub.domain.dom”, referrer: “https://sub.domain.dom/
2020/09/15 20:28:02 [error] 2288#2288: *72 FastCGI sent in stderr: “Primary script unknown” while reading response header from upstream, client: 192.168.1.1, server: sub.domain.dom, request: “GET /index.php HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.4-fpm.sock:”, host: “sub.domain.dom”, referrer: “https://sub.domain.dom/

/etc/log/nginx/error.log.1

2020/09/14 13:45:32 [error] 1896#1896: *328 open() “/var/www/html/nextcloud/.env” failed (2: No such file or directory), client: zzz.zzz.zzz.zzz, server: sub.domain.dom, request: “GET /.env HTTP/1.1”, host: “xxx.xxx.xxx.xxx”
2020/09/14 22:48:26 [warn] 1779#1779: conflicting server name “sub.domain.dom” on 0.0.0.0:443, ignored
2020/09/14 22:48:26 [warn] 1779#1779: conflicting server name “sub.domain.dom” on 192.168.1.100:80, ignored
2020/09/14 22:48:26 [emerg] 1779#1779: bind() to 192.168.1.100:80 failed (99: Cannot assign requested address)
2020/09/14 22:50:21 [warn] 2204#2204: conflicting server name “sub.domain.dom” on 0.0.0.0:443, ignored
2020/09/14 22:50:21 [warn] 2204#2204: conflicting server name “sub.domain.dom” on 192.168.1.100:80, ignored
2020/09/14 22:51:13 [error] 2207#2207: *1 FastCGI sent in stderr: “Primary script unknown” while reading response header from upstream, client: 192.168.1.1, server: sub.domain.dom, request: “GET /index.php HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.4-fpm.sock:”, host: “sub.domain.dom”, referrer: “https://sub.domain.dom/
2020/09/14 23:48:18 [warn] 1782#1782: conflicting server name “sub.domain.dom” on 0.0.0.0:443, ignored
2020/09/14 23:48:18 [warn] 1782#1782: conflicting server name “sub.domain.dom” on 192.168.1.100:80, ignored
2020/09/14 23:48:18 [emerg] 1782#1782: bind() to 192.168.1.100:80 failed (99: Cannot assign requested address)
2020/09/14 23:50:22 [warn] 2285#2285: conflicting server name “sub.domain.dom” on 0.0.0.0:443, ignored
2020/09/14 23:50:22 [warn] 2285#2285: conflicting server name “sub.domain.dom” on 192.168.1.100:80, ignored
2020/09/14 23:50:40 [error] 2288#2288: *1 FastCGI sent in stderr: “Primary script unknown” while reading response header from upstream, client: 192.168.1.1, server: sub.domain.dom, request: “GET /index.php HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.4-fpm.sock:”, host: “sub.domain.dom”, referrer: “https://sub.domain.dom/

Looks like for every problem I solve, I seem to create a mess of more of them.

Based on that log, it appears to me the problem is with the nginx configuration. But I’m not very familiar with nginx (I prefer Apache), so I’m not entirely sure.

Okay… I’ll take another, more thorough look at it.

I’m pretty sure I undid everything I did before the error, but at this point - it’s very likely I forgot to note something.

Thanks.

Hey, make it easy on yourself:

1 Like

Wouldn’t yours be https://sub.domain.com/nextcloud ?

typing sub.domain.dom into the browser gets me https://sub.domain.dom/index.php

But on a whim I tried sub.domain.dom/nextcloud and sub.domain.dom/nextcloud/index.php

They give me a 404 not found message

enoch85, That’s an impressive project. I’ve looked at it previously.

I really want to have a bit of customization to my server and sites, and to have a bit more understanding of the mechanics and configuration that goes into it.

But I’m probably not far from going a different route and doing something like using your project or similar. Especially if I can’t get this figured out. I’ll trying learning it from another angle.

1 Like

A manual installation like this shouldn’t cause so much trouble, so I hesitate to suggest an alternative to you. You could try running the snap package, which is almost entirely hands-free on setup, but be forewarned that it’s rather inflexible.

If you want to try Docker, I wrote a guide for that. I prefer Docker personally because no matter your *nix flavor or what else is going on with your system, the Docker container comes with its own stuff in a stable and known-good setup.

Learning by doing is great, but it takes time.

The Nextcloud VM is a shortcut to getting it up and running, then when it’s up, you are of course free to customize whatever you want. It’s your server. :slight_smile:

You have configured nginx + nextcloud in the webroot, so you’ll need a bit more voodoo in nginx’s configuration. Read this:

I have limited experience with nginx, so I won’t be of much help. I do know that Apache didn’t require much additional configuration.

This won’t fix your permissions issue with the data directory, but might get the initial setup page or the login page to appear.

Also want to say welcome to the club, I suspect pretty much everyone hacks their way through their initial nextcloud configuration.

Is this not unpacking to a folder under the webroot? That’s why I thought your address would be /nextcloud.

That had me confused too. Perhaps that is part of why it isn’t working… I don’t know.

I do know that I had the sub.domain.dom working just fine pointing it work from /var/www/html/whatever directory when testing it out previously and in previous iterations of the webserver… it’s just that it doesn’t seem to work with my NC installation.

It was this line in the nginx /etc/nginx/sites-available/sub.domain.dom config file that had me believing this was a web root install:

root /var/www/html/nextcloud/;

So all URLs you try on sub.domain.dom are currently giving you a 404?

What do the error and access logs for nginx say when you get the 404?

Any chance DNS was changed so requests are now bouncing off another machine?

Do the IPs in /etc/hosts and DNS match for sub.domain.dom?

Unless you tracked all the changes and feel confident backing all of them out so you can restart from a known baseline, personally, I’d nuke the machine and start over.

I was having simaler issues, you may try unlinking the default page. The command to unlink it is

sudo unlink /etc/nginx/sites-enabled/default

Then on the computer hosting Next Cloud you should be able to do the initial install by pointing your browser to localhost.

The other thing you may be missing some php modules.

here is the install cli I use you may need to adjust it for your verions of php.

sudo apt install php7.3 php7.3-fpm php7.3-mysql php-common php7.3-cli php7.3-common php7.3-json php7.3-opcache php7.3-readline php7.3-mbstring php7.3-xml php7.3-gd php7.3-curl php7.3-bcmath php7.3-gmp