February 21, 20179 yr Hi, I have noticed some weird behaviour.. I have searched the forum for a similar report but I cannot find any: - I have a user share called SERIES (in which live all my tv shows) - Because I needed to move large quantities of data between locations I created a folder called SERIES2 -inside- the user share SERIES (so just a regular folder inside SERIES, just like all the other folders in there). I created this folder on disk1 - When I look at the user share SERIES from my windows machine I do -not- see SERIES2 within SERIES - When I telnet in and check on console I do -not- see SERIES2 within SERIES - When I look at the disk share for disk1 I do see SERIES2 within SERIES - disk1 is globally excluded but that should only have impact on writes, not on reads - I have set the system overnight thinking maybe it would need to "catch up" or something (and knowing that would not be the case) and that did not help tower-diagnostics-20170221-0717.zip Edited February 21, 20179 yr by Helmonder
February 21, 20179 yr It's because permissions are wrong. If you are going to be creating dirs, etc from command line you should use 'user' command to 'su' as the 'nobody' user: user nobody
February 21, 20179 yr Author Thanks a lot, that explains things !Verzonden vanaf mijn iPhone met Tapatalk
February 21, 20179 yr Author 11 hours ago, limetech said: It's because permissions are wrong. If you are going to be creating dirs, etc from command line you should use 'user' command to 'su' as the 'nobody' user: user nobody Thanks for the heads up.. I ran the new permissions tool and also checked out what the current access rights of the Series2 folder are, are they wrong how they are showing now ? The Series2 folder still does not show up..
February 21, 20179 yr Yes, the permissions are now correct. You're just confused by the syntax of the ls command. From within /mnt/disk1/Series you typed "ls -al Series2" which gave you a list of the contents of /mnt/disk1/Series/Series2 . Your next command, from the same place was "ls -al | grep Series2" which gave you a list of the contents of the current directory (i.e. of /mnt/disk1/Series) which you then grepped for the string "Series2" hence it returned the line containing "Series2". From this I deduce that your directory tree is something like this: /mnt/disk1/Series /mnt/disk1/Series/Series2 /mnt/disk1/Series/Series2/Series Edited February 21, 20179 yr by John_M typo
February 21, 20179 yr Author 6 minutes ago, John_M said: Yes, the permissions are now correct. You're just confused by the syntax of the ls command. From within /mnt/disk1/Series you typed "ls -al Series2" which gave you a list of the contents of /mnt/disk1/Series/Series2 . Your next command, from the same place was "ls -al | grep Series2" which gave you a list of the contents of the current directory (i.e. of /mnt/disk1/Series) which you then grepped for the string "Series2" hence it returned the line containing "Series2". From this I deduce that your directory tree is something like this: /mnt/disk1/Series /mnt/disk1/Series/Series2 /mnt/disk1/Series/Series2/Series Fully correct John. Only when I show a directory listing of /mnt/user/Series (or the SMB Series share in windows) then Series2 is not listed.
February 21, 20179 yr What does "ls -la /mnt/disk1/Series" give you? You've already demonstrated that "ls -la /mnt/disk1/Series | grep Series2" does indeed show the presence of a Series2 folder. It's in your screen shot.
February 21, 20179 yr Author 3 minutes ago, John_M said: What does "ls -la /mnt/disk1/Series" give you? You've already demonstrated that "ls -la /mnt/disk1/Series | grep Series2" does indeed show the presence of a Series2 folder. It's in your screen shot. That gives me the contents of the share.. Works fine.. Its whenever I show the contents of the user share that Series2 is not listed.. So if I show /mnt/disk1/Series then "Series2" is shown If I show /mnt/user/Series then "Series2" is not shown. Now since there is nothing wrong with the folder itself the only thing I can think of is that something is going wrong with the unraid part of the system that shows the contents of the individual disk shares as one user share. That very possibly means that if I restart the array stuff will be fine again, but since I cannot find anything in the log showing some kind of error I wanted to make sure to check if you want me to verify something on the system (because this might be a bug). There is absolutely the possibility that I am overlooking something but I have no idea what that could be..
February 21, 20179 yr Ah, yes. I see. Sorry. Maybe you have file system corruption on disk 1? It would be worth running a check.
February 21, 20179 yr Author Its a new precleared disk on xfs.. what check should I do ? Verzonden vanaf mijn iPhone met Tapatalk
February 21, 20179 yr Stop the array and restart in maintenance mode. Click the "Disk 1" next to the green ball to open the page dedicated to disk 1 and do a file system check. That's the only reason I can think of for the folder not showing.
February 21, 20179 yr Author Will do.. I have to finish some copy actions that are running first, I'll get back with the results!
February 21, 20179 yr Author Shutting down the array shows a lot of "failed to remove /mnt/disk..." errors so something is going wrong... I'll see if it gets out of it on its own, otherwise I guess I will need to do a hard shutdown..
February 21, 20179 yr That could be explained by file system corruption too. Can you grab a diagnostics zip before hard shutdown?
February 21, 20179 yr Author The gui was hanging.. I have allready given a reboot command on the console.. Could have grabbed the syslog but forgot... :-( Its rebooting now..
February 21, 20179 yr Start in maintenance mode and run file system checks on all disks - it might not just be disk1 that's affected. Hopefully that will fix it - you'll still have a parity check to do because of the forced shutdown.
February 21, 20179 yr Author Started the array in maintenance mode now. File system check for disk1 is running.. Results: Not available Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 4 - agno = 1 - agno = 6 - agno = 7 - agno = 5 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting.
February 21, 20179 yr Author Now did disk 1 without the -n: Not available Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 4 - agno = 3 - agno = 2 - agno = 6 - agno = 5 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Some of my drives are btrfs, should I remove the readonly option for those checks also ?
February 21, 20179 yr Author My other XFS disk, also without the -n: Not available Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done
February 21, 20179 yr Author disk 11, btrfs: checking extents checking free space cache checking fs roots checking csums checking root refs Checking filesystem on /dev/md11 UUID: c5209701-9c11-4ebd-87c5-7c19b406f57f found 393216 bytes used err is 0 total csum bytes: 0 total tree bytes: 131072 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 124743 file data blocks allocated: 262144 referenced 262144
February 21, 20179 yr I'm not so sure about btrfs. There are lots of ways of messing them up. If I can find some information I'll post a link to it. The wiki isn't very helpful but some recent posts by johnnie.black give good advice. Edited February 21, 20179 yr by John_M added more info
February 21, 20179 yr Author I have let all the checks finish and I can find no errors. I restarted the array in regular mode. Parity sync did not start automatically. The Series2 folder still does not show. I stopped the array and removed the global share exclusions for disk1 and disk 11 just to be sure. The folders now show again. Did I understand these settings incorrectly ? I thought they would only work when you WRITE to the array, it appears they also steer what is shown when viewing a share.. I would have tried this earlier if it was not for the big copy action running that I wanted to finish before bringing down the array..
February 21, 20179 yr Are you saying that this missing Series2 folder only exists on disk1 (and possibly disk11) but not on any of the disks normally included in that share? I don't use exclusions so I don't know whether this is the expected behaviour or not. Does the GUI Help shed any light, or maybe the wiki?
Archived
This topic is now archived and is closed to further replies.