scooterbaga

Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by scooterbaga

  1. Apologies for more issues to the pile...

     

    Hadn't occurred to me until I added the VNC_PW key, but this docker is going to reset the OS/OBS settings on a rebuild. Is that going to happen with every update as well?

     

    Anyone have any suggestions there? I know you can backup OBS settings. Aside from manually saving off directories, is there an easier way? Should we incorporate Syncthing into the OS, or something so we can "backup" these settings?

     

     

  2. Had to delete and reinstall to get it working.

     

    Where's the option to change the vnc password in the setup?


    I'm unable to access the VNC from a 3rd party client? I'm using TightVNC Viewer just "closes gracefully" when I make the attempt.

     

    Couple other things. Might want to consider putting an OBS shortcut on the desktop. You may also want to update the info in the thread's first post.

     

    Thanks for your time/effort. Nice to finally be able to use this.

     

  3. WebUI didn't work for me on last version, and it seemed like other comments said "wait for an update". After updating to the latest, I see this:

     

    Quote

    Warning: could not find self.pem
    Using local websockify at /opt/noVNC/utils/websockify/run
    Starting webserver and WebSockets proxy on port 5901
    Failed to start WebSockets proxy

     

    Any help would be great. Let me know if I can provide more info. Thanks.

  4. Thanks for the help you two. I'm up and running. However, something is causing the system to freeze up/stall after about eight hours. So I'm off on my next troubleshooting adventure.

     

    Found a "Starting Over" list in the wiki, but hoping not to have to go that far. Half the "fun" is putting out these fires on one's own. If I don't get anywhere, I'll start a new topic.

     

     

    Thanks again!

  5. Okay, looks like crisis averted, lesson learned. Copied over new flash drive with CA backup (renamed the super.dat.CA_BACKUP to super.dat) and all appears to be well.

     

    Is there anything else I should be wary of in this process? My flash backup appears to only be two days old. Looks like it wants to do a parity check, but otherwise I'm up and running like normal.

     

    My only concern is with the 12 month USB key replacement. I'd much rather purchase a new flash drive and migrate to there. Does LimeTech budge on the replacement window?

  6. Managed to recover disk assignments txt from old USB. I have the drives selected in the correct order on the Main tab. However, it's saying it will wipe my parity drives even with the "parity is valid" selected?

     

    Afraid to pull the trigger on starting array. At some point I found an unraid FAQ about dual parity saying something about only staring it with one drive at first, but I'm unable to find it now.

  7. Hello,

    My USB failed completely and I don't have my disk assignments. I have relatively recent flash backup, but it's on the array. Somewhere along the way, I understood the data on the disks to be accessible, even if the USB fails. I thought, worst case scenario would be I have to dock each drive separately until I find the data I'm missing.

    This turns out to be not the case, and/or more complicated than I realized.

    I had dual parity and two ssds in a pool, and I'm able to differentiate these drives from the rest. However, not the order of assignment for anything. (Parity 1 vs Parity 2, cache drive 1 vs 2, etc.)

     

    I have my Unraid up and running, and the registration key reassigned. At a loss for what I can do next. Any help would be greatly appreciated. Thanks.

  8. 2 minutes ago, dlandon said:

    Why exFAT on a disk that size?

    I use exFAT for compatibility. I use this drive on Mac, Windows, and Unraid. I'm unaware of a better/easier method without installing/maintaining additional software if there is one.

     

    Did you catch my edit regarding the drive seeming to be fine? I think attempting to read/write from the disk with the partial plugin damaged the filesystem. (Could still easily/purely be a drive issue though.)

  9. Hello,

     

    Had some very bizarre behavior when trying to use Unassigned Devices after the creation of the Plus addon. My 4TB exFAT drive mounted and was usable in Krusader without the addon, but I was having issues. If I'm understanding what the addon does, I'm surprised the drive even mounted in the first place. I'm guessing the "base" plugin updated automatically, and fix common problems hadn't caught it yet to mention the addon?

     

    I was able to browse the exFAT drive in Krusader and start a Move process. However, it would get about 50GB in and freeze up. After a couple cancels and retries, Krusader crashed and I had to just reboot. Then the exFAT disks would no longer mount and I starting digging into UD to reinstall it, then noticed the addon.

     

    I was on 6.5.3, installed the addon, and was still unable to mount. (Very likely due to it not occurring to me to reboot after installing the addon.) Anyway, after misreading the minimum requirements for the addon, I upgraded to 6.8.0. All anecdotal at this point, and those logs are long gone. Just thought I'd mention how this presented for me in case it comes up for anyone else. There's also every chance that I'm just bad at unraid and a complete fringe case... and/or that drive is coincidentally failing.

     

    e.g.

     

    Quote

    Jan 9 00:01:17 Tower kernel: print_req_error: critical medium error, dev sdp, sector 4009728
    Jan 9 00:01:17 Tower kernel: Buffer I/O error on dev sdp1, logical block 500960, async page read
    Jan 9 00:01:20 Tower mount.exfat: failed to read cluster 0x796
    Jan 9 00:01:20 Tower kernel: sd 19:0:0:0: [sdp] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
    Jan 9 00:01:20 Tower kernel: sd 19:0:0:0: [sdp] tag#0 Sense Key : 0x3 [current]
    Jan 9 00:01:20 Tower kernel: sd 19:0:0:0: [sdp] tag#0 ASC=0x11 ASCQ=0x0
    Jan 9 00:01:20 Tower kernel: sd 19:0:0:0: [sdp] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 00 3d 2f 00 00 00 00 08 00 00
    Jan 9 00:01:20 Tower kernel: print_req_error: critical medium error, dev sdp, sector 4009728
    Jan 9 00:01:20 Tower kernel: Buffer I/O error on dev sdp1, logical block 500960, async page read
    Jan 9 00:17:18 Tower nginx: 2020/01/09 00:17:18 [error] 14636#14636: *9410 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.231, server: , request: "POST /plugins/unassigned.devices/UnassignedDevices.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.1.38", referrer: "http://192.168.1.38/Main"

     

    Disk sdp is the before mentioned 4TB drive. Not sure if it's the plugins not liking the format or the drive failing at this point. As the topic isn't lighting up with the issue, I'm guessing I'm fighting two things at once here and the plugins are fine. I'll have to look at the disk more in the morning.

     

    As for the non-disk failure issue... Perhaps, if it's possible and/or worth the effort, consider having the base plugin throw a warning sign for disks that require the addon?

     

    Thanks for your time/effort here and on the plugins.

     

    edit: After looking at and repairing the filesystem on the drive, it appears to be fine. I believe my initial Move process using the partial UD plugin may have borked the file system on the drive during the delete part of the Move. Just guessing, but I thought it was worth mentioning.