ImSkully

Yes, this is correct :) this is how standard Docker mappings work - it's also not hidden as you said, the /etc/vikunja/ mapping is the second entry in the configuration titled Configuration Directory and is always visible to you (not hidden) and this points Vikunja's configuration path to your appdata folder (or any location of your choosing). From there onwards, Vikunja expects all variables such as VIKUNJA_DATABASE_PATH to be relative to the configuration directory path set earlier. To clarify: within the container, the configuration directory and the SQLite database file is actually still in /etc/vikunja/ which is the correct configuration path as outlined in the official docs; the Docker path mapping to your /mnt/user/appdata/vikunja/config is what sets the real path of where it's stored on your array.

Added step-by-step guide for updating from FileRun 2024.x to the latest 2026.2, refer to the post under the main topic: I finally had some time to go through the update process myself and had a few minor hiccups though otherwise it's pretty seamless. I've captured everything regarding the process for Unraid users so if anyone was still holding off on updating now is a good time to do so :) the entire process should only take ~5 minutes. Let me know if you have issues!

Thanks for sharing! I'm pretty swamped this month with various work but will update the CA template and setup instructions soon.

Are you sure? Port 8080 works fine using this template and OpenProject begins listening on this port which is mapped to port :5683 by default if you don't change it otherwise in the template. Tested with a fresh deployment using latest CA template running openproject:17.0.2.

I've been keeping an eye on the 2026.1 update and following the forum thread, looks very exciting though there's still a few issues that need to be ironed out before its ready. Once the stable release is announced, I'll update the template and share notable breaking changes/migration steps for Unraid users to move over to the latest version with (hopefully) minimal disruption.

Thanks for letting me know, OpenProject doesn't provide an image with the :latest tag so the version number has to be manually bumped in the template every major version. I've updated to 17.0.2, should be refreshed within the hour - please let me know if you encounter any issues!

I've been running FileRun for years and pretty happy with it - that being said I don't use all the bells and whistles that come with it and mainly just use it as an archive for backups and documents/PDFs. If you don't have any greater requirements with it beyond it being a simple 'Google Drive' like solution, then you should be fine. That being said, @toxicPeary made a few good points regarding the fact that there's only a single person maintaining FileRun and receives very slow updates (last one was August 2024 though a new major update is coming in 2026). There is an online demo you can check out, or alternatively you can contact FileRun and ask for a trial license as outlined on the demo page.

https://github.com/go-vikunja/vikunja/blob/main/CHANGELOG.md#100-rc1---2025-08-17 Here's a highlight of the breaking changes: All of these don't appear to be relevant to the majority of users but YMMV. I auto updated a week ago and haven't had any issues.

There is a major update expected for FileRun at some point in the next few weeks January 2026 - hoping that will bring some improvements to Docker permissions.

I started seeing this recently as well and tried reverting the UID/GUID settings which seems to have fixed it - give the below config a go and see if it resolves it:

The Installation & Setup section covers all the necessary steps, if you need help then you'll have to provide more specific information about the problems you are facing.

Just testing the above and can confirm that you are correct. The user:group gets set correctly and allows rename/deleting as well as being correctly set to nobody:users with the following UID/GUID config: Quite interesting considering nobody:users is what is stated on FileRun docs.

That's odd - APACHE_RUN_USER and APACHE_RUN_GROUP variables are intended to be the actual UID names and this is how I have always used it which works perfectly fine for me; this is also inline with FileRun docs which shows an example docker-compose.yml which uses these variables as string values of the UID/GUID name alongside the *_ID variables which is what the actual numeric IDs are.

My guess is you'd need to copy over the existing .ini files that are in the docker volume to go into the new mapped directory as it would be expecting to be there (likely generated during initial setup). By this do you mean you had to set the APACHE_RUN_USER_ID + APACHE_RUN_GROUP_ID environment variables in the template to 99 + 100? Or is there elsewhere a change is necessary? I ask this because the template should by default have these preconfigured so it works out of the box.

The internal PHP configuration file for FileRun is located in the docker volume at the /usr/local/etc/php/conf.d/ directory, you could add a volume mapping for this on Unraid in order to access it by pointing it to a folder in /mnt/user/appdata/filerun/ directory. Not sure how FileRun will behave if this is mapped on an existing container? I know once FileRun is running the PHP config file is /usr/local/etc/php/conf.d/filerun-optimization.ini which contains some preconfigured defaults but of course no upload_tmp_dir so you could create your own php.ini here and configure it (see FileRun docs: PHP configuration). There is an existing feature request here which goes over this exact problem. I also found topics on FileRun forums that are related to this with some useful bits of knowledge: Big WebDav Uploads fills Unraid Docker Image Disk Increasing upload size - Docker install Where to configure PHP options? I need to try this myself at some point to verify and then update the container template to include this mapping by default for Unraid users. There are also some advanced configuration options for FileRun that can be changed by creating a /mnt/user/appdata/filerun/customizables/config.php file which might also be of interest - I'm using this to adjust the thumbnail cache dir $config["path"]["thumbnail_cache"] to /var/www/html/_thumbnails/ so thumbnails are all located in one folder in FileRun's appdata (/mnt/cache/appdata/filerun/_thumbnails/) rather than being placed alongside the user files directory on my array share; this prevents disk spin up when navigating FileRun as thumbnails will then be loaded from appdata which is exclusively set to a cache pool.