CD99

Members
  • Posts

    11
  • Joined

  • Last visited

Posts posted by CD99

  1. Mine is on 6.9.2, and this part of the guide has no actual steps for what to do if you are not on 6.10.

     

    To reiterate, the GUI is not accessible via web or on the server directly. The GUI also does not load even when trying safemode. I can however get to the command line

     

    Steps I've tried:

    1) Loading safemode

    2) Removing all drives and just booting normally, safemode, etc

    3) Copying all contents to a new thumbdrive and running that

     

    This issue arose when I was away, so I can't say what happened. I do have auto update for docker containers set, but if this does mess it up, I could usually use safemode to disable / remove the offending docker / app. Unfortunately, this does not work.

  2. Hey all, I can't access my unraid server GUI anymore, from the web or directly.

     

    Initially i thought it was a drive issue (as I saw errors). I've now tried removing all the drives, and booting in safe mode. Neither of these helps.

     

    I'm not sure what changed, as I had been away for some months and the OS stopped responding to webgui when I was away (but the docker services were still running).

     

    All I get when I try to access it is (last ~50 lines of the diagnostics syslog) :

    Quote

    May  4 15:29:24 NAS kernel: md: import_slot: 29 missing
    May  4 15:29:24 NAS emhttpd: import 30 cache device: no device
    May  4 15:29:24 NAS emhttpd: import 31 cache device: no device
    May  4 15:29:24 NAS emhttpd: import flash device: sda
    May  4 15:29:24 NAS root: Starting apcupsd power management:  /sbin/apcupsd
    May  4 15:29:24 NAS emhttpd: read SMART /dev/sda
    May  4 15:29:24 NAS apcupsd[2108]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded
    May  4 15:29:24 NAS apcupsd[2108]: NIS server startup succeeded
    May  4 15:29:24 NAS emhttpd: Starting services...
    May  4 15:29:24 NAS emhttpd: shcmd (9): /etc/rc.d/rc.samba restart
    May  4 15:29:27 NAS root: Starting Samba:  /usr/sbin/smbd -D
    May  4 15:29:27 NAS root:                  /usr/sbin/nmbd -D
    May  4 15:29:27 NAS root:                  /usr/sbin/wsdd
    May  4 15:29:27 NAS root:                  /usr/sbin/winbindd -D
    May  4 15:29:27 NAS emhttpd: shcmd (13): /etc/rc.d/rc.avahidaemon start
    May  4 15:29:27 NAS root: Starting Avahi mDNS/DNS-SD Daemon:  /usr/sbin/avahi-daemon -D
    May  4 15:29:27 NAS avahi-daemon[2160]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214).
    May  4 15:29:27 NAS avahi-daemon[2160]: Successfully dropped root privileges.
    May  4 15:29:27 NAS avahi-daemon[2160]: avahi-daemon 0.8 starting up.
    May  4 15:29:27 NAS avahi-daemon[2160]: Successfully called chroot().
    May  4 15:29:27 NAS avahi-daemon[2160]: Successfully dropped remaining capabilities.
    May  4 15:29:27 NAS avahi-daemon[2160]: Loading service file /services/sftp-ssh.service.
    May  4 15:29:27 NAS avahi-daemon[2160]: Loading service file /services/smb.service.
    May  4 15:29:27 NAS avahi-daemon[2160]: Loading service file /services/ssh.service.
    May  4 15:29:27 NAS avahi-daemon[2160]: Joining mDNS multicast group on interface br0.IPv4 with address 10.10.10.10.
    May  4 15:29:27 NAS avahi-daemon[2160]: New relevant interface br0.IPv4 for mDNS.
    May  4 15:29:27 NAS avahi-daemon[2160]: Joining mDNS multicast group on interface lo.IPv6 with address ::1.
    May  4 15:29:27 NAS avahi-daemon[2160]: New relevant interface lo.IPv6 for mDNS.
    May  4 15:29:27 NAS avahi-daemon[2160]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
    May  4 15:29:27 NAS avahi-daemon[2160]: New relevant interface lo.IPv4 for mDNS.
    May  4 15:29:27 NAS avahi-daemon[2160]: Network interface enumeration completed.
    May  4 15:29:27 NAS avahi-daemon[2160]: Registering new address record for 10.10.10.10 on br0.IPv4.
    May  4 15:29:27 NAS avahi-daemon[2160]: Registering new address record for ::1 on lo.*.
    May  4 15:29:27 NAS avahi-daemon[2160]: Registering new address record for 127.0.0.1 on lo.IPv4.
    May  4 15:29:27 NAS emhttpd: shcmd (14): /etc/rc.d/rc.avahidnsconfd start
    May  4 15:29:27 NAS root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon:  /usr/sbin/avahi-dnsconfd -D
    May  4 15:29:27 NAS avahi-dnsconfd[2170]: Successfully connected to Avahi daemon.
    May  4 15:29:28 NAS avahi-daemon[2160]: Server startup complete. Host name is NAS.local. Local service cookie is 3087488982.
    May  4 15:29:28 NAS avahi-daemon[2160]: Service "NAS" (/services/ssh.service) successfully established.
    May  4 15:29:28 NAS avahi-daemon[2160]: Service "NAS" (/services/smb.service) successfully established.
    May  4 15:29:28 NAS avahi-daemon[2160]: Service "NAS" (/services/sftp-ssh.service) successfully established.
    May  4 15:29:29 NAS emhttpd: stale configuration
    May  4 15:29:29 NAS emhttpd: shcmd (19): /etc/rc.d/rc.php-fpm start
    May  4 15:29:29 NAS root: Starting php-fpm  done
    May  4 15:29:29 NAS emhttpd: shcmd (20): /etc/rc.d/rc.nginx start
    May  4 15:29:29 NAS root: Starting Nginx server daemon...
    May  4 15:29:29 NAS ntpd[1914]: receive: Unexpected origin timestamp 0xe61c8db9.fc417f66 does not match aorg 0000000000.00000000 from [email protected] xmt 0xe61c8db9.c3a5daf6
    May  4 15:29:33 NAS login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=  user=root
    May  4 15:29:35 NAS login: FAILED LOGIN 1 FROM tty1 FOR root, Authentication failure
    May  4 15:29:44 NAS login: pam_unix(login:session): session opened for user root(uid=0) by LOGIN(uid=0)
    May  4 15:29:44 NAS login: ROOT LOGIN ON tty1

     

    Happy to include any other files from the diagnostics if needed.

     

    Thank you everyone for the assistance

     

    Edit: Its on Unraid 6.9.2 if that helps

     

     

  3. The best thing about unraid, in my view, is that its relatively easy to set up and then automate to run. Its one of the only non-windows system I haven't actually broken from trying to change settings, etc. I remember my last attempt at setting up my pfsense box fucked up to the extent that I gave up and reinstalled it. I'm happy beyond my initial trial and error my UnRaid system has been going strong.

     

    As for something I'd like to see - it would be to have backup functionalities in-built to the system, such that we can back up the whole system to another server /  cloud provider.

     

     

  4. On 2/19/2019 at 3:17 AM, snowboardjoe said:

    How did you "jack" with your MariaDB container? Did you modify your /mnt/user/appdata/mariadb structure?

     

    Your configuration for Nextcloud and your data should already be in two different filesystems and/or directories. So, your data should remain untouched. If I were to start over and no other application is storing data in MariaDB):

     

    • Stop Nextcloud
    • Stop MariaDB
    • Destroy all configuration and data for MariaDB.
    • Destory all configuration for NextCloud.
    • Start MariaDB and let it initialize.
    • Start Nextcloud and let it initialize.
    • Restore and custom configurations to Nextcloud (save a copy of your config.php?).
    • Setup Nextcloud and point to your existing data and run a scan of what's there.

    I've borked my Nextcloud before when I was setting things up by losing the admin password. I was able to modify the DB to get that back and get back on track again without needed to restore anything. 

    I've now done this step over 4 times over the past 30 days and somehow its failed. I've tinkered with the settings as well as tried restarting from scratch (deleting all the docker images and saved files)  As for Maria DB, i just used linuxserver's docker with the settings advised(as per spaceinvaderone's tutorial). Since I had not put any data important in it - it wasn't a loss other than having to follow the step one by one again. Nextcloud also runs perfectly on the local server as long as I use the local network on local IP. Letsencrypt meanwhile validates the domains correctly as indicated by the logs of the docker. So somewhere between letsencrypt and the nextcloud docker something falters. I'm curious if anyone had to do the settings differently?

     

    I did try to follow Linuxserver's tutorial but it felt too technical for me, especially as there are some parts that are not as clear or doesn;t feel step by step like Spaceinvaderone's tutorial

     

    The only things I can think of that i did differently is did differently is edit the configurations using CA Config Editor (instead of a text editor) and use Cloudfare as the DNS

  5. Hi all, not sure if this is the right place to raise this - but after trying many things I have to ask for help on this. I have followed Spaceinvaderone's tutorial to set up Nextcloud and Letsencrypt (linuxserver's dockers). Nextcloud now works on my LAN but I cant get it to work with a domain or letsencrypt.

     

    Letsencrypt correctly validates my domain but for some reason, somewhere between that and Nextcloud, the forwarding doesnt work. My domain is with Namecheap, and the DNS is with Cloudfare. I've tried setting this to directly connect via A record and CName (via duckdns) but each time, the domain fails to resolve at the server. I have port forwarding set correctly for letsencrypt on my router.

     

    As per Spaceinvaderone's tutorial, i have changed the network of the 2 dockers to proxynet (Maria DB left on bridge), changed the settings on letsencrypt & nextcloud via CA config editor & renamed the file to .conf for the former.

     

    Can anyone help and let me know what I am missing

     

    /mnt/user/appdata/letsencrypt/nginx/proxy-confs/nextcloud.subdomain.conf

    server {
        listen 443 ssl;
        listen [::]:443 ssl;

        server_name nextcloud.*;

        include /config/nginx/ssl.conf;

        client_max_body_size 0;

        location / {
            include /config/nginx/proxy.conf;
            resolver 127.0.0.11 valid=30s;
            set $upstream_nextcloud nextcloud;
            proxy_max_temp_file_size 2048m;
            proxy_pass https://$upstream_nextcloud:443;
        }
    }

     

    ---> renamed to nextcloud.subdomain.conf

     

    /mnt/user/appdata/nextcloud/www/nextcloud/config/config.php

      array (
        0 => '10.0.0.100:444',
        1 => 'nextcloud.*mydomain*.com',
      ),
      'dbtype' => 'mysql',
      'version' => '15.0.2.0',
      'trusted_proxies' => ['letsencrypt'], 
      'overwrite.cli.url' => 'https://nextcloud.*mydomain*.com',
      'overwritehost' => 'nextcloud.*mydomain*.com',
      'overwriteprotocol' => 'https',

     

     

    Note: Spaceinvaderone's tutorial does not show the need to add 'trusted_proxies' => ['letsencrypt'], but adding or leaving out this line does not make a difference