• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About unw1red

  • Rank
  1. As long as your server is wired, data will not traverse the router unless it being used by a wireless client or if the client is on a different subnet than the server. Meaning, if you are trying to read from InfluxDB container from Grafana container, via the server IP, the data will not traverse your router. It will be horseshoed through the eth0 interface. Make sense?
  2. I have my server connected to a router with a NATed IP to the Internet. It is not on a DMZ. I have some port forwarding in place for Let's Encrypt. That is working as it should. I also have noticed that I can reach the internal ports of the Docker containers via the Internet to the Public IP address. Does this have anything to do with using both an Ethernet and Bridge interface on the server. I have br0 bridging eth0. If I turn off bridging, will the Docker containers stop being accessible? I do not have any VMs or docker containers using alternate, local IP addresses. On my router
  3. Additional question on this topic. After making the above changes, should you then set your appdata share to Cache: ONLY?
  4. I just found this thread as well. I having been dealing with the SHFS problem for the last several weeks about every other day. It required a hard reset to clear. My server is currently in this state and I was trying to troubleshoot the situation. I found a couple of things: 1. The CPU load on my dual Xeon 2.0GHz 12 core/24 thread is climbing steadily and at about >=30.00, certain Docker containers become unusable 2. If I SSH into the server and try to do any dick I/O in the /mnt disk structure (except for /mnt/cache/appdata), the terminal session locks up and has to be kil
  5. I may have figured this one out, but I was wondering if anyone else had seen this situation. I have a Supermicro 12 HDD chassis with a Supermicro dualXeon motherboard, 12 cores and 24 threads and 128Gb of RAM. I am running about 10 Docker containers with Home Assistant, MariaDB, Radarr, Sonarr, Plex, and Zoneminder (at the time this was happening). After about 1-2 days after a clean boot, my server would not allow me to connect or use any of the Docker containers. I couldn't kill, restart or upgrade them from the UI or CLI. The processor load would hit about 40-50 when
  6. What procedure did you use to upgrade the disk? Did you use the data rebuild procedure? Did you preclear the disks?
  7. As the primary network connection or as an access point? This is from the wiki Realtek - RTL8169S, RTL8111B, RTL8111C, probably others too ***NOTE - MANY PEOPLE REPORT ISSUES WITH REALTEK, SO CHECK THE FORUMS BEFORE ASSUMING YOUR BOARD WILL WORK***
  8. You need to make sure both sides of the link are configured the same. Sometimes, a LAGG can be configured to LOAD BALANCING on one side and 802.3ad on the other and it will bounce interfaces until the end of time.
  9. Can you post the config for your switch for the UNRaid interfaces?
  10. NextCloud updated last night and successfully started. I tried my NextCloud app from my phone this morning and noticed that I could do no writes to my account. I can read the files, but I can't create a folder or upload. I then looked at the logs for NextCloud and all seems correct. I then tried to reboot the server with to no avail. I opened an UNRaid console and ran htop. It shows that the processor is running away (40.0 and growing on a 12-core, 24 thread server). The CPU usage is steadily climbing and the prevalent process is "/usr/local/sbin/shfs /mnt/user -disks 127 204800000
  11. After two and a half days, and a reboot, all went back to normal. Thanks for the help.
  12. Once the rebuild completed, I rebooted the system. All came back fat and happy. The error messages are no longer appearing in the syslog. I will now move onto replacing a 3TB drive with a 12TB drive and allowing parity to rebuild the data drive. Cross your fingers.
  13. I just found those messages as well. I am at 93% on my data rebuild. After it is done, I will reboot and report back.
  14. The only thing that stands out in the logs, barring the backups that are trying to be performed but can't, is this block. Nov 11 05:30:16 Musial emhttpd: shcmd (4942): /usr/sbin/hdparm -y /dev/nvme1n1 Nov 11 05:30:16 Musial root: HDIO_DRIVE_CMD(standby) failed: Inappropriate ioctl for device Nov 11 05:30:16 Musial root: Nov 11 05:30:16 Musial root: /dev/nvme1n1: Nov 11 05:30:16 Musial root: issuing standby command Nov 11 05:30:16 Musial emhttpd: shcmd (4942): exit status: 25
  15. I used this procedure for this operation... https://wiki.unraid.net/The_parity_swap_procedure