Alright, did some test uploads and my data is stored in the /mnt/user/nextcloud folder.  Now, I just need to figure out the mobile apps

When you're inputting paths into the nextcloud config it shouldn't be referring to /mnt/user/nextcloud, it should be referring to /data.

 

Inside the container there is no such thing as /mnt/user/nextcloud ONLY it's mapped location /data

 

I'm afraid you're going to need to wipe this and start afresh.

 

Also why is your appdata for MariaDB in /mnt/cache/mariadb

 

More conventionally all the /config folders are placed in a subdirectory of /mnt/cache/appdata

 

eg. /mnt/cache/appdata/mariadb

 

EDIT: Sorry, missed Sparklyballs' posts because I'm using my mobile...

 

Sent from my LG-H815 using Tapatalk

 

Getting an iconv error using LDAP module.  There is a bug report on the nextcloud website (https://github.com/nextcloud/server/issues/272) but it points to a PHP bug/a specific way to set docker.  I dont know if this information (https://github.com/docker-library/php/issues/240) can be implemented in our docker so it works properly?

Getting an iconv error using LDAP module.  There is a bug report on the nextcloud website (https://github.com/nextcloud/server/issues/272) but it points to a PHP bug/a specific way to set docker.  I dont know if this information (https://github.com/docker-library/php/issues/240) can be implemented in our docker so it works properly?

 

 

Reading the various links, it's a php bug beyond our control.

Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule.

Thanks for the help, it is very much appreciated.  Two questions. Can I edit MariaDB to move the config folder to the cache/appdata location without causing problems or should I nuke it and start over?

 

Second - Is there an OSX app for nextcloud?  I only found one for owncloud.

 

Thanks again!

 

Greg

 

When you're inputting paths into the nextcloud config it shouldn't be referring to /mnt/user/nextcloud, it should be referring to /data.

 

Inside the container there is no such thing as /mnt/user/nextcloud ONLY it's mapped location /data

 

I'm afraid you're going to need to wipe this and start afresh.

 

Also why is your appdata for MariaDB in /mnt/cache/mariadb

 

More conventionally all the /config folders are placed in a subdirectory of /mnt/cache/appdata

 

eg. /mnt/cache/appdata/mariadb

 

EDIT: Sorry, missed Sparklyballs' posts because I'm using my mobile...

 

Sent from my LG-H815 using Tapatalk

Yes you can copy the appdata to a new location.  I have done so on several occasions.  Personally I use midnight commander from the terminal (type mc )

 

I don't think nextcloud have their own desktop apps yet, but the Owncloud one works fine on Windows and I would imagine it also would for MacOS.

 

Sent from my LG-H815 using Tapatalk

 

 

Awesome.  Thanks!  I will fix it tonight.

Getting an iconv error using LDAP module.  There is a bug report on the nextcloud website (https://github.com/nextcloud/server/issues/272) but it points to a PHP bug/a specific way to set docker.  I dont know if this information (https://github.com/docker-library/php/issues/240) can be implemented in our docker so it works properly?

 

 

Reading the various links, it's a php bug beyond our control.

Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule.

 

Ya I agree with that.  I was doing a bit more digging and owncloud is working using LDAP in the same AD environment and the main difference I see is related to a iconv problem I think.  In the alpine image the php extention for inconv is undefined.

 

iconv

iconv support => enabled
iconv implementation => unknown
iconv library version => unknown

Directive => Local Value => Master Value
iconv.input_encoding => no value => no value
iconv.internal_encoding => no value => no value
iconv.output_encoding => no value => no value

 

The implementation is unknown.  From what I can find the way to resolve this is to use the libiconv extension instead.  This seems to be an issue on Alpine.  Is it possible to build using this instead of iconv?

 

Edit: Both dockers are running PHP 5.6.24 so I dont think its a pure PHP issue.

Getting an iconv error using LDAP module.  There is a bug report on the nextcloud website (https://github.com/nextcloud/server/issues/272) but it points to a PHP bug/a specific way to set docker.  I dont know if this information (https://github.com/docker-library/php/issues/240) can be implemented in our docker so it works properly?

 

 

Reading the various links, it's a php bug beyond our control.

Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule.

 

Ya I agree with that.  I was doing a bit more digging and owncloud is working using LDAP in the same AD environment and the main difference I see is related to a iconv problem I think.  In the alpine image the php extention for inconv is undefined.

 

iconv

iconv support => enabled
iconv implementation => unknown
iconv library version => unknown

Directive => Local Value => Master Value
iconv.input_encoding => no value => no value
iconv.internal_encoding => no value => no value
iconv.output_encoding => no value => no value

 

The implementation is unknown.  From what I can find the way to resolve this is to use the libiconv extension instead.  This seems to be an issue on Alpine.  Is it possible to build using this instead of iconv?

 

no, because it's not just an alpine issue, the bug is in many implementations of php from 2008 onwards and including php7.

 

it is up to nextcloud to resolve this, if it were "fixed" and nextcloud then made neccessary changes, the "fix" would have been a waste of time and effort.

 

 

Getting an iconv error using LDAP module.  There is a bug report on the nextcloud website (https://github.com/nextcloud/server/issues/272) but it points to a PHP bug/a specific way to set docker.  I dont know if this information (https://github.com/docker-library/php/issues/240) can be implemented in our docker so it works properly?

 

 

Reading the various links, it's a php bug beyond our control.

Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule.

 

Ya I agree with that.  I was doing a bit more digging and owncloud is working using LDAP in the same AD environment and the main difference I see is related to a iconv problem I think.  In the alpine image the php extention for inconv is undefined.

 

iconv

iconv support => enabled
iconv implementation => unknown
iconv library version => unknown

Directive => Local Value => Master Value
iconv.input_encoding => no value => no value
iconv.internal_encoding => no value => no value
iconv.output_encoding => no value => no value

 

The implementation is unknown.  From what I can find the way to resolve this is to use the libiconv extension instead.  This seems to be an issue on Alpine.  Is it possible to build using this instead of iconv?

 

no, because it's not just an alpine issue, the bug is in many implementations of php from 2008 onwards and including php7.

 

it is up to nextcloud to resolve this, if it were "fixed" and nextcloud then made neccessary changes, the "fix" would have been a waste of time and effort.

 

Ok.  Whatever, I just updated my owncloud docker to nextcloud and its working fine so i'll just use that.  I was just reporting a bug but if no one wants to look into it that's fine.  Its not php as its the same version in both my dockers and its not owncloud as I have it running in another docker now fine.  THe only difference is the base distro and the iconv module showing up as unknown instead of 2.19 as it does in the other docker.

For the life of me I cannot get nginx to work with a cert I bought from ssls.com. I combine the crt and bundle and copy them to the "keys" directory. restart the docker app and my site is completely unreachable. No security errors or anything, just not reachable. Throw the self signed cert and key back on back works right away. What gives?

For the life of me I cannot get nginx to work with a cert I bought from ssls.com. I combine the crt and bundle and copy them to the "keys" directory. restart the docker app and my site is completely unreachable. No security errors or anything, just not reachable. Throw the self signed cert and key back on back works right away. What gives?

 

Do you want to post a copy of the nginx config file?

I have changed nothing in the conf file. i simple update the certs in the keys folder (giving them the same names as the self signed) restart and get nothing. i can send you the file but it's the default file that works with the self signed certs. nothing more, nothing less.

 

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

server {
  listen 80;
  server_name _;
  # enforce https
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name _;

  ssl_certificate /config/keys/cert.crt;
  ssl_certificate_key /config/keys/cert.key;

  # Add headers to serve security related headers
  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Robots-Tag none;
  add_header X-Download-Options noopen;
  add_header X-Permitted-Cross-Domain-Policies none;

  # Path to the root of your installation
  root /config/www/nextcloud/;
  # set max upload size
  client_max_body_size 10G;
  fastcgi_buffers 64 4K;

  # Disable gzip to avoid the removal of the ETag header
  gzip off;

  # Uncomment if your server is build with the ngx_pagespeed module
  # This module is currently not supported.
  #pagespeed off;

  index index.php;
  error_page 403 /core/templates/403.php;
  error_page 404 /core/templates/404.php;

  rewrite ^/.well-known/carddav /remote.php/dav/ permanent;
  rewrite ^/.well-known/caldav /remote.php/dav/ permanent;

  # The following 2 rules are only needed for the user_webfinger app.
  # Uncomment it if you're planning to use this app.
  #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
  #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

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

  location ~ ^/(build|tests|config|lib|3rdparty|templates|data)/ {
    deny all;
  }

  location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
    deny all;
  }

  location / {

    rewrite ^/remote/(.*) /remote.php last;

    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

    try_files $uri $uri/ =404;
  }

  location ~ \.php(?|/) {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include /etc/nginx/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param HTTPS on;
    fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
    fastcgi_pass php-handler;
    fastcgi_intercept_errors on;
  }

  # Adding the cache control header for js and css files
  # Make sure it is BELOW the location ~ \.php(?|/) { block
  location ~* \.(?:css|js)$ {
    add_header Cache-Control "public, max-age=7200";
    # Add headers to serve security related headers
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    # Optional: Don't log access to assets
    access_log off;
  }

  # Optional: Don't log access to other assets
  location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|swf)$ {
    access_log off;
  }
}

Do an 'ls -lah' on the directory and make sure the user/group on those files is correct? Also check permissions.

"cert" are the self signed

 

"cert5" are my paid for cert/key..

 

-rw-r--r-- 1 nobody users 1.3K Aug 15 18:12 cert.crt
-rw-r--r-- 1 nobody users 1.7K Aug 15 18:12 cert.key
-rw-rw-rw- 1 nobody users 7.4K Aug 15 23:11 cert5.crt
-rw-rw-rw- 1 nobody users 1.8K Aug 15 23:11 cert5.key

How are you trying to access the site, via the IP or the URL?

both. neither are a no go. as soon as rename the self signed keys to match the conf file, the site works fine. when i rename the bought cert to match the conf file, it's completely unreachable by internal ip or domain. this certainly is odd. i blew up the container and did a reinstall twice. no dice

 

The only thing I changed from the default install were the directory mapping. Changed them to this..

 

nextcloud	lsiodev/nextcloud:latest	 up-to-date	443/tcp  172.17.0.XXX:8000	/data  /mnt/user/Docker_Apps/NEXTCLOUD/data
/config  /mnt/user/Docker_Apps/NEXTCLOUD/config

From memory I had a similar problem, I sorted it by using a .pem file instead of a .crt.

 

Here is the excerpt from my guide a few pages back, give it a go?

 

Navigate to the nextcloud keys folder, in my case:

/mnt/user/appdata/nextcloud/keys

Remove/rename the current cert.key and cert.crt files.

Run this command:

openssl req -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr

Follow the wizard through to generate your cert.csr and cert.key. Use the cert.csr to activate your newly purchased SSL cert with ssls.com

Using the SSL cert information make a file called cert.crt using the SSL cert and another called inter.crt with the intermediate CA.

Run this command to concatenate the two new files:

cat cert.crt inter.crt >> cert.pem

 

The relevent line in my config file:

ssl_certificate /config/keys/cert.pem;

I knew it wasn't going to work because I verified my crt file was already in pem format. Did what you said anyway and had the same result. am i hosed? lol!!

I knew it wasn't going to work because I verified my crt file was already in pem format. Did what you said anyway and had the same result. am i hosed? lol!!

 

After you created the .pem file did you update nginx config to look for a .pem file instead of .crt?

yep... blowing up my certs and getting a reissue. hoping that helps/works.

got a new cert reissued and now all is well, lol! Thanks for your help. Not sure what happened before!

got a new cert reissued and now all is well, lol! Thanks for your help. Not sure what happened before!

 

Really unlucky I guess, congrats on having it sorted.

Any chance of getting Postgres support added to the Docker? I'm running MariaDB just for this container, while everything else can use Postgres. Pretty sure all you need is the php5-pgsql package (Postgres will show up in the setup wizard once the extension is properly enabled).