TyantA

Members
  • Posts

    321
  • Joined

  • Last visited

About TyantA

  • Birthday July 30

Converted

  • Gender
    Male
  • Location
    Ontario, Canada

Recent Profile Visitors

1479 profile views

TyantA's Achievements

Contributor

Contributor (5/14)

2

Reputation

  1. That seems to be what I'm observing. I forgot to mention that the error happened as my monthly parity check began, resulting on 2048 error before it aborted and got the red X label.
  2. I find this confusing. Sadly, I don't believe I captured the syslog before shutting the server down. One of my disks scared me with a red X. I ordered new drives, pre-cleared them and started the server up, replacing the one drive. Rebuild went fine. (Which means the controller doesn't have an issue as it's on the same port). Then I took the "red x" drive and put it in my 2nd server. So far, no SMART Errors presented so I ran a quick self test and it says there are no errors. Now I'm running the extended test. My second server isn't vital; what would you do prior to deploying it again - if at all?
  3. I have one unraid box with a 1050Ti in the primary PCI-E slot and a 1660Ti in the secondary. I'm bringing up another system to split out my work and personal needs; thinking of moving the 1050Ti to it (as secondary) and reverting to either my passively cooled GT730 or FX570 as primary GPU in the main/personal rig. I guess I'm giving up NVDEC with support for h.265 which was the reason for this combo to begin with, hrmm. I do have some h.265 content but as I'm limited to 1080p; not much. Maybe I should leave the main server as-is and just accept that the work system is only for work. (The thought had been light gaming one day using separate systems instead of multiple VMs on the main rig). Any input appreciated.
  4. That turl. So because it's a bz file, you're saying they can't (at least easily) be changed outside of an update. So the "low hanging fruit" risk is attack surfaces on dockers and VMs and their inherent potential security issues (ex, Windows), but they are in theory completely isolated from the host OS... and there's nothing really there (Unraid level) that would persist beyond a reboot. So if one were truly concerned, you could blow out / restore a VM from a known clean state and be sure dockers are up to date and follow security best practices.
  5. If it's a website, I'd look for rogue code. If it's Windows I'd just format the system (lol). Unraid? I have no reason to believe mine has been, but I'm still curious - what would one do? I suppose you could start from scratch but would there be an easier way (maintain drive config at least)? Would just copying over fresh Unraid files to flash suffice? Could a compromised VM pose any issues to the rest of the system/network? In theory I'd think not but...
  6. linux 4096 bytes windows 260 characters unless you do some fancy work to disable that limitation but bytes != chars So that still doesn't answer the question. Inquiring minds also want to know if browsing unraid from a windows based machine will run into issues manipulating files in paths beyond 260 characters. And if Krusader is "smart" enough to alert me if files being moved to a longer path will run into issues.
  7. Hello, I'm in the process of reorganizing my data. Due to my multi-level + descriptive directory naming conventions, in Windows I often bump up against "this path is too long" type error. 1) Does unraid/linux have the same path length restrictions as Windows? 2) If I end up moving a directory (and its subdirectories) to a nested folder where the resulting path would be too long, will Krusader notify me of this? I'm (obviously) trying to avoid lost data in the process. TIA
  8. I have a particular disk, it seems. It was pulled from a Windows laptop with the intent of using it as a 3rd cache drive just for file transfers. I installed it, it showed as unmountable as expected with no option to format. (I know where to look). I thought OK, I'll blow away the partitions so I used power shell to delete all the partitions on the drive, then I created a new volume. (There were 7 in total (Dell rig, all sorts of recovery partitions etc.) Left it as raw. I got the dreaded "unmountable -Unsupported partition layout" but there was no option to format the disk. Fine, I brought it back to my PC and formatted it there as an ntfs drive. Dropped it in unraid and this time, the format button showed up, except it didn't work. I tick the "yes I want to do this", format, it says "formatting" then it reverts to "Unmountable disk present and the option to format again. Loop. On the right, it says "Unmountable: No file system". Ideas? Never had this much issue taking a drive and dropping it into unraid. More curiously: I unassigned it from the cache pool and now under unassigned devices, it shows as mounted. [SOLVED] That was my clue. I guess in looking at the disk, I had mounted it as an unassigned device, then, without unmounting it, I assigned it to a pool. Then I couldn't format it. When I unassigned it, unmounted it then assigned it, I was able to format it!
  9. Yes, I have backups of both drive, original apps and trial appdata folders. Ok so what I'm hearing is, because my trial used all default locations vs. the custom ones I had set up, my fresh install is "seeing" the docker.img file which I should obliterate and restart, since my objective is to have a clean start. Cool, I'll try that. What started confusing me was thinking about the fact that the trial put an appdata folder on cache and the array, so the new install would also be pointing to those files, but the current unraid install isn't aware of those installs, so I was planning to obliterate them as well. BUT, one of those has my most recent Plex cache/metadata so I have to be careful. Maybe I should just rename the "old" appdata and move on. Edit: That worked. I nixed the docker image and was able to start fresh. Thanks!
  10. I had an old version of unraid running on my "production" rig. This used a custom /apps folder instead of appdata. I tested moving my plex metadata to a fresh install with a trial USB key. It worked. This created a mnt/user/appdata folder I then backed up and wiped my "production" key as I wanted to start from scratch. This included a brand new cache drive as well. After enabling docker, I saw the two dockers I had set up with the trial key were there, less their icons. I tried removing Krusader. It's gone from the Docker tab but some (icon?) files persiste in /appdata and for whatever reason, installing it again just goes through the motions but it doesn't actually install. The other docker was plex. I'm being careful with that one as it is where my Plex meta/cache data was. I guess I'm just a bit confused as to why those are showing up, having not installed any dockers on this fresh key install. Obviously they live on the array and were (likely) set to "prefer" the old cache drive. I guess as long as it is (also?) on the array, it'll show up in the docker tab too?
  11. One more question. I'm trying to do the following. Would you suggest a particular order of operations other than this? Move Plex linuxserver > binhex while maintaining library/watch data. Install nvidia GPUs I've had on hand forever (1050 Ti, 1660 Ti) FINALLY Upgrade Unraid 6.5.3 > current w/ nvidia support Enable Plex hardware transcoding Replace cache drive showing signs of age Replace 3 older drives with new, larger drives
  12. Thanks squid for the prompt reply. I kind of assumed as much (based on SI's deletion in one case) but being the reverse situation, I wanted to be sure. Thanks again.
  13. I watched SpaceInvader's video covering this topic however his media was already set up to use /media. I'm moving from Linuxserver's container to binhex (possibly plexpass) and need help/clarification for the opposite scenario. My libraries within plex are /tv, /movies, etc. and my mappings are /mnt/user/tv but in the binhex template, it's looking at where to map /media. As you can see, I don't use /media for anything so... how do I handle this move? TIA
  14. I picked up 2x 12TB WD Elements drives and ran 3 preclear cycles on each (which took 9+ days) over USB. Both finished successfully. I checked before and after SMART values; nothing jumping out at me. (see here) I was about to unplug the drive & shuck it when I clicked the preclear log and see countless entries like this: Dec 8 03:21:13 XXXX kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 Dec 8 03:21:13 XXXX kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x88 88 00 00 00 00 05 25 96 70 00 00 00 08 00 00 00 Dec 8 03:21:13 XXXX kernel: print_req_error: I/O error, dev sda, sector 22105452544 I/O error for many, many sectors? Why is this not obvious in the SMART report? The second drive is full of the same. I can't check its SMART values from the Dashboard because for some reason it doesn't show up under unassigned devices. Only sda does. (But both show up under "Main".
  15. Yeah, hence the roadblock. I've come to terms with the fact that it might be time to start my main server "from scratch" hopefully not 100% from scratch though. The main thing I need to figure out how to keep is my plex play data. So, with my secondary key, I'm going to revert back to the fresh trial install and start building it up as though it were my production key. Double the work but at least I can fall back on my main key. Are there any tips for speeding up this process? Or is it just best to start from "as scratch as possible" vs. copying old things over. Some of my dockers are messed up and I plan to swap some out for others, so that should be OK. I've been wanting to re-do my VMs anyway... really just the Plex docker. If I can replicate that setup on the trial key, that'll give me confidence to do this on my production.