DebrodeD

for me, problems with webdav usually point to a problem with your reverse proxy. Are you using nginx or some other reverse proxy? I would also ask this in the filerun forums as they've been pretty helpful.

If you're having issues with the CyberChef template, a recent update broke the webui because they switched the default port to 8080 instead of 80. You just need to update your port mapping on the template to map to port 8080 and update the webUI address in the advanced section of the template to [IP]:[8080] as well.

I updated my above post, but I've been working through some bugs in 2026.1 with Vlad the creator and he's solved most of them. I recommend installing the patched update that you can find here: patched update and upload it using the "Offline update" button, under the "Update" FileRun control panel section. Also, I found out that setting APACHE_RUN_USER to "filerun" or "abc" (or anything you want OTHER than nobody or www-data as recommended in other guides) will fix Unraid seeing the owner as "UNKNOWN" and correctly show as "nobody". I also added: // Set File Permissions umask(000);to my config.php file found in "html/customizeables" to make it so that full permissions are added to any files created or uploaded to FileRun. That fixed problems I was having with my files not being editable/accessible via smb.

Successfully installed the 2026.1.0 update. Here is what I had to do (which was basically just follow the update instructions here): Backed up everything I could think of (other than user files) - appdata folder & db (using adminer) & container Made sure my MariaDB container was up to date Logged into Filerun as superuser & checked for update, then download/installed it Then went to my FileRun container in Unraid and updated the repository to "filerun/filerun:8.4" After doing that it successfully updated but it wouldn't start because I needed to change my APACHE_USER & GROUP container variables from 99/100 to nobody/users: APACHE_RUN_USER_ID=99 APACHE_RUN_GROUP_ID=100 APACHE_RUN_USER=filerun APACHE_RUN_GROUP=usersThen I added these into the "gear" icon of my proxy entry for FileRun in Nginx (after everything else already in there): fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info;Then the container started and I was introduced to the final update screens in FileRun where I came upon one more error: I fixed that by running this in the console of the FileRun container: chown -R 99:100 /var/www/html/system/data chmod -R 775 /var/www/html/system/dataI then refreshed the update page in FileRun and it showed as a checkmark , so I continued and I was able to login successfully and it's now working perfectly.

I've been running this container for a while in Unraid! I wish I'd had your community template a couple years ago @ImSkully, thanks for making it! Yours is setup exactly like mine, but there are a few additional notes for those that are setting this up for the first time to avoid any issues: Add LimitRequestBody 0 to /etc/apache2/apache2.conf (you can do this from the console of the filerun container by navigating to that file and using "vi" to edit it. By default you will be unable to upload a file larger than 1GB via webdav from services that don't support Filerun methods of chunking (Photosync), this will fix that. Use these in the advanced settings of Nginx (the gear icon) to avoid any issues with upload & download size & speed: client_max_body_size 50000M; proxy_max_temp_file_size 0; proxy_request_buffering off; proxy_buffering off; proxy_read_timeout 600s; proxy_send_timeout 600s; proxy_connect_timeout 300s; send_timeout 600s; client_body_timeout 600s; FileRun generates thumbnails for images automatically (assuming you have the plugins enabled (via the superuser control panel)), but it only does it once you are viewing the image. If you have a small library this is fine, but I would run into issues where I would try to view all the images in a folder of large RAW files and it would crash my server trying to generate all of them. You can avoid this issue by pre-generating thumbnails by following the instructions in my post on the FileRun forum: https://feedback.filerun.com/communities/1/topics/2498-thumbnail-questions

This is exactly the solution. I was having a similar issue where the template maps to /db, so the db file was being destroyed every time the container restarted and I'd have to use the temp admin password from the log to re-login.

This is my experience exactly as well. Switching the repository to "bitnamilegacy/keycloak:latest" fixed keycloak for me, but it isn't a long-term fix as it won't be updated.

I'm having issues with keycloak as well, stopped working for me this week with a recent update I assume. I believe some variable keys changed? I've been trying to debug, but haven't found the correct combination yet.

The Keycloak template is outdated ever since keycloak rolled out their hostname v2. Here are the correct variables to get it working correctly: Port KEYCLOAK_ADMIN_USER (temporary first username to login and do first time setup) KEYCLOAK_ADMIN_PASSWORD (temporary first password to login and do first time setup) KEYCLOAK_DATABASE_HOST (Postgres Hostname if on same docker network, or IP if not) KEYCLOAK_DATABASE_PORT (Postgres container port 5432 if on same docker network, or public port if not) KEYCLOAK_DATABASE_USER (Postgres username) KEYCLOAK_DATABASE_PASSWORD (Postgres password) KEYCLOAK_DATABASE_NAME (Postgres DB name - i.e. "keycloak") KEYCLOAK_EXTRA_ARGS (leave blank) KEYCLOAK_PROXY_HEADERS (set to "xforwarded" if using a reverse proxy like Nginx) KEYCLOAK_HOSTNAME_ADMIN (URL for admin access, you can have this be the same as hostname if you want to have web access to Keycloak admin portal, or you can set to something else if you want to keep it local) KEYCLOAK_HOSTNAME (i.e. "auth.example.com") KEYCLOAK_PRODUCTION (Set to "true" if you want to run in production mode, which you do, or "false" for development mode) The old template fields of "HTTPS Strict" and "HTTP Enabled", and "KC_Proxy" have been deprecated.

I just installed this app and got it working and setup with reverse proxy. Here are a few helpful tips for anyone trying to run this: Change "storage" in the template to "/mnt/user/appdata/docmost/", the default is /mnt/apps/appdata/docmost, which led to permission issues (and just isn't where appdata is supposed to go). I was able to change this after already standing up my instance and having pages created. I believe this folder is only used for asset upload (such as images) and not used for any page/app data. Once I switched this in the template I was able to upload images. Click the "advanced view" toggle and update the "extra parameters" to "--restart=unless-stopped --hostname docmost" (adding the 'hostname' part to make it easier to setup Nginx/reverse proxy in the future). Also in the "advanced view" change the "WebUI" to "http://[IP]:[PORT:3000]". The default has "https" in it which will make the local web UI not show up when trying to access from the Unraid Docker page. Database URL example: postgresql://[your postgress hostname]:[your postgres DB password]@[your postgres admin username]:5432/docmost?schema=public. Note: "5432/docmost?schema=public" is your postgres port (yours may be different, though you can use 5432 if you're on the same docker network since that would be the container internal port). the "docmost" part of this snippet is the name of the db in postgres. I used the container "postgresql16" and in it you can set your initial db name. If you're already running that for another container, then you can use adminer to login to postgres and create your docmost db there first. If you're running docmost & redis on the same custom docker network (such as "nginx"), then instead of "redis://127.0.0.1:6379", you can use "redis://redis:6379" (assuming you have set the hostname in the redis container to be "redis").

Fixed the owner issue, the above advice no longer works with the recent update (at least for me), you need to create 4 new variables and set them to these values: Name: Apache Run User Key: APACHE_RUN_USER Value: 99 Name: Apache Run User ID Key: APACHE_RUN_USER_ID Value: 99 Name: Apache Run Group Key: APACHE_RUN_GROUP Value: 100 Name: Apache Run Group ID Key: APACHE_RUN_GROUP_ID Value: 100

I can fix the permissions issue by setting the umask to 000, but that doesn't fix the owner issue.

Adding those variables into the template and the umask into the config file hasn't worked for me. New folders created from within Filerun are still listed as "UNKNOWN" under owner in Unraid and are read-only on SMB. Anything I'm missing?

This is amazing! I'm in the process of building an Unraid Server to replace both my current plex server and gaming pc. I game very rarely (like once every few weeks) and so I was hoping to use a windows VM that had access to the majority of the resources on my unraid server, but would only need them for a while and would then free-up when not in use and hibernating (and then using wake on lan) to wake it up when needed again). Would this allow me to accomplish that? Specs of my server: i5-8500 (6 core, no HT) 16GB DDR4 1TB NVME Cache Drive 1TB NVME unassigned drive (was hoping to use this for windows vm/steam installs) AMD RX6400 A bunch of bigger drives for the array I obviously don't have enough cores/ram to just be assigning them away to a VM permanently, so would your method allow me to have my cake and eat it too?