Cloudron Forum

@joseph
btw, i ended up uninstalling and reinstalling the Keycloak app and this the process went about as depicted in your video.

@joseph
I'm aware those are the prescribed steps, but the issue exists despite them, hence this post (as also stated before).

https://www.dropbox.com/scl/fi/jxiz1wuq86xy3oo8f6c5k/Screen-Recording-2025-02-06-100122.mp4?rlkey=n9pcd9qjbdzodohsy3cywo188&raw=1

https://www.dropbox.com/scl/fi/trjxvza4ktgrsuymh7u86/Screen-Recording-2025-02-06-100437.mp4?rlkey=r2vlkbso7nm157pbey8g8uin4&raw=1

@joseph
that's also part of the reported error, as well as shown in the shared screenshots.

@joseph yeah, my 2nd image corresponds to your 3rd one. There's no dropdown option available in my case because I've already added all the available roles, although, the 'admin' role is not one of them.

@joseph said in How to add a permanent admin?:

you have to create a new User in the master realm with 'admin' role

Hi @joseph, this is pretty much the reason for my post; there's no option available to select the 'admin' role.

I've tried to add every role available, but the 'admin' role option is nowhere to be found in my instance.

Even though, the role does exist:

How to add a permanent admin?

Creating a user via the UI doesn't have the option to assigning them the role of 'admin'.

And as per https://github.com/keycloak/keycloak/discussions/33803#discussioncomment-10921141, the new user should be added to the admin role via the CLI, but, when i try that, i get this error:

Failed to create config file: /root/.keycloak/kcadm.config

@nebulon

Seem to have finally resolved the issue, by deleting those empty directories, using find . -type d -empty -delete, for now.

Although, the app is steadily creating new empty directories already!

@nebulon said in Since update to v8.2.1 backups fail with "Too many empty directories":

so are all those empty dirs within the upload folder in your case?

Except for :

/mnt/immich/i/typesense

all of the paths seems to be:

/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/../..

@nebulon said in Since update to v8.2.1 backups fail with "Too many empty directories":

Also did you happen to change the data layout at some point in the past?

I think i migrated the app storage from local disk to a volume, around 5 months ago.

@nebulon said in Since update to v8.2.1 backups fail with "Too many empty directories":

@shrey can you run the Migration job in the end of the jobs section within Immich? https://immich.app/docs/administration/jobs-workers#jobs

Tried that.
But on my Immich instance (v1.123.0), it seems to have no effect on the concerned empty directories

root@apps:~# find /mnt/immich/i -type d -empty | wc -l
56587

@girish said in Since update to v8.2.1 backups fail with "Too many empty directories":

you can disable immich backups and then the system backup will succeed.

Yeah, that's the workaround i ended up with for now.

But i would really like to get my Immich start updating again (without compromising on the backup process). It's already 3 versions behind.

@girish said in Since update to v8.2.1 backups fail with "Too many empty directories":

Which paths inside immich are they in?

find /mnt/immich/i -type d -empty

/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/c7
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/96
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/01
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/09
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/36
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/2c
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/52
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/70
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/a3
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/93
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/33
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/0b
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/b7
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/9c
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/7d
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/3e
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/7c
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/d9
/mnt/immich/i/upload/upload/b4fe288d-66ef-42ac-b74a-14ec12220a71/82/82
...

@girish
Additionally, my instance backups all are failing as well, just because the system can't backup one of the apps, Immich!

Is this the (designed) expected behaviour?

@girish No idea. Nor could i find any issue in their repo regarding anything related to this.

Could you recommend any workaround for now?

@girish
Hi. I've come across the same error, BoxError: Too many empty directories. Run "find /mnt/immich/i -type d -empty" to investigate, when i was investigating why my Immich app stopped updating at all.
It seems, that the backup process keeps failing and hence the app hasn't updated for the past month.

Btw:

root@apps:~# find /mnt/immich/i -type d -empty | wc -l
56108

@avatar1024 Since i've installed the app, yes...have rebooted Cloudron once.

@girish said in App not starting:

docker inspect <containerid> --format='{{json .HostConfig.Ulimits}}'

"Ulimits": null

@girish

root@apps:~# ulimit -n
1048576

@girish Hi. Is this something that needs to configured on my end?

Fresh install.

Dec 25 22:50:44 ==> Creating directories
Dec 25 22:50:44 ==> Initialise database
Dec 25 22:50:44 panic: registerHooks: too many open files
Dec 25 22:50:44 2024-12-25T17:20:44Z
Dec 25 22:50:44 goroutine 1 [running]:
Dec 25 22:50:44 github.com/pocketbase/pocketbase/plugins/jsvm.MustRegister(...)
Dec 25 22:50:44 /home/runner/work/pocketbase/pocketbase/plugins/jsvm/jsvm.go:106
Dec 25 22:50:44 main.main()
Dec 25 22:50:44 /home/runner/work/pocketbase/pocketbase/examples/base/main.go:96 +0x6ce
Dec 25 22:50:46 => Waiting for app to come up
Dec 25 22:50:47 => Waiting for app to come up
Dec 25 22:50:48 => Waiting for app to come up
Dec 25 22:50:49 => Waiting for app to come up
Dec 25 22:50:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:50:50 => Waiting for app to come up
Dec 25 22:50:51 => Waiting for app to come up
Dec 25 22:50:52 => Waiting for app to come up
Dec 25 22:50:53 => Waiting for app to come up
Dec 25 22:50:54 => Waiting for app to come up
Dec 25 22:50:55 => Waiting for app to come up
Dec 25 22:50:56 => Waiting for app to come up
Dec 25 22:50:57 => Waiting for app to come up
Dec 25 22:50:58 => Waiting for app to come up
Dec 25 22:50:59 => Waiting for app to come up
Dec 25 22:51:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:00 => Waiting for app to come up
Dec 25 22:51:01 => Waiting for app to come up
Dec 25 22:51:02 => Waiting for app to come up
Dec 25 22:51:03 => Waiting for app to come up
Dec 25 22:51:04 => Waiting for app to come up
Dec 25 22:51:05 => Waiting for app to come up
Dec 25 22:51:06 => Waiting for app to come up
Dec 25 22:51:07 => Waiting for app to come up
Dec 25 22:51:08 => Waiting for app to come up
Dec 25 22:51:09 => Waiting for app to come up
Dec 25 22:51:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:10 => Waiting for app to come up
Dec 25 22:51:12 => Waiting for app to come up
Dec 25 22:51:13 => Waiting for app to come up
Dec 25 22:51:14 => Waiting for app to come up
Dec 25 22:51:15 => Waiting for app to come up
Dec 25 22:51:16 => Waiting for app to come up
Dec 25 22:51:17 => Waiting for app to come up
Dec 25 22:51:18 => Waiting for app to come up
Dec 25 22:51:19 => Waiting for app to come up
Dec 25 22:51:20 => Waiting for app to come up
Dec 25 22:51:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:21 => Waiting for app to come up
Dec 25 22:51:22 => Waiting for app to come up
Dec 25 22:51:23 => Waiting for app to come up
Dec 25 22:51:24 => Waiting for app to come up
Dec 25 22:51:25 => Waiting for app to come up
Dec 25 22:51:26 => Waiting for app to come up
Dec 25 22:51:27 => Waiting for app to come up
Dec 25 22:51:28 => Waiting for app to come up

And for now, should i simply delete those .conf files?

Yeah, that works.

A new (Directus) app that i cloned from an existing one, has seemingly become stuck in an unresponsive (502 Error) state.

The logs show:

[no timestamp]  [warn] conflicting server name "<my-app-domain>" on 0.0.0.0:80, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on [::]:80, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on 0.0.0.0:443, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on [::]:443, ignored

How to resolve this issue?

Note:

• Domain's been configured using a Wildcard config
• Domain has no pending propagation (IPv4 & IPv6 addresses are correctly pointed)
• Tried "Sync DNS" > restart app already
• Have already uninstalled and reinstalled once

Update:
I have again uninstalled the app.
Upon inspecting /etc/nginx/applications/, i can now see 2 orphan configs (for the uninstalled apps) for the concerned <my-app-domain>, which should be the cause of this issue.

Is this a bug then (orphaned nginx configs persisting) ?

And for now, should i simply delete those .conf files?