Edit:
Thanks @Mike !!
Indeed, the problem was the filesystem. CS:S server starts fine now.
This seems to be an unRAID specific problem, since there is a difference between access a disk directly (btrfs in my case) and access a share (fuse.shfs):
root@xxxx:~# df -T /mnt/nvme_pool/amp_data/
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/mapper/nvme0n1p1 btrfs 500090200 377488328 121472232 76% /mnt/nvme_pool
root@xxxx:~# df -T /mnt/user/amp_data/
Filesystem Type 1K-blocks Used Available Use% Mounted on
shfs fuse.shfs 500090200 377488328 121472232 76% /mnt/user
Looks like srcds (or AMP) doesn’t like it’s files to be written to fuse.shfs, but btrfs is fine.
For anyone else having these issues in unRAID, all I did was changing the Unraid Source Path in VM settings from /mnt/user/amp_data/ to /mnt/nvme_pool/amp_data/. In this case, unRAID doesn’t manage, which files are being written to which disk, which is fine for me.
The mount point in the VM in fstab stays the same.
old:
On host:
root@xxxxxx:~# df -T /mnt/user/amp_data/srcds01/
Filesystem Type 1K-blocks Used Available Use% Mounted on
shfs fuse.shfs 500090200 377538632 121421752 76% /mnt/user
In VM:
Dateisystem Typ 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
udev devtmpfs 5075024 0 5075024 0% /dev
tmpfs tmpfs 1018576 692 1017884 1% /run
/dev/sda1 ext4 9232860 6235568 2506696 72% /
tmpfs tmpfs 5092864 4 5092860 1% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
amp_data 9p 500090200 377538868 121421564 76% /mnt/amp_data
tmpfs tmpfs 1018572 0 1018572 0% /run/user/1000