Docker: Internal Server Error

[d14na]

Running Docker container latest. Everything was working fine (apps installed, mobile connected, etc), until I moved the volume files to a larger volume 10GB to 50GB, and then:

Internal Server Error

The server was unable to complete your request.
If this happens again, please send the technical details below to the server administrator.
More details can be found in the server log.

Pretty useless error message and I have NO idea where to find server log. I'm not even sure what filename I'm looking for. There is a file under nextcloud_nextcloud/_data named nextcloud.log. Is that the server log? I've tried removing that file to see if it would be re-created and/or update after a restart of the container and a refresh of the error page, but nothing.

---

sure I could just start all over again, but fyi, this is the second time I've tried using Nextcloud (the first was a few years ago) and I recall having the same issue back then; Internal Server Error and nothing else in terms of error details. I guess this is fine for the end-user, they just call the admin, but where's the support for the admin? I would love nothing more than for this open-source cloud solution to work, but if nextcloud is really this fragile, then I guess its just not the solution I'm looking for. Back to Google?? (ugh!)

Obviously pretty disappointed by this, but any and all support are very much appreciated.
Cheers!

__EDIT:__
Went back through the docs to find mention of a Nextcloud Server Log File. Does this file NOT exist unless its enabled in the Admin Page??

Also, when I connect to the container and try to view the Webserver Log Files, this is what I get:

root@c6cd43acc381:~# ls -l /var/log/apache2
total 0
lrwxrwxrwx 1 www-data www-data 11 Oct 17 14:28 access.log -> /dev/stdout
lrwxrwxrwx 1 www-data www-data 11 Oct 17 14:28 error.log -> /dev/stderr
lrwxrwxrwx 1 www-data www-data 11 Oct 17 14:28 other_vhosts_access.log -> /dev/stdout

Does this get written somewhere on the host? This could just be a docker thing, I'm really not sure, but either way, it would be nice to find these log files, and eventually solve "Internal Server Error".

[kesselb]

There is a file under nextcloud_nextcloud/_data named nextcloud.log. Is that the server log

Yes.

[d14na]

There is a file under nextcloud_nextcloud/_data named nextcloud.log. Is that the server log

Yes.

@kesselb thank you so much for the confirmation.

nextcloud.log has been my focus point since this problem started (really haven't had much else to go on).

Here is the orignal file (after I renamed it):
-rw-r----- 1 root root 7318 Oct 31 04:48 nextcloud-20191031.log

_(there really wasn't anything here, other than a failed login attempt via mobile)_

Here is the latest log file:
-rw-r--r-- 1 root root 0 Oct 31 07:23 nextcloud.log

when i refresh the START page, I can see (under Technical details) that the Request ID: changes each time; but it doesn't appear to get written ANYWHERE. That's the error message I'm looking for. __Would an error like Internal Server Error be written to /data/nextcloud.log; if not, then where would that error be written to?__ If this is a permissions issue, I guess I could try chmod 777 -R ./nextcloud_nextcloud/, but what answers would that really provide?

in this case, it would NOT be a big issue to just start all over with a fresh Docker container and Volume, however, I __KNOW__ this will __NOT__ be the last time I see Internal Server Error and be clueless as to what that means. If I am ever to use Nextcloud, this is a problem I MUST get a handle on.

[laurentS]

@d14na I am not sure if I have the exact same error as you, but I got the same looking error message after upgrading, and like you, nothing useful in nextcloud.log. But I found some good hints when stopping my setup with docker-compose down and then docker-compose up (without the -d). This spits out logs to your console, and in my case, the issue seems to come from the postgresql upgrade from 11 to 12.

db_1                     | 2019-10-31 22:43:20.025 UTC [1] FATAL:  database files are incompatible with server
db_1                     | 2019-10-31 22:43:20.025 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 12.0.

Hope this helps! (now I need to figure out how to properly upgrade my database files, this SO answer might help)

[laurentS]

Following up on my comment above, I feel like the example docker-compose.yml files should pin the db version, to avoid random db upgrades without warning which break a running setup. So instead of image: postgres:alpine, it would probably make more sense to use image: postgres:11-alpine or whatever version you want.

[d14na]

@laurentS thank you!! i took your advice to remove the -d, and it does in fact give me clear error logs.

PHP Warning:  fileperms(): stat failed for /var/www/html/data/nextcloud.log in /var/www/html/lib/private/Log/File.php on line 85

Here is File.php:

        public function write(string $app, $message, int $level) {
                $entry = $this->logDetailsAsJSON($app, $message, $level);
                $handle = @fopen($this->logFile, 'a');
line 85--->     if ($this->logFileMode > 0 && (fileperms($this->logFile) & 0777) != $this->logFileMode) {
                    @chmod($this->logFile, $this->logFileMode);
                }

I've tried changing the permission: chmod 777 nextcloud.log, but still "Internal Server Error". I have confirmed that simply recreating the volume folder DOES fix the error, and I suppose I could then copy the data back, but I'm still determined to SOLVE this, and not just start over. The new logs are a tremendous help, @laurentS thanks again!!

---

__EDIT:__

More clues:

{
    "reqId": "6BEh1Sy1xojii4nzxu5Z",
    "level": 3,
    "time": "2019-11-01T02:37:45+00:00",
    "remoteAddr": "XXX",
    "user": "--",
    "app": "index",
    "method": "GET",
    "url": "\\/",
    "message": {
        "Exception": "OC\\\\HintException",
        "Message": "Can't write into config directory!",
        "Code": 0,
        "Trace": [{
            "file": "\\/var\\/www\\/html\\/lib\\/private\\/Config.php",
            "line": 132,
            "function": "writeData",
            "class": "OC\\\\Config",
            "type": "->",
            "args": []
        }, {
            "file": "\\/var\\/www\\/html\\/lib\\/private\\/SystemConfig.php",
            "line": 100,
            "function": "setValue",
            "class": "OC\\\\Config",
            "type": "->",
            "args": ["instanceid", "ocqlrfgvd1vg"]
        }, {
            "file": "\\/var\\/www\\/html\\/lib\\/private\\/legacy\\/util.php",
            "line": 1152,
            "function": "setValue",
            "class": "OC\\\\SystemConfig",
            "type": "->",
            "args": ["instanceid", "ocqlrfgvd1vg"]
        }, {
            "file": "\\/var\\/www\\/html\\/lib\\/base.php",
            "line": 415,
            "function": "getInstanceId",
            "class": "OC_Util",
            "type": "::",
            "args": []
        }, {
            "file": "\\/var\\/www\\/html\\/lib\\/base.php",
            "line": 642,
            "function": "initSession",
            "class": "OC",
            "type": "::",
            "args": []
        }, {
            "file": "\\/var\\/www\\/html\\/lib\\/base.php",
            "line": 1081,
            "function": "init",
            "class": "OC",
            "type": "::",
            "args": []
        }, {
            "file": "\\/var\\/www\\/html\\/index.php",
            "line": 40,
            "args": ["\\/var\\/www\\/html\\/lib\\/base.php"],
            "function": "require_once"
        }],
        "File": "\\/var\\/www\\/html\\/lib\\/private\\/Config.php",
        "Line": 251,
        "Hint": "This can usually be fixed by giving the webserver write access to the config directory. See https:\\/\\/docs.nextcloud.com\\/server\\/17\\/go.php?to=admin-dir_permissions",
        "CustomMessage": "--"
    },
    "userAgent": "XXX",
    "version": ""
}

definitely a permissions issue; and this time I'm given a link to docs:
https://docs.nextcloud.com/server/17/go.php?to=admin-dir_permissions

[d14na]

__SOLVED!!__

Directory permissions on the Nextcloud data requires __www-data:root as the user.__ Must have changed to root:root when copying/moving the folders back and forth (not sure how or why though); and that's why it couldn't write to the folder. Refreshed the start page, and everything is exactly as I left it, with an additional 40GB to store my files.

Much thanks to @kesselb and @laurentS for their support.

[jtagcat]

If you move often (untested) this could work in your compose file:
user: "www-data:root"

[OggyParx]

Resolved by the solution of @d14na

chown -R www-data:root /your-directory-of-nextcloud

And the same problem with the data base

chown -R 999:root /your-directory-of-data-base

Thanks! :+1:

[Motophan]

This happens in current versions of nextcloud through updates. Can this be marked unresolved critical priority?

[unixbird]

This is actually happening to me now as well after an upgrade to nextcloud 20. I checked folder permissions and they are correct. The DB hasnt changed (although im using docker run instead of compose" but its not giving any probable error. I really dont want to completely scrape and make a new docker instance

[unixbird]

Alright this issue ALSO seems to be from if your nextcloud instance cannot connect to the DB. In my case the container for the db changed ip and i had to go into config.php and change it. After doing this it started working again

[lazmol]

Hi @unixbird,
could you tell me how to check the ip of the db abd how to change in config.php. I am also using nextcloud docker.
To me the permissions seem to be fine as well.
Thanks in advance!

[unixbird]

@lazmol all you need to do is docker insepct containerthathasdb then find the ip. Then all I had to do was just docker exec into the nextcloud container and change the config.php manually inside of it