December 22, 20178 yr So it looks like while attempting to install a version of the koken docker (photography file management system, php with database) I have inadvertently modified/destroyed/created files which are currently conflicting with unRaid webui. I can not start both radarr and sonarr for some reason (missing from docker ps, along with other dockers. Images still found) and performing tasks in the webui is not possible including obtaining logs. I have also noticed that this isn't an issue while the array is offline, so some offending file/s are located within the array somewhere and not on the boot usb. The best I could do in terms of logs is attached as UnRaid_Log.txt and there's also an image of what the main page in unRaid looks like. Along with the page looking like that the page title is now referred to as /Main. How would I fix this uninitialized csrf_token issue? If it means a new copy of unRaid on usb then will I lose my dockers/files etc? Thanks for the help! UnRaid_Log.txt
December 22, 20178 yr Community Expert Not clear what you have done but your post is not a defect report, and there is no evidence of a defect, so I am moving to General Support.
December 22, 20178 yr What would really be great is if you could post the output of df -h Thus far there has only been a single reported case of uninitialized csrf token, and anecdotally it was related to the rootfs being 100% full. Ultimately, your recovery is probably going to wind up having to restart (post the output first though). Unless you've really played around with having strange path mappings for your containers (ie: like mapping / to /), a container won't be able to actually trash unRaid. Its more likely that you've got a container storing some huge datafiles in memory itself which is causing the problems.
December 24, 20178 yr Author Here is the output of df -h, and it looks a full rootfs is the culprit: Filesystem Size Used Avail Use% Mounted on rootfs 32G 31G 427M 99% / tmpfs 32G 528K 32G 1% /run devtmpfs 32G 8.0K 32G 1% /dev cgroup_root 32G 0 32G 0% /sys/fs/cgroup tmpfs 128M 2.9M 126M 3% /var/log /dev/sda1 15G 416M 15G 3% /boot /dev/md1 7.3T 7.3T 23G 100% /mnt/disk1 /dev/sdd1 2.8T 70G 2.7T 3% /mnt/cache shfs 7.3T 7.3T 23G 100% /mnt/user0 shfs 11T 7.4T 2.7T 74% /mnt/user /dev/loop0 20G 11G 8.6G 57% /var/lib/docker shm 64M 8.0K 64M 1% /var/lib/docker/containers/9dbad0aa6c20fd0833645d215d8ce27703b69bf832fe9121d41229548d61a053/shm shm 64M 4.0K 64M 1% /var/lib/docker/containers/b14c60be0840883e6155a12ec6e923031b8bbc28cd9e2a273341c14d59d10432/shm shm 64M 0 64M 0% /var/lib/docker/containers/5444c7e05c38f77b70232cc8dff0086ed82181276b0e8d2dec2b5249c7ab170a/shm shm 64M 0 64M 0% /var/lib/docker/containers/cb31bf35203a91123eda5f22282f796562033d25766c124e4c66548e2a6f4125/shm shm 64M 0 64M 0% /var/lib/docker/containers/e64c5e0185ae4453369c419410f632402895d25e71751c2247256c9d18f10657/shm shm 64M 0 64M 0% /var/lib/docker/containers/369e640324494d30ccd3ca5e60fc091349ece66ace3bfc40af1ec11d3e685a1b/shm shm 64M 0 64M 0% /var/lib/docker/containers/85728a7e088d062d7e270d41863e7f1a2d60970b0aa2fa2b5b6ebeb3a53bd955/shm shm 64M 0 64M 0% /var/lib/docker/containers/70a081bdb59a771a2dfd4e9d3c9dab1de9b3b4706469485ede1095a0030fd92e/shm shm 64M 0 64M 0% /var/lib/docker/containers/1513089c13cda75e68d7794f1775ce4bfe207207deb34f07ba0f78f92b998c43/shm shm 64M 0 64M 0% /var/lib/docker/containers/5cd45170bafec81656c1cf0656989b752c194512cf1f000f70851cb2534a4834/shm shm 64M 0 64M 0% /var/lib/docker/containers/9ab5a25be0fe3716df2228083819a757c9dd244f2e7d9f24c9ef07065df7dc67/shm shm 64M 9.3M 55M 15% /var/lib/docker/containers/5ae34418546c5964ac2a86a188a99752106de93d5121c404309902eaf3471a2d/shm /dev/loop1 1.0G 17M 905M 2% /etc/libvirt /dev/sdc1 2.8T 879G 1.9T 32% /mnt/disks/WDC_WD30EZRZ-00GXCB0_WD-WCC7K1XF5ZZC shm 64M 4.0K 64M 1% /var/lib/docker/containers/969e9d786fb38c2f1a49b60d44007b5c8fdaf10544b687486ae05ef422f6bf20/shm shm 64M 4.0K 64M 1% /var/lib/docker/containers/098d2217a58c27273e4a3fbdc163b7727638b6364bfbe76b2436785342f8ae53/shm What's strange is I was monitoring unraid upon a reboot and restart of array and rootfs fills completely and what felt like instantaniously on this line (something in sa1/sadc): Dec 24 22:47:01 Server crond[2112]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Not sure why initializing this script would cause something like this, but it might be useful. Thanks for the help!
December 24, 20178 yr 27 minutes ago, Firelfy said: Here is the output of df -h, and it looks a full rootfs is the culprit: Yup. If you have that container set to autostart, then disable it and then reboot. After that, edit the container and post a screen shot of all the path mappings (or ideally, edit the container, make a change, revert the change and then hit Apply and post the resulting docker run command that appears.
December 24, 20178 yr Author If you're referring to koken, it has been removed (afaik completely within shell) along with it's appdata.
December 24, 20178 yr Author Yep. I'll mention I used this koken docker script to generate the docker, adjusting for variables such as port, and changing path mappings and so on.
December 25, 20178 yr Author 6 hours ago, Squid said: Reboot Rebooted, still having the same issue. Just remembered I had telegraf mapped to / for access to system info, this is how the docker is designed to be setup. In order to conclude whether this was the issue or not I stopped influxdb/grafana and telegraf upon array initialization and I'm still having issues. The array is fine up until this script is run: /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 In which I get this error: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null My rootfs before this command is run is nowhere near full (2% usage usually) so there's something going on with sa1/sadc. Edited December 25, 20178 yr by Firelfy Added info refarding telegraf/influxdb etc
Archived
This topic is now archived and is closed to further replies.