[Support] Linuxserver.io - Heimdall


Recommended Posts

24 minutes ago, aptalca said:

Do you have htpasswd file in both letsencrypt and heimdall? If so, delete the one in heimdall.

 

If not, clarify what you're doing. It's not clear where you're running the htpasswd command and where you're deleting the default file.

 

I just found these errors in letsencrypt log so i was just about to ask where the htpasswd file should be. I only had it in heimdall so i should copy it to the letsencrypt config folder instead?

 

for reference i ran docker exec -it heimdall htpasswd -c /config/nginx/.htpasswd <username> in the unraid console/terminal and I deleted the default file from the heimdal folder /nginx/site-confs. 

 

2019/09/05 12:15:05 [error] 378#378: *9 open() "/config/nginx/.htpasswd" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: links.*, request: "GET / HTTP/2.0", host: "x.x.com"

 

Edited by uaborne
Link to comment
On 9/5/2019 at 1:40 PM, uaborne said:

 

I just found these errors in letsencrypt log so i was just about to ask where the htpasswd file should be. I only had it in heimdall so i should copy it to the letsencrypt config folder instead?

 

for reference i ran docker exec -it heimdall htpasswd -c /config/nginx/.htpasswd <username> in the unraid console/terminal and I deleted the default file from the heimdal folder /nginx/site-confs. 

 


2019/09/05 12:15:05 [error] 378#378: *9 open() "/config/nginx/.htpasswd" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: links.*, request: "GET / HTTP/2.0", host: "x.x.com"

 

Then you enabled http auth in heimdall. Don't enable it in letsencrypt. Doubling up will cause issues.

Link to comment
  • 1 month later...
  • 4 weeks later...

It's a great plugin that I'm using as a landing page for my website, however, I keep getting this error after a few refreshes.  Any thoughts?

 

ETA: I have found that if I go delete cookies/history/etc from the browser then it works again for awhile.

 

var/www/localhost/heimdall/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php
     *
     * @return bool
     */
    public function shouldAddXsrfTokenCookie()
    {
        return $this->addHttpCookie;
    }
 
    /**
     * Add the CSRF token to the response cookies.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Symfony\Component\HttpFoundation\Response  $response
     * @return \Symfony\Component\HttpFoundation\Response
     */
    protected function addCookieToResponse($request, $response)
    {
        $config = config('session');
 
        $response->headers->setCookie(
            new Cookie(
                'XSRF-TOKEN', $request->session()->token(), $this->availableAt(60 * $config['lifetime']),
                $config['path'], $config['domain'], $config['secure'], false, false, $config['same_site'] ?? null
            )
        );
 
        return $response;
    }
 
    /**
     * Determine if the cookie contents should be serialized.
     *
     * @return bool
     */
    public static function serialized()
    {
        return EncryptCookies::serialized('XSRF-TOKEN');
    }
}
 
Arguments
"Call to a member function setCookie() on null"

 

 

One thing that I see is that it is referring to user "abc" which isn't a user of mine.

 

Server/Request Data
USER	
"abc"
HOME	
"/config"
HTTP_COOKIE	
"remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IkVLQXc3VFo3T1lGWWtkR0lPcHk2U3c9PSIsInZhbHVlIjoiYWdvMDE2Qmc1NzU2UEZXZGcydkJldk91VUFiZGJxUExxWndScV ▶"
HTTP_ACCEPT_LANGUAGE	
"en-US,en;q=0.9"
HTTP_ACCEPT_ENCODING	
"gzip, deflate, br"
HTTP_SEC_FETCH_MODE	
"navigate"
HTTP_SEC_FETCH_SITE	
"none"
HTTP_ACCEPT	
"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3"
HTTP_SEC_FETCH_USER	
"?1"
HTTP_USER_AGENT	
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36"
HTTP_UPGRADE_INSECURE_REQUESTS	
"1"
HTTP_DNT	
"1"
HTTP_X_FORWARDED_SSL	
"on"
HTTP_X_FORWARDED_HOST	
"home.mydomain.info"
HTTP_X_FORWARDED_PROTO	
"https"
HTTP_X_FORWARDED_FOR	
"192.168.5.1"
HTTP_X_REAL_IP	
"192.168.5.1"
HTTP_HOST	
"home.mydomain.info"
PHP_AUTH_PW	
""
PHP_AUTH_USER	
""
SCRIPT_FILENAME	
"/var/www/localhost/heimdall/public/index.php"
REDIRECT_STATUS	
"200"
SERVER_NAME	
"_"
SERVER_PORT	
"443"
SERVER_ADDR	
"172.17.0.4"
REMOTE_PORT	
"33070"
REMOTE_ADDR	
"172.17.0.1"
SERVER_SOFTWARE	
"nginx/1.16.1"
GATEWAY_INTERFACE	
"CGI/1.1"
HTTPS	
"on"
REQUEST_SCHEME	
"https"
SERVER_PROTOCOL	
"HTTP/1.1"
DOCUMENT_ROOT	
"/var/www/localhost/heimdall/public"
DOCUMENT_URI	
"/index.php"
REQUEST_URI	
"/"
SCRIPT_NAME	
"/index.php"
CONTENT_LENGTH	
""
CONTENT_TYPE	
""
REQUEST_METHOD	
"GET"
QUERY_STRING	
""
FCGI_ROLE	
"RESPONDER"
PHP_SELF	
"/index.php"
REQUEST_TIME_FLOAT	
1573516169.3208
REQUEST_TIME	
1573516169
APP_NAME	
"Heimdall"
APP_ENV	
"local"
APP_KEY	
"base64:TaZDqEor6EbObZWuK1w0P4wcG1bW/2fwbZIvkgGuFjY="
APP_DEBUG	
"true"
APP_LOG_LEVEL	
"debug"
APP_URL	
"http://localhost"
DB_CONNECTION	
"sqlite"
DB_DATABASE	
"app.sqlite"
BROADCAST_DRIVER	
"log"
CACHE_DRIVER	
"file"
SESSION_DRIVER	
"file"
SESSION_LIFETIME	
"120"
QUEUE_DRIVER	
"database"
REDIS_HOST	
"127.0.0.1"
REDIS_PASSWORD	
"null"
REDIS_PORT	
"6379"
MAIL_DRIVER	
"smtp"
MAIL_HOST	
"smtp.mailtrap.io"
MAIL_PORT	
"2525"
MAIL_USERNAME	
"null"
MAIL_PASSWORD	
"null"
MAIL_ENCRYPTION	
"null"
PUSHER_APP_ID	
""
PUSHER_APP_KEY	
""
PUSHER_APP_SECRET	
""
PUSHER_APP_CLUSTER	
"mt1"
SHELL_VERBOSITY	
0
Environment Variables
APP_NAME	
"Heimdall"
APP_ENV	
"local"
APP_KEY	
"base64:TaZDqEor6EbObZWuK1w0P4wcG1bW/2fwbZIvkgGuFjY="
APP_DEBUG	
"true"
APP_LOG_LEVEL	
"debug"
APP_URL	
"http://localhost"
DB_CONNECTION	
"sqlite"
DB_DATABASE	
"app.sqlite"
BROADCAST_DRIVER	
"log"
CACHE_DRIVER	
"file"
SESSION_DRIVER	
"file"
SESSION_LIFETIME	
"120"
QUEUE_DRIVER	
"database"
REDIS_HOST	
"127.0.0.1"
REDIS_PASSWORD	
"null"
REDIS_PORT	
"6379"
MAIL_DRIVER	
"smtp"
MAIL_HOST	
"smtp.mailtrap.io"
MAIL_PORT	
"2525"
MAIL_USERNAME	
"null"
MAIL_PASSWORD	
"null"
MAIL_ENCRYPTION	
"null"
PUSHER_APP_ID	
""
PUSHER_APP_KEY	
""
PUSHER_APP_SECRET	
""
PUSHER_APP_CLUSTER	
"mt1"
SHELL_VERBOSITY	
0
Registered Handlers
0. Whoops\Handler\PrettyPageHandler

 

Edited by jlficken
Link to comment

It is behind the Nginx reverse proxy as well.

 

Here is my conf file contents (bolded lines were adding while trying to troubleshoot):

 

# make sure that your dns has a cname set for heimdall

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

    server_name heimdall.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_heimdall heimdall;

 

 

        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass_header       Set-Cookie;

 

 

        proxy_pass https://192.168.5.40:2443;
    }

 

Link to comment

Is there anyway to download version 2.1.13 as the latest version just doesn't seem to work right for me?

 

Figured it out....

1) Go to https://hub.docker.com/r/linuxserver/heimdall/tags

2) Find the version that you want

3) Find the Pull Command on the right side of the screen...it will look like - docker pull linuxserver/heimdall:2.1.13-ls45

4) Copy out the "linuxserver/heimdall:2.1.13-ls45"

5) Replace the "Repository" field in the Docker config

6) Click Apply

 

It's not too back so now I get to see if 2.1.13 works as that was the version I was told to use on Github.

Edited by jlficken
Link to comment
  • 1 month later...

I'm sure I'm setting something up wrong here. I've set up my reverse proxy through Spaceinvader One's excellent tutorial on how to set up Nextcloud and how to have it visible over the internet.  (which I've gotten other containers visible over the domain URL, however, they do not use 80/443, such as Ombi)
 

I'm sorry I need to preface this as I'm not super skilled in this realm. If you're asking me to do something, explain like I'm five.

 

The issue I have is trying to get heimdall visible over the internet through my subdomain server.myserver.com

 

However, when I try to access that I get the Letsencrypt's welcome screen. However, If I place the port I opened up in the firewall  at the end of the domain URL I can get in. It appears I need some way to make the system know which port to direct me to automatically, which I'm not sure how to do.

 

I obviously changed the default ports from 80 and 443 as these are already used.

 

The only change I made to heimdall.subdomain.conf file is to change it from heimdall.* to server.*

 

 

Edit: not sure what I did other than remove the information for port 80 in the container edit screen and left 443's port

Edited by Drazzilb
Link to comment
  • 2 weeks later...
On 12/25/2019 at 4:49 PM, Drazzilb said:

I'm sure I'm setting something up wrong here. I've set up my reverse proxy through Spaceinvader One's excellent tutorial on how to set up Nextcloud and how to have it visible over the internet.  (which I've gotten other containers visible over the domain URL, however, they do not use 80/443, such as Ombi)
 

I'm sorry I need to preface this as I'm not super skilled in this realm. If you're asking me to do something, explain like I'm five.

 

The issue I have is trying to get heimdall visible over the internet through my subdomain server.myserver.com

 

However, when I try to access that I get the Letsencrypt's welcome screen. However, If I place the port I opened up in the firewall  at the end of the domain URL I can get in. It appears I need some way to make the system know which port to direct me to automatically, which I'm not sure how to do.

 

I obviously changed the default ports from 80 and 443 as these are already used.

 

The only change I made to heimdall.subdomain.conf file is to change it from heimdall.* to server.*

 

 

Edit: not sure what I did other than remove the information for port 80 in the container edit screen and left 443's port

You should not have to open a port in the firewall, your reverse proxy should pick up the request on 443 and send the request to the heimdall's port.  That is the whole point of a reverse proxy, to block your internal ports from direct access from the internet.

 

It seems you need to configure heimdall in the letsencrypt config folder.  Take a look at the samples the linuxserver team already has ready:  https://github.com/linuxserver/reverse-proxy-confs

Link to comment

Can anyone explain how the "tag" functionality works. 
 

I have setup a few tabs with a separate tag. After doing that, i expected to be able to sort the main menu by tags, is that possible?

 

I would love to group them on the home page so that unraid, and other links can be kept separate

Edited by mihcox
Link to comment
  • 2 weeks later...

Hi,

with the latest version (i don't know the number) the container is broken, nginx won't start i have the following error:

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4

i pulled 2.2.2-ls68 and it's back to normal

Link to comment
1 hour ago, caplam said:

Hi,

with the latest version (i don't know the number) the container is broken, nginx won't start i have the following error:

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4


nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4

i pulled 2.2.2-ls68 and it's back to normal

Update again. That was already fixed last night

Link to comment

I think there might be a synchronisation problem.

With 2.2.2-ls68 tag it was ok.

Having read you post i updated container with latest tag. It was not ok.

I then tried with 2.2.2-ls70 (which is supposed at this time to be the latest) and it was ok.

I retried with latest tag and it was broken.

So for now i'm with 2.2.2-ls70 tag.

Link to comment
  • 1 month later...
  • 3 weeks later...

UPDATE 3: I wasn't using organizr2 anymore, so I commented that out in letsencrypt and also put back the server 80 https redirect and somehow it is working now. Guess it was jiving with the organizr2 code even tho the container was not on.

 

UPDATE 2: Back to the 502 error.

Quote

2020/03/15 14:40:14 [error] 401#401: *10 connect() failed (111: Connection refused) while connecting to upstream, client: 70.xxx.xxx.8, server: dashboard.*, request: "GET / HTTP/1.1", upstream: "https://172.18.0.16:4442/", host: "dashboard.example.com"

Changed back to default heimdall subdomain

Quote

2020/03/15 14:49:48 [error] 403#403: *17 connect() failed (111: Connection refused) while connecting to upstream, client: 70.xxx.xxx.8, server: heimdall.*, request: "GET /favicon.ico HTTP/1.1", upstream: "https://172.18.0.16:4442/favicon.ico", host: "heimdall.example.com", referrer: "https://heimdall.example.com/"

 

 

UPDATE: I saw on the heimdal github that subfolders are not supported, changed to subdomain but it just goes to the default nginx page.

Fixed that. conf file was not saving after changing subdomain name

 

So, I am trying to get this going but keep getting 502 externally. The error log for letsencrypt nginx says:

Quote

2020/03/15 14:23:06 [error] 395#395: *490 connect() failed (111: Connection refused) while connecting to upstream, client: 174.xxx.xxx.146, server: _, request: "GET /heimdal/ HTTP/1.1", upstream: "http://172.18.0.16:5849/heimdal/", host: "xxxxx.com"

 

 I have tried bridge mode also. same affect. I have tried http and https. (changed in letsencrypt heimdal conf). There are no other errors in any of the logs. I am also using http auth, but commented that to see. Nothing.

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='heimdall' --net='dabworx' -e TZ="America/Toronto" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -p '5849:80/tcp' -p '4442:443/tcp' -v '/mnt/user/appdata/heimdall':'/config':'rw' 'linuxserver/heimdall' 

 

Edited by dbinott
Link to comment

Hello everyone!

I've installed and configured Heimdall and it works perfectly fine through the webui.

 

However, if I try to use it with letsencrypt, the page that opens is broken.

image.png.fc70f2016d3e91011cd3d70db859712e.png

 

Other people in this topic had similar issues, but the fix wasn't explained.

What might be happening?

 

Everything else works fine with letsencrypt.

 

Ps. I'm using the default .conf file

 

# make sure that your dns has a cname set for heimdall

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

    server_name heimdall.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app heimdall;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}
 

Ps2. I'm accessing through https://heimdall.domain.com:PORT, because my 443 port is blocked by ISP.

 

TIA

Edited by luizmont
clarification
Link to comment
  • 1 month later...

Anyone know why every item I create on the page ends up with a hyperlink of "10.0.0.2:8443/10.0.0.100:80" instead of simply the address to the container or URI the item is for, 10.0.0.100:80 in this instance?  I have tried completely wiping the container and various ways of entering the correct information, as well as searching for some file to edit in the configs with no luck.

Link to comment
On 4/18/2020 at 2:47 AM, mikeylikesrocks said:


Are you just entering just the IP address or the full “http://10.0.0.100:80”?  I was having the same problem till I put in http://

Well I tried both, but it was going in and editing existing entries and adding the http/https to beginning of link.  It didn't work until I removed the container and appdata and reinstalled.  Only then was I able to use http for each link and have it work.  Thanks for the reply!

Link to comment

I have been able to get everything set up and it is running great. I'm using the letsencrypt docker for reverse proxy and everything works.

 

The only issue I have, is that I have no problem adding a link to another docker container from my server to the homepage of heimdall, provided it is set up as a subfolder, however I can not figure out how, or if its even possible, to add a link to something set up as a subdomain.

 

For example if something was set up as myserveraddresss.com/plex I would just add /plex in heimdall to link it.

 

But if I wanted to add plex.myserveraddress.com it doesn't really have the functionality to add something this way.

 

I just want to be sure I'm not missing something obvious, and if not maybe it could be added in future releases to use subdomains as well as subfolders.

 

Thanks.

Link to comment
On 4/18/2020 at 2:05 PM, greg_gorrell said:

Anyone know why every item I create on the page ends up with a hyperlink of "10.0.0.2:8443/10.0.0.100:80" instead of simply the address to the container or URI the item is for, 10.0.0.100:80 in this instance?  I have tried completely wiping the container and various ways of entering the correct information, as well as searching for some file to edit in the configs with no luck.

Same issue - even putting http first

Reinstalled, wiped appdata folder without any success

 

Is there a different fix for this issue?

Link to comment
  • 4 weeks later...

hi all,

 

tried searching for this but didn't see anything about it.  apologies if I missed it.

 

Is it possible to use Jackett as a default search provider for the dashboard?  I see it's an option on the dashboard, but not an option for a default in Heimdall's settings.

 

Thanks!

Edited by acosmichippo
Link to comment
  • 4 weeks later...

hey guys, read through the thread here and saw folks dealing with a few reverse proxy problems, but didn't see a solution for me. i've kept my setup fairly simple with a custom domain "mysite.com". i've got no issues getting this to work for other cname instances, but can't seem to get it working for heimdall. i'm using linux's letsencrypt default subdomain config:

 

# make sure that your dns has a cname set for heimdall

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

    server_name heimdall.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app heimdall;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

here's a screenshot of my container config:

1798738947_ScreenShot2020-06-18at5_21_16PM.png.08d873968ae9e2789e41de5116d72af1.png

 

i've got heimdall setup and working just fine on lan, just can't get it on the reverse proxy side. during troubleshooting, i tried changing upstream to match the container 2443:

set $upstream_port 2443

but it didn't make any difference, so i reverted back to default 443 until i get some guidance. i've triple checked my cname in cloudfare at heimdall.mysite.com. 

 

Any help is much appreciated, thanks!

 

Link to comment
2 hours ago, Cpt. Chaz said:

hey guys, read through the thread here and saw folks dealing with a few reverse proxy problems, but didn't see a solution for me. i've kept my setup fairly simple with a custom domain "mysite.com". i've got no issues getting this to work for other cname instances, but can't seem to get it working for heimdall. i'm using linux's letsencrypt default subdomain config:

 


# make sure that your dns has a cname set for heimdall

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

    server_name heimdall.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app heimdall;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

here's a screenshot of my container config:

1798738947_ScreenShot2020-06-18at5_21_16PM.png.08d873968ae9e2789e41de5116d72af1.png

 

i've got heimdall setup and working just fine on lan, just can't get it on the reverse proxy side. during troubleshooting, i tried changing upstream to match the container 2443:


set $upstream_port 2443

but it didn't make any difference, so i reverted back to default 443 until i get some guidance. i've triple checked my cname in cloudfare at heimdall.mysite.com. 

 

Any help is much appreciated, thanks!

 

See here https://blog.linuxserver.io/2019/04/25/letsencrypt-nginx-starter-guide/

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.