Error setting cgroup config: Failed to write "4905" to io.bfq.weight

[Joniator]

Background (please complete the following information):

• Panel or Daemon: Daemon
• Version of Panel/Daemon: Wings 1.3.1
• Server's OS: Fedora 32, Kernel 5.10.22
• Your Computer's OS & Browser: Windows 10, Edge

Describe the bug
The daemon is correctly configured on my fedora 32 server. An identical installation on the server hosting the panel (ubutnu 20.04) works just fine. The panel recognizes the daemon and shows its status as healthy.
The container gets created, and if I try to start the container with docker start I get the same error as I get in the client. All my other containers work just fine, it seems like there is some Issue with the way the daemon creates the container.

To Reproduce
Steps to reproduce the behavior:

1. Install Wings on Fedora 32
2. Register Wing in Panel
3. Create and Start any server (Minecraft and Valheim tested) with or without limits
4. Installation is successfull, files get created
5. Try to start the server
6. The server wont start, error:

Errormessage

container init caused: process_linux.go:458: setting cgroup config for procHooks process caused: failed to write "4950": write 
/sys/fs/cgroup/system.slice/docker-b1942d97385d43f64e8f6d85ad1f96cd9aa3f9408339a0d5a89fa6a0a07ae976.scope/io.bfq.weight: numerical result out of range: unknown

The hash in the path is the correct one for the container, but the Path does not exist.

ls -la /sys/fs/cgroup/system.slice

drwxr-xr-x. 60 root root 0 Mar 15 09:17  .
dr-xr-xr-x.  5 root root 0 Mar 15 08:55  ..
[...]
drwxr-xr-x.  2 root root 0 Mar 15 08:55  dev-hugepages.mount
drwxr-xr-x.  2 root root 0 Mar 15 08:55  dev-mqueue.mount
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-3bd9eca45cae7068ca91506dbacf62c0937e2b29bb84d6f6e345b717e779687f.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-4b9fe68d7f79ec68fba4077f2f16d7e25a9319ffa4af93006a3119df61210817.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-5561b112b7ada5760eb2fd2f2653160f35a00fddd0c22654ddbee6581eff3529.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-56b05f2c4ea131147e1cb344b12c3c786d16c7fc03a5b19a739e60fb22be412e.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-8813b4a1d9bad05ad7f3ccbf6b043bc60291be07ae99cedf8ea9c4d3c730abb4.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-c8fdb2c4f9ff24e6008f434af675b807308a7b1d64d948a92aa1bbc3d5eef8f3.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-e8b64693165800294d8d36f6cf961d04a8c17e474783c77c659d7902fab7a339.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-edffec39d9511a8b91d1bdf93b447a8f4f0bbe0e0b32429cc89f0e90e16df85a.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-f2b61e9f5c93fcef130887c08c8146a98a29b3bf7262dc077418c12b2e3e60c7.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker-fd67bbacce580a890f40e43d2cd27cf5f747e11c885157068271f2fc094df8e5.scope
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker.service
drwxr-xr-x.  2 root root 0 Mar 15 08:55  docker.socket`

Diagnostic Report

Expected behavior
I would have expected the daemon to properly create and start the docker container

[parkervcp]

I suspect this has to do with how fedora/rhel have cgroups set up in their most recent releases.

[DaneEveritt]

This appears outside the scope of this software and is likely an issue with Docker itself, not Pterodactyl.

[Joniator]

It is most likely an issue with docker and cgroups v2, which is not really supported as of now. But I somehow got docker working with cgroups v2 on the broken machine, while my other Fedora 32 works just fine with pterodactyl.

Using docker info I looked at the cgroups versions of both of them:
The working machine uses Cgroup Driver: cgroupfs, and the broken machine uses Cgroup Driver: systemd and Cgroup Version 2.

I am not sure how I got docker to work with cgroup v2 in general, but this seems to be the problem.

If anyone else runs into this or a similiar problem, and you don't depend on some cgroup v2 features, you can go back to cgroups v1 like this.

This are the commands that I used for the working machine, and I will try this solution on the other machine.

Edit: The above link worked, I downgraded to cgroups v1 and now everything is running just fine