June 22, 20188 yr So I found where the data is but I dont know why its in here. root@10:/var/lib# du -sh /var/lib/docker/btrfs/subvolumes* 41G /var/lib/docker/btrfs/subvolumes When i run du in this directory, i get a bunch of these directories. 142M /var/lib/docker/btrfs/subvolumes/00b4acf750cf0e59e0d38dd529c8097fea9b79825b5cdef8b8d799e759d05a79 509M /var/lib/docker/btrfs/subvolumes/00f2827538376a35cc2c0bc1d53d3bf70ca5623d6c74be6d0a101e96b7e35ec7 503M /var/lib/docker/btrfs/subvolumes/00f2827538376a35cc2c0bc1d53d3bf70ca5623d6c74be6d0a101e96b7e35ec7-init So what are these directories and why are they filling up? Current server up-time is less than 2 days. 10.1.1.2-diagnostics-20180622-0837.zip
June 22, 20188 yr 46 minutes ago, icemansid said: 142M /var/lib/docker/btrfs/subvolumes/00b4acf750cf0e59e0d38dd529c8097fea9b79825b5cdef8b8d799e759d05a79 509M /var/lib/docker/btrfs/subvolumes/00f2827538376a35cc2c0bc1d53d3bf70ca5623d6c74be6d0a101e96b7e35ec7 503M /var/lib/docker/btrfs/subvolumes/00f2827538376a35cc2c0bc1d53d3bf70ca5623d6c74be6d0a101e96b7e35ec7-init This is part of the docker.img file and isn't the problem of your rootFS filling up Jun 22 04:42:34 10 root: #012/dev/sdk:#012 drive state is: standby Also not your problem, but you've got debugging turned on in CA Auto Turbo which does nothing other than spam the log unnecessarily if there's no problem This is my best guess: Jun 21 07:30:07 10 unassigned.devices: Remote SMB share '//10.1.1.50/Shawn' is not mounted and cannot be unmounted... Jun 21 07:30:07 10 unassigned.devices: Remote SMB share '//UNRAID-BACKUP/TV' is not mounted and cannot be unmounted... I can't tell what you've got for docker volume paths etc, but if I take a leap and you've got those mapped to a path in a docker template and the container happens to write (ie: download) to them, then what happens is that the host path (/mnt/disks/UNRAID-BACKUP/ eg) gets created in RAM, and the downloads happen to RAM instead of the SMB share. Either way, the odds are excellent that you've got a misconfigured app somewhere that is saving stuff to RAM instead of to a disk.
June 22, 20188 yr Author OK - CA Turbo debug turned off. Those two remote SMB shares are on another unraid server and are accessed only by an rclone script that runs as a backup of file. The server is off at the moment so it is very possible that its doing what you said. With that said - why is it writing to RAM instead of just not having the share accessible? Edit: Scripts have been disabled and serer is getting a reboot. Edited June 22, 20188 yr by icemansid
June 22, 20188 yr If you start watching the output of df every once in a while and see it growing, and then correlate that to what the various apps are doing at the time you should be able to figure out which one. Could be something like a typo If you've mapped say /mnt to /mnt and within the container are referring to /mnt/usr/downloads instead of /mnt/user/downloads, then the downloads wind up going to RAM.
June 24, 20188 yr Author Squid Thank you thank thank you! you have helped me out more times than you can imagine! a few direct and many indirect. A few days and we are still going strong.
Archived
This topic is now archived and is closed to further replies.