MidPackPark Posted November 27, 2017 Share Posted November 27, 2017 Hello, I've been using unRAID for for a few weeks and have not had a problem. Today I log in and the array is not started or accessible and this message is across the top: Warning: file_put_contents(): Only 0 of 1675 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php on line 997 I tried accessing logs but it eventually times out. Is my USB bad? What should I do? Link to comment
Squid Posted November 27, 2017 Share Posted November 27, 2017 9 minutes ago, MidPackPark said: I tried accessing logs but it eventually times out. I'm assuming you meant diagnostics. (Tools - Diagnostics) Can you do this instead from the locally attached keyboard / monitor or via an SSH (putty session) cp /var/log/syslog /boot/syslog.txt and then post the resulting file stored on the flash drive. that and df -h and post the output. Hard to know 100% what's going on (or give anything other than a wild guess) without at least a syslog. Link to comment
MidPackPark Posted November 27, 2017 Author Share Posted November 27, 2017 2 minutes ago, Squid said: Can you do this instead from the locally attached keyboard / monitor or via an SSH (putty session) cp /var/log/syslog /boot/syslog.txt and then post the resulting file stored on the flash drive. I'm trying a putty session. I can't remember. What is the default UN and Password? I've tried admin admin and it didn't work. Link to comment
Squid Posted November 27, 2017 Share Posted November 27, 2017 login: root password nothing Its the same password you use to hit the UI Link to comment
Squid Posted November 27, 2017 Share Posted November 27, 2017 I also posted above an additional command for you to do. Link to comment
MidPackPark Posted November 27, 2017 Author Share Posted November 27, 2017 When I type the first command nothing happens. When I type the second command I get: Filesystem Size Used Avail Use% Mounted on rootfs 32G 32G 0 100% / tmpfs 32G 332K 32G 1% /run devtmpfs 32G 0 32G 0% /dev cgroup_root 32G 0 32G 0% /sys/fs/cgroup tmpfs 128M 128M 0 100% /var/log /dev/sdb1 7.3G 165M 7.1G 3% /boot /dev/md1 7.3T 3.7T 3.7T 51% /mnt/disk1 /dev/md2 7.3T 3.0T 4.4T 41% /mnt/disk2 /dev/md3 1.9T 1.9G 1.9T 1% /mnt/disk3 /dev/md4 1.9T 1.9G 1.9T 1% /mnt/disk4 /dev/md5 1.9T 1.9G 1.9T 1% /mnt/disk5 /dev/md6 1.9T 1.9G 1.9T 1% /mnt/disk6 /dev/md9 1.9T 1.9G 1.9T 1% /mnt/disk9 /dev/md10 932G 1021M 931G 1% /mnt/disk10 /dev/md11 932G 1021M 931G 1% /mnt/disk11 /dev/md12 932G 1021M 931G 1% /mnt/disk12 /dev/sdc1 477G 83G 395G 18% /mnt/cache shfs 27T 6.6T 20T 25% /mnt/user0 shfs 27T 6.7T 21T 25% /mnt/user /dev/loop0 20G 4.2G 15G 23% /var/lib/docker /dev/loop1 1.0G 17M 905M 2% /etc/libvirt shm 64M 0 64M 0% /var/lib/docker/containers/5287216d4cfce0270bb0343b3b61fb3a945cb7375952647bcf55b08898ee3b5c/shm shm 64M 8.0K 64M 1% /var/lib/docker/containers/a4d2432fd70a77585170a19bc1b4e263626c7e6d5fd8942aa6ea3958bb598d21/shm Link to comment
itimpi Posted November 27, 2017 Share Posted November 27, 2017 The root file system is full. I would expect it to be more like 5% used or less. That suggests you have a docker or something similar that is configured incorrectly and is thus writing files to RAM rather than a physical drive. Link to comment
MidPackPark Posted November 27, 2017 Author Share Posted November 27, 2017 4 minutes ago, itimpi said: The root file system is full. I would expect it to be more like 5% used or less. That suggests you have a docker or something similar that is configured incorrectly and is thus writing files to RAM rather than a physical drive. Does this screenshot help? Link to comment
Squid Posted November 28, 2017 Share Posted November 28, 2017 1 hour ago, MidPackPark said: When I type the first command nothing happens. Nothing would happen except a file is created on the flashdrive called syslog.txt upload that file here. You should still be able to access the flash drive over the network. If you can't access the flash over the network, then see if this returns anything ls -ail /boot If syslog.txt appears there (and does NOT have a size of 0 (the 6th column), then reboot powerdown -r and when the system comes back alive post the file If syslog.txt is not there (or has a size of 0 or nothing is there at all), then post the result of this before you reboot tail -n 20 /var/log/syslog *A reboot will at least temporarily fix all of your problems, but I'm trying to figure out what happened so that we can fix whatever caused this in the first place Link to comment
MidPackPark Posted November 28, 2017 Author Share Posted November 28, 2017 Okay back at this... The syslog.txt file is attached Everything seems to be working fine now. Weird. My boot device is only showing 166MB used. Thoughts? Is everything okay? syslog.txt Link to comment
MidPackPark Posted November 28, 2017 Author Share Posted November 28, 2017 Well it happened again out of the blue. I reset and still get the same problem. Attached is the updated syslog.txt file syslog.txt Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 Any ideas? I'm a couple days away from having to purchase and cannot do that if I keep having this problem. Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 My USB drive is 97% free according to Krusader Link to comment
JorgeB Posted November 29, 2017 Share Posted November 29, 2017 Bond settings are not correct, log is flooded with: Nov 28 14:24:20 unRAID kernel: br0: received packet on bond0 with own address as source address Nov 28 14:24:20 unRAID kernel: br0: received packet on bond0 with own address as source address If possible always post the complete diagnostics. Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 7 minutes ago, johnnie.black said: Bond settings are not correct, log is flooded with: Nov 28 14:24:20 unRAID kernel: br0: received packet on bond0 with own address as source address Nov 28 14:24:20 unRAID kernel: br0: received packet on bond0 with own address as source address If possible always post the complete diagnostics. Okay. So I tried unbonding the network connections and it says: VM manager and Docker service must be Stopped to change I tried stopping both the Docker service and VM manager in the settings but neither will stop and keep defaulting to yes (on) Link to comment
JorgeB Posted November 29, 2017 Share Posted November 29, 2017 Reboot and try right after boot. Link to comment
saarg Posted November 29, 2017 Share Posted November 29, 2017 Stop the array before doing changes in the network settings. Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 Sheesh. I was able to reboot but now I can't access the GUI. I've tried a few different computers and browsers. I can SSH in just fine so everything seems to be up and running. Thoughts? Link to comment
JorgeB Posted November 29, 2017 Share Posted November 29, 2017 Type diagnostics on the console and upload the zip saved to the flash drive. Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 This is the diagnostics file I can ping the server. It does seem to take an abnormally long time to boot up and I see a lot of errors spit out on the boot screen. tower-diagnostics-20171129-1236.zip Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 Is there a command I can send via SSH to un-bond the nic's? I tried unplugging one of the network cables but still have the same issue Link to comment
JorgeB Posted November 29, 2017 Share Posted November 29, 2017 Easiest way is to boot with the GUI option then use the local browser to reconfig the network. Link to comment
MidPackPark Posted November 29, 2017 Author Share Posted November 29, 2017 Okay. That seemed to solve the problem....for now. Not sure what happened. I've been operating with bonded nic's since the beginning without any issues. Thank you very much for the help guys!!! Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.