There have been no app updates via the TrueNAS catalog for at least 7 days. Did something happen that I’m not aware of?
Thanks!
Apps maintainer is propably on summer vacation…
5 Likes
Sigh… just as Audiobookshelf released a new version while globalping-probe is in a stopped state and unable to start.
I was curious what this was and tried it, apparently the container is trying to set permissions and just can’t. My guess it’s because it’s running as root and not uid 1000.
Sadly that’s not really much help since I don’t remember where to PR to change the template. 
The place for the PR would be the apps section of the truenas github
1 Like
Neat! Now to figure out how to test my concept lmao.
Maybe when I’m not sleep-depliveried and zombie posting.
propably the easiest way would be to convert the app to a custom app and change the value for UID and GID and see if it deploys successfully.
ROFLMAO it started the updater okay but died copying the app files to /app because /app is owned by root. 
But it also fails to update certs for the same reason.
AI slop suggested (after many many many false starts) to just override the tar command:
services:
globalping-probe:
cap_add:
- NET_RAW
cap_drop:
- ALL
deploy:
resources:
limits:
cpus: '2'
memory: 1512M
entrypoint:
- /bin/sh
- '-c'
- |
mkdir -p /tmp/bin
printf '#!/bin/sh\nexec /bin/tar "$@" --no-same-owner\n' > /tmp/bin/tar
chmod +x /tmp/bin/tar
export PATH="/tmp/bin:$PATH"
exec /entrypoint.sh
environment:
NVIDIA_VISIBLE_DEVICES: void
TZ: America/Los_Angeles
UMASK: '002'
UMASK_SET: '002'
group_add:
- 568
healthcheck:
disable: True
image: ghcr.io/jsdelivr/globalping-probe:0.49.0
network_mode: host
platform: linux/amd64
privileged: False
restart: unless-stopped
security_opt:
- no-new-privileges=true
stdin_open: False
tty: False
Terrible hack I don’t know if I want to even submit for review.
At least it’s not my ugly way of making a Guacamole plugin in-line in the dockerfile…
Right and some critical app updates are missing since weeks: e.g.: Release 2026-07-24-r1 - UPDATE ASAP · ZoeyVid/NPMplus · GitHub … I’m close to switch everything to custom apps with Arcane leaving TrueNAS build in support as main docker host behind.
I hope there is more than one person as gatekeeper for updates. But I would also think that it should be possible to automatically get minor updates and only the major ones should require to pass a gatekeeper…
2 Likes
I didn’t want to be reliant on the truenas team for updates, that’s why my whole docker stack runs inside an lxc managed by portainer. My own compose files, my own pace for updates (granted i’m a lazy a** and set up watchtower for automatic app updates)
Runs this way for almost 2 years now without any issues, or breaking changes that would have me re-installing everything (like happened on the various truenas apps systems over the years)
5 Likes
As a TrueNAS is company operating in a space where IT security and reliability are key aspects of the product, I believe it is important to only offer services that can be maintained with an appropriate level of care and responsiveness. If there are operational constraints, those should be communicated transparently.
In this case, I would expect an explanation of what caused the delay, what measures are being taken to prevent similar situations in the future, and what the long-term plan is. Alternatively, if maintaining timely updates is not always feasible, perhaps the catalog should be positioned as a deployment starting point, supplemented with change tracking and diff comparisons, rather than as a fully managed update channel.
This happened every time the one full-time apps maintainer was on vacation (at least i can remember almost the same questions from the last few years). And i doubt that will change unless iX hires more apps maintainer…
Looks like some of the test are failing Update updates-patch-minor by truenasbot · Pull Request #5462 · truenas/apps · GitHub
The maintainer being on vacation is the most likely reason for the delay. Since TrueNAS pulls updates directly from GitHub, you can always check the commit history to get a sense of when activity resumes:
https://github.com/truenas/apps/commits/master/
From the history, the last merge was on July 24, 2026. Until the maintainers return, submitting additional PRs is unlikely to speed things up, as there won’t be anyone available to review, merge, and publish them.
I’ll offer the same advice that I did the last time this came up. The apps repo is open source, and we’d be happy to accept additional maintainers if folks want to step up to test and help us approve PRs.
7 Likes
I didn’t want to be reliant on the truenas team for updates, that’s why my whole docker stack runs inside an lxc managed by portainer.
You don’t even need to go this far. I simply installed Dockhand (as a “custom yaml” app), then installed everything else from in there. Works great. And it notifies me of updates too.
I don’t understand why so many people insist on using these volunteer-maintained “community apps” which prevents you from using the official builds from the project maintainers and greatly restricts how you install and use these apps, when it’s SO easy to just install with a yaml file in Dockhand, Portainer, or Dockge. And now they’re asking for more volunteers to do work which isn’t even necessary because no one actually needs these community apps. If someone wants to volunteer, they should spend their limited time on the app itself, not some dumb wrapper around it.
While I’d really love to help with this, I’m still fairly new to contributing apps. For the three apps I’ve submitted, I leaned heavily on AI, and @stavros-k provided a lot of guidance to help get them over the finish line. I don’t yet have his level of expertise when it comes to reviewing app submissions, so I’m happy to be patient until he returns.
At the end of the day, it’s an open-source project, and sometimes that means being patient when maintainer time is limited. 
1 Like
I agree that community apps aren’t strictly necessary, but they do provide a lot of convenience for novice users and for anyone who simply wants an easier deployment experience.
The UI-driven configuration forms, selectors, and validation help reduce configuration errors and streamline deployments, so I wouldn’t describe the wrappers as “dumb.”
In some cases, the community apps also include genuine improvements over the vendor’s recommended deployment. For example, when I submitted Seafile to the catalog, I was encouraged to migrate from Redis to Valkey and to use a newer MariaDB release than the one included in the upstream Docker Compose template.
There are a couple of other benefits that I find particularly valuable:
-
The ability to use TrueNAS-managed SSL certificates instead of maintaining certificate files separately.
-
Having a custom application icon provided through the Apps Catalog. This is especially useful until support for custom icons in custom apps is implemented (https://forums.truenas.com/t/moved-to-roadmap-allow-custom-icons-for-custom-apps/22714).
For experienced users, these advantages may not be compelling. But for many people, especially those new to self-hosting, they make the deployment and maintenance experience significantly smoother.
5 Likes
Kinda sad that its only one person maintaining the catalog, maybe somebody else from the team could do some app updates wheres the app has critical vulnerabilities.
1 Like
The rest of the team are all probably working on getting the next release out the door. They are coming up on that time….