• Content Count

  • Joined

  • Last visited

Community Reputation

12 Good

About Delarius

  • Rank


  • Personal Text
    Linux and Openshift administrator.

Recent Profile Visitors

738 profile views
  1. Greetings, I don't have a lot of time right now, but this is definitely fixable. First, please elaborate on this statement if you could. This sounds a bit unexpected. I don't know how you renamed this 'share', but something was missed. Somehow plex or the OS is remembering a disk or share or something regarding "Plex Media Server" but why? Let's look at the configs. So open terminal, and look for that string in the most likely places. grep -R "Plex Media Server" /mnt/user/appdata /etc This will look for any occurrences of this string in both of the above locations
  2. Hi! I think this is the issue. Normally when I do this I don't put a passphrase on the key. It's not the password of the server, it's a special passphrase to make your key more secure. If you want automation, redo your key generation and press enter when you get prompted for a passphrase. You can also test with the verbose flags -v through -vvv in your ssh command to give you a little more feedback about what is failing. Try something like: # ssh -vvv root@mytower.local That should sort this out. Del
  3. Hi, this might not work for your use case, but I have a few virtual machines that I would prefer to have a backup but it doesn't have to be the very latest. This is the lazy mans way of doing this, provided an overnight backup is good enough: Create a file like this one at /boot/config/mybackup that rsyncs whatever you want from cache: #!/bin/bash rsync -a /mnt/cache/domains/ /mnt/disk1/Backup/domains/ ##note disk to disk here - you can do it through the /mnt/user directory too. They are mutually exclusive Then in your /boot/config/go file add two lines like this somewhere:
  4. Try turning bonding off in your existing config file - reboot: BONDING="no" And then what I'd do is start a ping test from another computer, and then unplug all network cables, and plug one in - test in all ports. Then try the other cable and do the same thing if needed. And wow, i totally forgot about that ethtool functionality Hoopster, yeah identify the port with ethtool. Del
  5. Hi tiwing, Something is definitely happening on your machine. In your initial screenshot, note the network traffic? You may be able to gather more information about what is running on your machine by simply going into the terminal and typing: top press q to exit, it should show you what is using your cpu. Diagnostics are always helpful if this doesn't reveal the problem. Hope this helps, Del
  6. Thanks, that's good information. To me, it looks like the bridging/bonding part isn't quite right, note how a few pings went through, but in ifconfig we see that eth0 appears down? I suggest, just for troubleshooting, test out a variation on my network.cfg So, make a backup of network.cfg (we can just move it for now) # mv /boot/config/network.cfg /boot/config/network.cfg.Mar42021.bak then make a new file at /boot/config/network.cfg with your favorite editor (vi, nano, pico, whatever). Might be easiest to shutdown - copy the file using another computer to the usb stick and then t
  7. Hi Drackeo, Something is definitely amiss with your network. If possible, it would be useful to try the following things. 1. from the unraid cli - can you ping the gateway? Hopefully you get something back. # ping 2. Can you send the output of two commands? First shows all the interfaces, and the second will show your routing. # ip a # ip r Post that information and we might be able to figure out what's going on. Hope this helps, Del
  8. Greetings, Long time since i've posted here. I hope this is still a valid way of doing things but seems to be working for me in 6.8.3 You should have a file at /boot/config/rsyslog.conf That's the base config file for rsyslog, what i often do is just drop messages entirely. Again, forgive me if i haven't stayed current, but what i do is the following. 1. open up /boot/config/rsyslog.conf with an editor 2. find the line that reads: # limetech - everything goes to syslog. 3. underneath that line, add a log exclusion: :msg,contains,"connect from 192.1
  9. Just a small tip, having seen this a few times where users (and sometimes sysadmins) are a bit puzzled by immutable. If you do change attributes to immutable - be sure to remind yourself which files you changed and how to undo it. Never fails if you don't, in a few months you'll be trying to remove those files and will find it surprisingly challenging. Del
  10. I thought there was now a reset password button on the main login but I have no idea how it works, so here's an alternative that should work to at least restore command line access to the root account: If you have access to a linux command line - this would probably work on a live DVD. Rename the files on the USB in /config back to the original names. On a Linux command line run these commands - replacing MyUnRaidPassword with your desired password python -c "import random,string,crypt; randomsalt = ''.join(random.sample(string.ascii_letters,8)); print crypt.crypt('MyUnRaidP
  11. Glad I could help, I'm fairly sure libvirt has its own way of figuring out routing, so that's why your VMs and quite possibly dockers were still working. Del
  12. Greetings, I had a weird quirk like this a few weeks ago. This may or may not be your problem. You can check in two ways: - In Settings -> Network - make sure your default route is set to the correct gateway. or - In terminal type either: ip r route Route can take a moment to finish - check the default route is set to the proper gateway. You should also check that you don't have any odd routing - you'll likely have 4-6 routes for internal routing which is fine - they should generally only point to internal (non routable) networks. You can
  13. I'd guess the files/directory might have a the 'immutable' attribute set. You can check with: lsattr /path/2/problem/fileordirectory if you see an 'i' in the listing it's immutable - fix it with (you might want to use -R to do it recursively): chattr -i /path/2/problem/fileordirectory That should allow you rm the file if needed. Del
  14. I think you might be misunderstanding how the cache drive works. The cache drive is generally intended to provide faster, unprotected storage for things that need snappy storage - in many cases things like virtual disks, or possibly appdata If you want items protected, they need to be on the array. If you want them fast, on the cache. You can certainly probably use a tool to make backups of your cache to the array, which is what most people likely do. Del
  15. I agree it is somewhat misleading but the dashboard cpu meter in my view is intended to show if there's a problem. If you do have very high i/o wait then that's almost certainly an issue, and thus it's displayed - to warn you. It might be nice to have a toggle so you could see the actual cpu load, but this can also be done through the system stats plugin. Or just using top. Just my two cents, Del