trurl

Moderators
  • Posts

    43850
  • Joined

  • Last visited

  • Days Won

    137

Everything posted by trurl

  1. You don't specify what "that" refers to. The text you quoted discusses 4 different shares. Also, your screenshots are very difficult to work with since the don't show any labels.
  2. Still seeing the same in these except FCP hadn't done its scan yet. Check Filesystem on disk1. Post the output.
  3. Looks like you have an FSCK file on flash. That file happens when a file is corrupt. Whatever can be guessed about its contents gets put into FSCK. Was that file also on your backup? Reboot and see if syslog works. If not, maybe something important got corrupted on flash. Your config folder from your backup is all you need to get your configuration on a new install. Maybe you already know since you changed flash drives.
  4. Do you have a current flash backup?
  5. Possibly since it couldn't become disabled, it became corrupted instead.
  6. Already included in diagnostics. Mar 21 15:12:32 Tower kernel: sd 1:0:6:0: [sdg] tag#545 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s Mar 21 15:12:32 Tower kernel: sd 1:0:6:0: [sdg] tag#545 Sense Key : 0xb [current] Mar 21 15:12:32 Tower kernel: sd 1:0:6:0: [sdg] tag#545 ASC=0x0 ASCQ=0x0 Mar 21 15:12:32 Tower kernel: sd 1:0:6:0: [sdg] tag#545 CDB: opcode=0x2a 2a 08 3a 38 37 30 00 00 08 00 Mar 21 15:12:32 Tower kernel: I/O error, dev sdg, sector 976762672 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 2 Mar 21 15:12:32 Tower kernel: md: disk1 write error, sector=976762608 Mar 21 15:12:32 Tower kernel: XFS (md1p1): log I/O error -5 Mar 21 15:12:32 Tower kernel: XFS (md1p1): Filesystem has been shut down due to log error (0x2). Mar 21 15:12:32 Tower kernel: XFS (md1p1): Please unmount the filesystem and rectify the problem(s). This would have disabled disk1 if you had parity. Possibly it is unmountable now. Mar 21 15:24:37 Tower root: Fix Common Problems: Error: disk1 (ST1000LM010-9YH146_Z1008ZGE) has read errors ** Ignored Mar 21 15:24:46 Tower root: Failed to write /mnt/disk1/33297349.tmp Mar 21 15:24:46 Tower root: Fix Common Problems: Error: Unable to write to disk1 Seems it is at least readonly. Why would you set FCP to ignore read errors??? Reboot and post new diagnostics.
  7. Most recent diagnostics shows those OK.
  8. If you want to restrict a share so it only goes to a few disks, Include is the right idea. If you want to restrict a share so it doesn't go to a few disks, Exclude is the right idea. Never use Include and Exclude together. Looks like you tried to include a lot of disks you no longer have. Better to Include All instead of specific disks that might not exist.
  9. Is that why you are using docker folder instead of docker.img? You shouldn't need to access anything within docker.img. Try recreating (as 20G image, not folder) and reinstalling https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file But before that, your domains and system shares have files on the array. Ideally, appdata, domains, and system shares would have all files on fast pool such as cache, with nothing on the array, so Dockers/VMs will perform better, and so array disks can spin down since these files are always open. Nothing can move or delete open files, so you will have to disable Docker and VM Manager in Settings before you can work with these. Since you have Dynamix File Manager plugin might be simpler to clean this up yourself instead of trying to reconfigure so Mover will take care of it, and Mover won't replace files anyway so if there are duplicates you will have to decide which to keep.
  10. Attach Diagnostics to your NEXT post in this thread.
  11. Do you have any client computer with a mapped drive to that share?
  12. Reboot, Uninstall My Servers plugin, post diagnostics
  13. I've changed all my hardware more than once, it just recognized my assigned disks and kept going as usual. The reason I mentioned RAID controllers is because they can cause it to not recognize your assigned disks.
  14. Technically, where there is single parity and single data, then they are mirrors just because that's how the calculation works out. And it allows for simpler parity updates that are faster than the usual method. But I don't know why it would ask that question, since the answer is implied by the disk assignments.
  15. You can access the current documentation from links at the top and bottom of the forum, or from the "manual" link in lower right corner of your Unraid webUI.
  16. M--------a shareUseCache="yes" # Share exists on cache, disk1 What is the purpose of this share? Does it have seeding torrents?
  17. That is where they should be if you are doing it right. So nothing to do with the parity swap procedure really. You should disable Docker and VM Manager in Settings until you get cache back in. And post diagnostics before you enable them again. They probably got created on the array and you will need to clean that up first.
  18. I merged your threads since they seemed to be about the same problem but the posts had additional information.
  19. If you are not using a trial key, make sure your basic key is the only .key file in the config folder.
  20. Start reading here https://docs.unraid.net/unraid-os/manual/storage-management/#selecting-a-file-system-type