@Eichhorn On Unraid this can happen if the appdata for FileRise was partially left over from an older version and something in users/ is now invalid.

1. Make sure you’re on the latest FileRise image

   In Unraid, edit the container and make sure the image is:

error311/filerise-docker:latest

Then force a pull + restart.

2. Fix the broken config + reset the admin user

   In your Unraid appdata for this container (e.g. something like

   /mnt/user/appdata/filerise), you’ll see:

   • uploads/

   • users/

   • metadata/

   To completely reset logins without touching your files:

   • Stop the FileRise container.

   • In the appdata folder, delete the users/users.txt file.

     • On next start, FileRise will treat this as a first run and ask you to create a new admin user.

   • Start the container again and go to the WebUI – you should see the initial “create admin” screen.

   That takes care of the login issue.

   If the json_decode error still shows up after that, it means one of the config files under users/ is corrupted

Edited November 30, 2025Nov 30 by error311

19 minutes ago, error311 said:

@Eichhorn On Unraid this can happen if the appdata for FileRise was partially left over from an older version and something in config/ is now invalid.

1. Make sure you’re on the latest FileRise image

   In Unraid, edit the container and make sure the image is:

error311/filerise-docker:latest

Then force a pull + restart.

2. Fix the broken config + reset the admin user

   In your Unraid appdata for this container (e.g. something like

   /mnt/user/appdata/filerise), you’ll see:

   • upload/

   • users/

   • metadata/

   To completely reset logins without touching your files:

   • Stop the FileRise container.

   • In the appdata folder, delete the users/users.txt file.

     • On next start, FileRise will treat this as a first run and ask you to create a new admin user.

   • Start the container again and go to the WebUI – you should see the initial “create admin” screen.

   That takes care of the login issue.

   If the json_decode error still shows up after that, it means one of the config files under users/ is corrupted

i dont have a folder named user. only a file named users.txt, directly in appdata/filerise that users.txt i deleted now, also the file metadata.json isnt in a folder named metadata, thats also directly in appdata/ filerise.

ok then how can i repair the broken files ?

i havent a folder namend user. only a file directly in appdata/filerise

i deleted it now again and installed it new but no changing

Edited November 30, 2025Nov 30 by Eichhorn

@Eichhorn when you edit the container in unraid you set the location  USERS_DIR:

You can try deleting the adminConfig.json and siteConfig.json that may resolve the issue too.

You can back these up too if you have changes to OIDC you want to keep.

Edited November 30, 2025Nov 30 by error311

19 hours ago, error311 said:

@Eichhorn when you edit the container in unraid you set the location  USERS_DIR:

You can try deleting the adminConfig.json and siteConfig.json that may resolve the issue too.

You can back these up too if you have changes to OIDC you want to keep.

ok this way brings me a little bit foreward, 2 steps maybe..

now the red Protokolls are gone, a New User added with Admin rights, but if i try to login, i get Error "Login session not established"

in Container Edit" CHOWN_ON_START:" is allready set to "false", it was on true after reinstall and the first run and first Account setup

but now, i restart the container sometimes. and try it again to login with the new created account, i get everytime this error

After some restarts and trys i see in the protokoll that

Edited December 1, 2025Dec 1 by Eichhorn

Hey @Eichhorn 👋

That log line:

checkAuth: setup mode

means FileRise still thinks it’s in initial setup which basically it’s not seeing any users in its users.txt file. So when you create the admin user, it’s either:

• not being written at all, or

• being written somewhere that isn’t persisted / readable on restart.

On Unraid this is USERS_DIR mapping.

Can you try this:

1. Double-check your USERS_DIR mapping in the container template

In the Unraid docker UI for FileRise:

• Make sure you have something like:

  • Host path: /mnt/user/appdata/filerise/users (or similar)

  • Container path: /var/www/users

• And the env var USERS_DIR should point to that container path ( /var/www/users).

Also make sure that host folder exists and isn’t mounted read-only.

2. Check if users.txt is actually created

After you go through the setup screen and create the first admin:

• Open a console into the FileRise container (Unraid → Docker → FileRise → Console)

• Run:

  ls -l /var/www/users
  cat /var/www/users/users.txt

or verify the users.txt was created at the host path.

On 12/2/2025 at 3:41 PM, error311 said:

Hey @Eichhorn 👋

That log line:

means FileRise still thinks it’s in initial setup which basically it’s not seeing any users in its users.txt file. So when you create the admin user, it’s either:

• not being written at all, or

• being written somewhere that isn’t persisted / readable on restart.

On Unraid this is USERS_DIR mapping.

Can you try this:

1. Double-check your USERS_DIR mapping in the container template

In the Unraid docker UI for FileRise:

• Make sure you have something like:

  • Host path: /mnt/user/appdata/filerise/users (or similar)

  • Container path: /var/www/users

• And the env var USERS_DIR should point to that container path ( /var/www/users).

Also make sure that host folder exists and isn’t mounted read-only.

2. Check if users.txt is actually created

After you go through the setup screen and create the first admin:

• Open a console into the FileRise container (Unraid → Docker → FileRise → Console)

• Run:

  ls -l /var/www/users
  cat /var/www/users/users.txt

or verify the users.txt was created at the host path.

i think here is everything right

the host folder was not there, i created it manual in ../filerise/users/

i stopped the container and startet it after few minues fresh but still dont want to work

Edited December 3, 2025Dec 3 by Eichhorn

@Eichhorn you also need the metadata folder META_DIR

You need the UPLOADS PATH, META_DIR and USERS_DIR...

Edited December 3, 2025Dec 3 by error311

21 hours ago, error311 said:

@Eichhorn you also need the metadata folder META_DIR

You need the UPLOADS PATH, META_DIR and USERS_DIR...

yes, this are also there, but was not on the screenshot

this right ?

It looks like the backend is running fine, so this is usually the browser not keeping the session cookie.

Can you try this and let me know what happens?

1. Use a private/incognito window

   • Open a new private window.

   • Go directly to the FileRise URL you’re using now (the new container, not any old bookmark).

   • Try logging in again and see if the message still says “Login session not established”.

2. Clear old site data for that host

   Since you had a very old FileRise install before, your browser might be mixing old JS/cookies with the new container.

   • In your normal browser profile, clear cookies + site data just for that URL (files.example.com or the IP/port you use for FileRise).

   • Then reload and try login again.

3. Double-check the URL

   Make sure you’re always using the same URL when you:

   • Load the login page

   • And after login (no mixing http://IP:8085 and https://hostname)

If it still says “Login session not established” after trying incognito + cleared cookies, send me a screenshot of your browser’s DevTools > Network tab around the /api/auth/auth.php and /api/auth/checkAuth.php calls and I’ll dig deeper.

Note this should no longer be an issue on newer versions of FileRise since we cache bust.

Edited December 5, 2025Dec 5 by error311

5 hours ago, error311 said:

It looks like the backend is running fine, so this is usually the browser not keeping the session cookie.

Can you try this and let me know what happens?

1. Use a private/incognito window

   • Open a new private window.

   • Go directly to the FileRise URL you’re using now (the new container, not any old bookmark).

   • Try logging in again and see if the message still says “Login session not established”.

2. Clear old site data for that host

   Since you had a very old FileRise install before, your browser might be mixing old JS/cookies with the new container.

   • In your normal browser profile, clear cookies + site data just for that URL (files.example.com or the IP/port you use for FileRise).

   • Then reload and try login again.

3. Double-check the URL

   Make sure you’re always using the same URL when you:

   • Load the login page

   • And after login (no mixing http://IP:8085 and https://hostname)

If it still says “Login session not established” after trying incognito + cleared cookies, send me a screenshot of your browser’s DevTools > Network tab around the /api/auth/auth.php and /api/auth/checkAuth.php calls and I’ll dig deeper.

Note this should no longer be an issue on newer versions of FileRise since we cache bust.

i get the same result an a new private window / tab, other devicelike smartphone or laptop etc. on everyone comes the session not established error.

if i try to open the container directly from dockerpool it dont opens because then docker gives me a site with port 10443 but i changed this to 1180.

i have also a running nginx, now i tryed to use a redirect . thats works, also with login, but ony over the redirect adress, also not over the internet ip.

then i would to look into the log file maybe it shows me somethings, there is see than that:

i dont get whats the problem maybe somethings with the ports ?

Thanks for all the info – this helps narrow it down.

From your screenshot of the logs I can see entries for things like:

• index.php

• app_dev.php

• authz_core errors

Those files/paths are not part of FileRise at all. That means your requests are not actually hitting the FileRise app in /public, but some other Apache vHost or webroot (maybe from an old container or another PHP app that used the same volume/ports before).

That would explain both:

• The “login session not established” message

• And the strange log entries that don’t match FileRise

To get this sorted, can you please check these things step by step:

---

1. Confirm which container is serving the traffic

In Unraid, open the Docker tab and:

1. Click on your FileRise container → Edit.

2. Take a screenshot of:

   • The Repository (should be the FileRise image)

   • The Port mappings

   • The Volume mappings (especially anything mapped to /var/www or /var/www/html)

If you’re reusing an appdata folder from some older PHP app, that can cause exactly this behavior (Apache serving the wrong app).

---

2. Port mapping sanity check

On Unraid, you should only change the host ports (left side), not the internal container ports (right side).

For example (just an example):

• HOST 1180  ->  CONTAINER 80

• HOST 11443 ->  CONTAINER 443

If you changed the container port instead of the host port, the Unraid “WebUI” button will still point to the old port (e.g. 10443), and the app might not be listening where you expect it.

When you say "docker gives me a site with port 10443 but I changed this to 1180": that usually means unraid template still pointing to the old value. Send a screenshot of the actual port mapping lines.

---

3. Try bypassing nginx / redirects

Right now login only works over the redirect address, not over the IP. That’s another hint that you’re hitting two different backends.

Please try:

1. Temporarily bypass nginx / any reverse proxy.

2. In your browser, go directly to the FileRise container via host IP + host port, e.g.:

http://SERVER-IP:1180/

3. You should see the FileRise login page, not some generic PHP or different app.

If you don’t see the FileRise login, but some other page, then nginx/ports are definitely pointing to the wrong container or wrong webroot.

---

4. Quick session check in browser

If you do see the FileRise login page directly on http://SERVER-IP:1180/ but still get “login session not established”, please:

1. Open DevTools → Network.

2. Try to log in.

3. Click on the /api/auth/auth.php and /api/auth/checkAuth.php requests.

4. Send me a screenshot that shows:

   • Request URL

   • Response code

   • The Cookies tab (to see if the session cookie is set)

---

TL;DR:

The log lines with app_dev.php and authz_core are a big sign that your browser is not actually talking to the FileRise app, but to a different Apache instance / webroot. Once we see your Unraid Docker template (ports + volumes) we can normally fix this pretty quickly.

12 hours ago, error311 said:

Thanks for all the info – this helps narrow it down.

From your screenshot of the logs I can see entries for things like:

• index.php

• app_dev.php

• authz_core errors

Those files/paths are not part of FileRise at all. That means your requests are not actually hitting the FileRise app in /public, but some other Apache vHost or webroot (maybe from an old container or another PHP app that used the same volume/ports before).

That would explain both:

• The “login session not established” message

• And the strange log entries that don’t match FileRise

To get this sorted, can you please check these things step by step:

---

1. Confirm which container is serving the traffic

In Unraid, open the Docker tab and:

1. Click on your FileRise container → Edit.

2. Take a screenshot of:

   • The Repository (should be the FileRise image)

   • The Port mappings

   • The Volume mappings (especially anything mapped to /var/www or /var/www/html)

If you’re reusing an appdata folder from some older PHP app, that can cause exactly this behavior (Apache serving the wrong app).

---

2. Port mapping sanity check

On Unraid, you should only change the host ports (left side), not the internal container ports (right side).

For example (just an example):

• HOST 1180  ->  CONTAINER 80

• HOST 11443 ->  CONTAINER 443

If you changed the container port instead of the host port, the Unraid “WebUI” button will still point to the old port (e.g. 10443), and the app might not be listening where you expect it.

When you say "docker gives me a site with port 10443 but I changed this to 1180": that usually means unraid template still pointing to the old value. Send a screenshot of the actual port mapping lines.

---

3. Try bypassing nginx / redirects

Right now login only works over the redirect address, not over the IP. That’s another hint that you’re hitting two different backends.

Please try:

1. Temporarily bypass nginx / any reverse proxy.

2. In your browser, go directly to the FileRise container via host IP + host port, e.g.:

http://SERVER-IP:1180/

3. You should see the FileRise login page, not some generic PHP or different app.

If you don’t see the FileRise login, but some other page, then nginx/ports are definitely pointing to the wrong container or wrong webroot.

---

4. Quick session check in browser

If you do see the FileRise login page directly on http://SERVER-IP:1180/ but still get “login session not established”, please:

1. Open DevTools → Network.

2. Try to log in.

3. Click on the /api/auth/auth.php and /api/auth/checkAuth.php requests.

4. Send me a screenshot that shows:

   • Request URL

   • Response code

   • The Cookies tab (to see if the session cookie is set)

---

TL;DR:

The log lines with app_dev.php and authz_core are a big sign that your browser is not actually talking to the FileRise app, but to a different Apache instance / webroot. Once we see your Unraid Docker template (ports + volumes) we can normally fix this pretty quickly.

the screenshots from fileise edit:

for Number 3. : yes of course i can connect the the local IP:Port and on this way to the container web ui ( the filerise loginpage ) but there i cant login, if i try that i get everytime the login error.

4. Where exactly i can find devtools ?

@Eichhorn

To simplify things and rule out all the weird edge cases, can you reset the container to a “known good” setup:

1. Stop and remove the current FileRise container (keep the appdata folders).

2. Re-add FileRise from the Unraid template with these settings:

• Network: bridge

• DO NOT change the internal Apache ports:

  • Leave HTTP_PORT and HTTPS_PORT empty (defaults to 80/443 inside the container).

• Port mappings:

  • Host 1180 > Container 80 (HTTP)

  • (Optional) Host 11443 > Container 443 (HTTPS)

• PUID=99, PGID=100 (Unraid defaults)

• Set CHOWN_ON_START=true at least for this run, so the container can fix permissions on uploads/metadata/sessions.

3. Start the container, wait for it to finish the initial scan + chown in the logs.

4. In your browser, go directly to:

• http://SERVER-IP:1180/

You should see the FileRise login page.

5. Try logging in again.

Once this works on http://SERVER-IP:1180/, you can put a reverse proxy (nginx/Nginx Proxy Manager) in front if you want, but keeping Apache on 80/443 inside the container is the simplest and most tested layout.

Edited December 6, 2025Dec 6 by error311

3 minutes ago, error311 said:

@Eichhorn

To simplify things and rule out all the weird edge cases, can you reset the container to a “known good” setup:

1. Stop and remove the current FileRise container (keep the appdata folders).

2. Re-add FileRise from the Unraid template with these settings:

• Network: bridge

• DO NOT change the internal Apache ports:

• Leave HTTP_PORT and HTTPS_PORT empty (defaults to 80/443 inside the container).

• Port mappings:

• Host 1180 > Container 80 (HTTP)

• (Optional) Host 11443 > Container 443 (HTTPS)

• PUID=99, PGID=100 (Unraid defaults)

• Set CHOWN_ON_START=true at least for this run, so the container can fix permissions on uploads/metadata/sessions.

3. Start the container, wait for it to finish the initial scan + chown in the logs.

4. In your browser, go directly to:

• http://SERVER-IP:1180/

You should see the FileRise login page.

5. Try logging in again.

Once this works on http://SERVER-IP:1180/, you can put a reverse proxy (nginx/Nginx Proxy Manager) in front if you want, but keeping Apache on 80/443 inside the container is the simplest and most tested layout.

ok i will try it in few minutes, but what about port 80 and 443, what if this ports are allready in use from an another container ? because you mean leave http port and https port default 80 and 443

Just now, Eichhorn said:

ok i will try it in few minutes, but what about port 80 and 443, what if this ports are allready in use from an another container ? because you mean leave http port and https port default 80 and 443

Dont change these from your picture the Internal Apache port keep those as 80 and 443.

6 minutes ago, error311 said:

Dont change these from your picture the Internal Apache port keep those as 80 and 443.

now filereise deleted, new installed over apps in unraid:

now it works with clicking on webui on the container, but my admin account cant login, "login failed"

but also i see still this in the protokoll:

Edited December 6, 2025Dec 6 by Eichhorn

reinstalled it sometimes again and again, but still the same problem. i dont get what is going wrong. i didnt change the ports. everything is like in my screenshot but still not working

On 12/13/2025 at 6:00 AM, Eichhorn said:

reinstalled it sometimes again and again, but still the same problem. i dont get what is going wrong. i didnt change the ports. everything is like in my screenshot but still not working

FileRise v2.10.0 adds proper support for subpaths. I believe you mentioned that you were using a subpath. Please review the latest Nginx setup wiki:
https://github.com/error311/FileRise/wiki/Nginx-Setup

On 12/19/2025 at 3:01 AM, error311 said:

FileRise v2.10.0 adds proper support for subpaths. I believe you mentioned that you were using a subpath. Please review the latest Nginx setup wiki:
https://github.com/error311/FileRise/wiki/Nginx-Setup

now it works . i uninstalled it , run appdata cleaner, restarted docker . now very well...

Nice app. Love the demo and excellent developer communication I have seen. Kudos! Looking for a new decent file manager for my media server, and this looks very promising.

Unfortunately, I have trouble getting Tailscale to work, which I usually use for all my containers.

With tailscale disabled, the container starts fine. (Since I'm doing it remotely, I wasn't able to check local access.) With tailscale turned on (serve) I'm running into the 443 conflict as shown in above screenshot. I tried a few things, including deleting the https port variable, but no luck so far.

Any advice on getting Tailscale to work with Filerise? Or is there a better, more/same secure way to remote access?

Edited December 22, 2025Dec 22 by Pixbone

@Pixbone

You don’t want to map FileRise to host 443. If you do, it often collides with Unraid or another container and the FileRise container won’t start.

• Keep FileRise on a high host port, for example:

  • Host 8085 > Container 80

  • (optional) Host 8443 > Container 443 (only if you really need it)

Then, from any device on your Tailnet, just open:

• http://<unraid-tailscale-ip>:8085 (or http://<unraid-hostname>:8085 if you use MagicDNS)

On 12/23/2025 at 9:27 AM, error311 said:

@Pixbone

You don’t want to map FileRise to host 443. If you do, it often collides with Unraid or another container and the FileRise container won’t start.

• Keep FileRise on a high host port, for example:

  • Host 8085 > Container 80

  • (optional) Host 8443 > Container 443 (only if you really need it)

Then, from any device on your Tailnet, just open:

• http://<unraid-tailscale-ip>:8085 (or http://<unraid-hostname>:8085 if you use MagicDNS)

Thank you @error311 . I tried all combinations of port mapping, but it seems that even when HTTPS is left blank, Apache 443 still tries to connect. Since the Apache server is not starting for me at all, I have no way to access your link:port address suggestion.

I tried to turn off Tailscale serve, hoping it would stop using port 443, but no luck.

This is the Docker log:

Docker run

With Tailscale off, the container is running fine.

Do you see any issues with my port setup?

Edited December 27, 2025Dec 27 by Pixbone

@Pixbone

You’re not doing anything wrong with FileRise itself.

FileRise works great over Tailscale when you just access the container on its host port (tailnet IP + 8083).

What’s failing here is Tailscale Serve running inside the same container: Serve grabs port 443, then Apache also tries to bind 443, and Apache refuses to start (Address already in use).

Fix options:

1. Simplest: don’t use Tailscale Serve. Leave HTTP_PORT / HTTPS_PORT empty, map host 8083 → container 80, then open http://<unraid-tailscale-ip>:8083.

2. If you want the nice https://name.ts.net/ URL, then Serve should own HTTPS and Apache should stay HTTP-only (Apache must not bind 443 inside the container). That means disabling Apache SSL / default-ssl in the container (or running a reverse proxy externally).

Also: only change the Host Port fields in Unraid. Leave HTTP_PORT / HTTPS_PORT blank unless you’re intentionally changing Apache’s internal listen ports.

if a folder is be shared, the opedet shared folder site dont keeps the footer settings from main site setted

6 hours ago, Eichhorn said:

if a folder is be shared, the opedet shared folder site dont keeps the footer settings from main site setted

Yes sorry that is on the pro road map to add deeper branding. I don't have an ETA but hopefully will be soon.