TL,DR:
one cannot raise i-nodes after fs creation. normally, a tar from rootfs, reformat the rootfs, and restore would be necessary.
but to find out, who is consuming all the inodes, one can do the following:

try du -s --inodes * 2>/dev/null |sort -g then cd into the last dir in output and repeat.

Full Disclosure: not all OS's support --inodes flag for du command (my Mac OS does not) but many Linux OS's do.

one has to cd into the dir with the most i-nodes, recursively going down the tree and finally find the dir with the biggest i-node consumption.

in this case, as girish had mentioned, it was caused by not right configured nullmailer, writing tons of error-msg to /var/spool/nullmailer/failed useing 4.4M i-nodes…
deleting that dir eased the situation ad hoc.
rebooting the server and restart all failed apps (GUI & CLI) fixed it.

thanks for all your help

Here's some discussion about it - https://lwn.net/Articles/724522/

If that command doesn't work, put our ssh keys in your /root/.ssh/authorized_keys (https://cloudron.io/documentation/support/#ssh-keys)

thx everybody for trying to help.

I think thats a pure cloudron/system/cgroup pbl. as I haven't touched that system.
and never came around that on my various other docker projects/server.

/tmp & /dev/pts are are pseudofilesystems and are not managed via fstab.
they are too smale.

And

mkdir /tmp/pty465273103: no space left on device: unknown

Have you checked if /tmp is mounted correctly and is writable? It should appear in df -h even if it is a pseudo-filesystem. Since you provided no informations it's hard to help you. Please note that support time is expensive and Cloudrons support only covers problems that are directly caused by cloudron. In addition, time spent on support cannot be used for development, so it is in our best interest to help you here.

sudo systemctl stop box
sudo systemctl stop docker

then run this command to see if they had:

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

Then, when it was obvious my /boot was stuffed to the gills with prior linux-images, I had to remove old kernels, adjusting the below to the results from above:

sudo rm -rf /boot/*-4.4.0-{98,97,96,93,62}-*

Then, automatically remove unneeded kernels

sudo purge-old-kernels

After that, bring Cloudron back online:

sudo systemctl restart box
sudo systemctl restart docker
sudo systemctl restart cloudron.target

The fact that this occurred in /boot, and not in the main partition, had thrown us for a little while.

@girish can you pls. check on this. services are down for 24h now

create OCI runtime console socket: mkdir /tmp/pty465273103: no space left on device: unknown

Since rebooting worked, I assume you have disk space left on the system? Do you have SSH (root) access to the server? Does the cloudron web SSH console works? Seems to be an issue with cgroups to me. Does your server come with any kind of limitation?

Please post the output of:

• df -h
• df -i
• cat /proc/cgroups
• docker info; echo; echo;