phbigred

Members
  • Posts

    265
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by phbigred

  1. Yup you can do as listed, or... If you think you can wait it out a day swap your 5TB for the 8 and rebuild parity. That way (assuming you aren't adding and removing a lot of data) you have a backup copy of your parity info should the drive die. One other option would be to pull your drive and let it emulate contents and copy the virtual data to an off array drive. This is a parity risk as is my first option, however the first one is a safer bet should your array croak. Any way you do this get that data off now before it dies.
  2. Also under advanced under Extra Parameters on all your dockers add: --log-opt max-size=50M --log-opt max-size=1 This limits your logging size making it stay lean. I "think" it was Unevent that posted this a while back.
  3. Had the same issue with starting. I baselined my settings and didn't do any tuning pulling all plugins. Only plugins I had installed was CA and backup. Pulled backup and removed the docker and did a repull. Then it started, odd I would find that one causing an issue. Post rebuild I did reload tips and tweaks and recycle bin and haven't had issues. Did you recently update any plugins? Not fully placing the blame on CA Backup but that's what I removed to fix. My log starting looked the same as CattDamon's above.
  4. Agreed with the above I have multiple Win 10 boxes that I've had absolutely no problem with. Win 10 sees it as smb 3 and communicates with it normally. Have a "vanilla" load of Windows you can test with? Most likely it's the security/AV software causing the issue. Especially with losing ping it's been blocked by something.
  5. I was reading up to a free GB. Never monitored that closely as I have 16GB free.
  6. Yeah that / in the path has gotten me a few times. Don't do it very often. Btw if you have enough RAM free run transcode from /tmp that makes it run on a RAM Drive.
  7. Well I had the same thing happen. Found out that (even after clearing out my flash drive) as soon as I put on the CA Backup it caused the problem. Removed the CAbackup manually by removing the plugin from another machine. Bingo, spent 3 days trying to get it going. Tried all 3 main dockers. Linuxserver.IO Limetech PlexMediaServer and plex.inc. All with similar problems with the exception of Limetechs. It was throwing a 6 1000 error. Wonder if something in CA Backup is causing a loop as I've never had it happen before!
  8. Pull the USB and make a copy of the drive by pulling it into a folder of your desktop, then go to lime-technology site and download the zip. Extract and copy the 3 "bz" files to the root of the USB drive and pop it back in you NAS. Should boot and it gives you assurance you have a copy of your drive should something go south.
  9. Found this in another board for IOMMU for a B350, ASUS appears to possibly have it in a different menu than documented. Yeah, found it. ASUS is lying in the manual. It was in Advanced>AMD CBS submenu, and not in CPU Configuration. One has to wonder which side is to blame - the writers of the manual, or the BIOS developers.
  10. Something to try, boot in safe mode if you can live without plugins and dockers for a bit and see if it locks up. Could be a plugin or docker locking up the OS. I had some oddities with one of the 6.3 RCs that I never got nailed down but it could be RAM or something too. The safe mode would be something to try until the moderators chime in. If you have install the fix common problems plugin and turn on troubleshooting mode to capture a log before it dies as well.
  11. If you can get to console type diagnostics and upload them otherwise do it in GUI under tools Diagnostics. Post here and smarter people than I can read them. Might be a repair of XFS BUT POST DIAGNOSTICS BEFORE DOING ANYTHING! *Steps off soapbox* and wait for a response.
  12. Board, CPU, RAM should be straight forward. As you know about the assignments that should be all you need. For grins before you do any hardware changes copy your USB drive off to something in case something gets borked. Drives should be picked up and in theory start running as soon as you turn it on. I converted from Intel Celeron to i3 to AMD 8350 all without doing much other than swapping board, CPU, RAM. Just make sure all your drive connections are seated before turning on and if you have a SAS card that it fits the motherboard otherwise that might be a purchase. (i.e. PCI bus and what you buy doesn't have one) Whatever you look to replace with look to see if it has Vtx-d or IOMMU if you want to play with hardware pass through. Dockers are useful too as I'm sure you've gathered. Good luck and god speed!
  13. Unless you change the port the dockers will fight one another. Here's a thought, on your clients try turning off direct play. Depending on the client I've had to do that, thinking iOS devices in particular. Let the plex transcode everything rather, takes a bit to buffer (seconds) but then is rock solid. Also you haven't mentioned the hardware you're running on. In the docker forum under plex make sure to give them all that info.
  14. I was thinking for parity check speeds as that's a write intensive process, slower the drive the longer the checks take. I've tested this with a 7200 and 5900 drive. Difference of close to an hour.
  15. Garycase's option #1 would be the route I would go, didn't think about that one. That way you remain under parity protection.
  16. Biggest thing keep your faster drives for parity otherwise I don't think you'll have a problem unless you have a network bottleneck.
  17. Keep track of your parity but do a "new config" after you remove your disk and put in the new one. Make sure your default disk format is xfs in settings disk settings before you turn on your array. (Preclear too if you haven't) Parity will have to rebuild being the only risk to this. ALSO with that many disks have you considered double parity?
  18. Are you copying and pasting the XML UID in when building it to these clones. Might be a workaround. (First few lines reference it in the XML)
  19. Or if you don't care about the data, preclear them and bring them in and move your data to them. (Or whatever they are in now see if you can whittle down the disk footprint to free up 2 disks.) Otherwise as my storage team calls it, a massive game of Tetris will ensue. Hell even if you have an external drive or 2 just to give wiggle room. Get creative, unraid can mount unassigned drives with the unassigned drive plugin. Granted data will be temporarily unprotected but it's an idea. Just weigh the risk/reward and move forward with your plan.
  20. True enough Turl I was thinking for the "oh crap" I didn't copy something factor.
  21. If there is data you care about on the drive, recommend doing what I'm working on currently. Run a non-correcting parity check and make sure you have no errors. Identify your "newest" disk by looking at smart hours running. Then use MC (midnight commander or some other tool) to move data off the disk you identified to another disk by doing a disk to disk move. NEVER go disk to share or share to disk as the system can lose data that way. (IE folder /mnt/disk1/share1 to /mnt/disk3/share1 and step data over.) Once your data is off the disk you identified, shutdown your array and pull your disk. (This can be done before you add the 2TB drive). Power on your unraid, then as the drive is missing go to the GUI and identify the parity drive, take a pic of your screen if you need. Then go to tools and choose new config. What this does is clear the assignments and the reason you identify the parity as it doesn't have a file system so you assign it again as parity. This also allows you to reorder your disks as well, should you have different sizes. Now at this point you can assign parity and do a parity rebuild leaving the 4tb you pulled out of the array JUST in case something borks. Once parity finishes run another non-correcting and verify its at 0 errors. Check to make sure your data looks "good". Then stop your array and assign your old 4tb as 2nd parity, and add your 2TB drive(s). This process assumes you have enough free space on other drives to absorb the data from the drive you pulled. If that isn't the case where I say "this can be done before adding 2TB drives" add the 2TB drives at this point instead and move data around to the new drives. Assuming they are pre-cleared for ease.
  22. Somewhere over the rainbow or 3rd or 4th whatevs
  23. Ssh in and type virsh list. Find your vm that's stuck and type virsh destroy (vm_name) that will kill the vm so it can be reset/fixed for versioning or just getting back online.
  24. If you have fix common problems installed from community apps turn on troubleshooting mode. It should catch the state of your hardware right before the crash. Once you get it turned on and it "dies" turn off and snag the logs off the usb on another computer (should be a time stamped diag file) and post up here. Also just to get you running if it's a plugin go to safe mode on boot after snagging the diagnostics. Then you can hopefully be running while the smart people look at the logs and give recommendations to try.
  25. Upgrade from 6.3.1 was uneventful, which is good!