adammerkley

Upgraded from 6.6.2 without issue.

The fact that Amazon and Apple have come out with strong denials, and have even said that they are under no gag order, tells me that Bloomberg's report is wrong. Publicly traded companies can be compelled to not comment. They cannot be compelled to lie.

Ah, thank you. I will plug it into one of my open drive caddies. Edit: Plugged a single drive into one of my caddies and it worked right away. Thanks so much!

Trying to get some data off of my old Unraid server. The hardware no longer boots so I have pulled the drives and plugged them into an external USB enclosure. I've plugged the drives into my current Unraid server, but I'm unable to mount any of them so far in UD. The drives are formatted in ReiserFS. I get these messages in the log when trying to mount: Oct 14 11:12:35 Tower unassigned.devices: Adding disk '/dev/sda1'... Oct 14 11:12:35 Tower unassigned.devices: Mount drive command: /sbin/mount -t reiserfs -o auto,async,noatime,nodiratime '/dev/sda1' '/mnt/disks/old1' Oct 14 11:12:35 Tower kernel: REISERFS (device sda1): found reiserfs format "3.6" with standard journal Oct 14 11:12:35 Tower kernel: REISERFS (device sda1): using ordered data mode Oct 14 11:12:35 Tower kernel: reiserfs: using flush barriers Oct 14 11:12:35 Tower kernel: REISERFS (device sda1): journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 14 11:12:35 Tower kernel: REISERFS (device sda1): checking transaction log (sda1) Oct 14 11:12:35 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 14 11:12:35 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] Oct 14 11:12:35 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 Oct 14 11:12:35 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 00 01 00 cf 00 00 08 00 Oct 14 11:12:35 Tower kernel: print_req_error: critical target error, dev sda, sector 65743 Oct 14 11:12:35 Tower kernel: print_req_error: critical target error, dev sda, sector 65743 Oct 14 11:12:35 Tower kernel: Buffer I/O error on dev sda1, logical block 8210, lost sync page write Oct 14 11:12:35 Tower kernel: REISERFS warning (device sda1): journal-837 _update_journal_header_block: IO error during journal replay Oct 14 11:12:35 Tower kernel: REISERFS warning (device sda1): reiserfs-2006 journal_init: Replay Failure, unable to mount Oct 14 11:12:35 Tower kernel: REISERFS warning (device sda1): sh-2022 reiserfs_fill_super: unable to initialize journal space Oct 14 11:12:35 Tower unassigned.devices: Mount of '/dev/sda1' failed. Error message: mount: /mnt/disks/old1: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error. Oct 14 11:12:35 Tower unassigned.devices: Partition 'ST315003 41AS' could not be mounted...

Can't think of much benefit to doing that. I'm relying on CA Backup for this. But if you do backup using Github and you use DNS verification, you'll want to exclude the file with your DNS provider API key.

Thank for the replies. Got LetsEncrypt DNS verification to work after messing around with various security settings on CloudFlare.

I'm on Cox residential. Is there no way for me to do this since port 80 is blocked? I've tried to go around this by circumventing DuckDNS and registering a domain, and using CloudFlare as my name server, but I still can't figure out how to make DNS Validation work.

Last night I noticed an error in Fix Common Problems, reporting that even though Appdata is set to be Cache Only, some of it's folders exist on Disk4. Sure enough, I looked at the Appdata share and it is indeed set to Cache Only, but there are folders on Disk4. I used the Dolphin docker to copy the data back to /mnt/cache/appdata, worked like a charm. How did this happen though? My Appdata share has always been set to Cache Only.

Bought 2 8TB EasyStores last week. Shucked and found white drives inside. Both register just fine in my Rosewill RSV-L4411 case's backplane.

Interesting. I've never had this issue in 3+ years of this build. How can I mitigate?

Nevermind. I shutdown, then figured out which slots those 2 disks were in. Removed and reseated them, but switch disk 8 with another disk to see if the problem traveled or not. The problem didn't come back.

Disks 8 and 10 both got a single error. I got an alert on my phone about it. Trying to run short or long SMART tests from the disk pages results in nothing. Haven't rebooted yet. Attached diagnostics. Any ideas? tower-diagnostics-20170805-1859.zip

Oh cool. I'm transcoding to RAM already, how are you writing Plex logs to RAM?

Am I crazy or does mapping /transcode to /tmp work again?

CA Appdata Backup is only supposed to backup appdata, right? If you're backing up your entire cache drive then it's going to backup TV, or Movies or whatever temporary shares exist on the cache drive at that point, waiting to be written next time Mover runs. So when you restore using CA Backup it will overwrite everything in the folders it is restoring.