nerv

Members
  • Posts

    48
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

nerv's Achievements

Rookie

Rookie (2/14)

1

Reputation

  1. Thanks, I think I made the mistake before as well. Obvious in hindsight... I disabled the disk and set it to reiser and everything looked fine, so I'm rebuilding the new disk as reiser now.
  2. Hey folks, I had a disk failing SMART checks with reallocated sectors going up steadily so I replaced it. It was an old 2TB drive formatted with reiser, and I replaced it with a 4TB and chose xfs. The array appeared to rebuild fine, but has the "Unmountable: No file system" issue, which the other disk didn't have when I removed it. xfs_repair spins for a long time looking for the secondary superblock (output below). What's the best way to proceed here? There's data on the disk I'd like and I have 2 parity disks. I'm worried if I do something dumb here it will clear the disk and parity will happily accept that erasing my data. I'm not sure if there's a way to get the old disk to be emulated at this point, because I unassigned the disk and started the array and it still shows as unmountable. thanks! xfs_repair -v /dev/md3 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .......................................................................................................................................................................................................................................................................................................
  3. for those stumbling upon this, I think I figured out a way to work around it. I created a separate SMB share that only had 1 hard link each in it and it solved the issue. Basically I have SMB share1 structured share1/folder1 and share1/folder2 where folder1 and folder2 have hard links to the same file. I created a share2 that directly mounts folder1. share1 still can't access all the hard linked files in folder1 and folder2, but share1 works fine, and this is good enough for my use.
  4. I don't know enough about the plugin to know if it's possibly a plugin issue, or an underlying issue with the unraid filesystem that the plugin is using. Any thoughts? If it's the latter I can try and follow up more with generic unraid help (long shot), but at least something to try.
  5. No. Here are the two hard links (move title replaced). Movie.2020.REPACK.1080p.WEB.h264-WATCHER.mkv Movie (2020) WEBDL-1080p Proper.mkv
  6. Nothing special, just movie titles. So things like (, numbers etc, but nothing crazy. e.g. "Movie X (2007) BluRay.mkv"
  7. Copying from above. Basically unraid can only access one of the two hard linked files, and fails the other. I guess it's not necessarily a permission issue, it just presents that way in Plex. Are hard linked files expected to work when they exist in a mounted SMB? I'm getting "head: cannot open 'file' for reading: Invalid argument" on one of the hard links, but not the other.
  8. Yes. Remote mounted Freenas share via SMB. Works fine in MacOS finder, but I have the permission issues described above in unraid.
  9. I think this may be related to the unassigned devices plugin and how it mounts SMB. I'm reaching out on the plugin support thread.
  10. Are hard linked files expected to work when they exist in a mounted SMB? I'm getting "head: cannot open 'file' for reading: Invalid argument" on one of the hard links, but not the other.
  11. Fair enough. A bit more data here. Unraid can actually access one of the two hard links. I also verified that connecting to Freenas's SMB via MacOS can access both hard links, so this seems like an issue in unraid's ability to access hard linked files over SMB?
  12. I don't follow. As far as I can tell both of the hard links are the same as stat returns the same data on each. Can you give some more background?
  13. I'm not sure. I figured out how to make freenas format the same was as unraid. Included below. My only theory is this has to do with the hard links. The flow this happens in is sonarr creates a hard link of the file after the download completes. Most of the time that works fine, but 10% or so of the time unraid loses access. stat -x file1.mkv File: "file1.mkv" Size: 11130060980 FileType: Regular File Mode: (0644/-rw-r--r--) Uid: ( 1001/ unraid) Gid: ( 0/ wheel) Device: 103,3780247684 Inode: 6621 Links: 2 Access: Sun Jul 19 06:26:36 2020 Modify: Sun Jul 19 06:22:54 2020 Change: Sun Jul 19 06:22:54 2020 stat -x file2.mkv File: "file2.mkv" Size: 4690439998 FileType: Regular File Mode: (0644/-rw-r--r--) Uid: ( 1001/ unraid) Gid: ( 0/ wheel) Device: 103,3780247684 Inode: 4057 Links: 1 Access: Sun Jul 19 06:21:08 2020 Modify: Mon Apr 20 10:28:15 2020 Change: Mon Apr 20 10:28:15 2020
  14. Whoops sorry, fixed. It can access file2, but not file1.