garycase Posted June 6, 2015 Share Posted June 6, 2015 before i proceed ... is this safe as i currently do NOT have parity? Whether you have parity or not doesn't matter -- if you do something that inadvertently wipes out files, they'll be wiped out with or without parity !! Before messing with the file system, I'd rename the share, just to see if this is somehow causing the problem. If not, then there are a couple SAFE ways to proceed ... but first see if a simple rename resolves this. Quote Link to comment
SnickySnacks Posted June 6, 2015 Share Posted June 6, 2015 He has split level=1 and is copying to the root of the share. It's likely putting the file onto whatever disk all the other BDs are on, no? (My thinking is the split level affects where the directories are created, not the files, so the root directly is probably all on one disk?) To be honest I have no idea how split levels work when copying files to the root of the share, but that seems to be the most likely culprit. Can you look in the share directory in the unraid menu and check the "Location" column and see if perhaps all the BDs you have copied are only on a single or set of disks that are now full? My logic goes: The average BD is about 30gb, your error screenshot shows 105 items in that share, so ~3TB is about right for 1 disk filled to the brim. Quote Link to comment
garycase Posted June 6, 2015 Share Posted June 6, 2015 That's why I had him test with a small file (just a couple MB) ... and it still failed. Clearly that's NOT the issue. Quote Link to comment
adrian ballard Posted June 7, 2015 Author Share Posted June 7, 2015 renamed the share to 'butter'. tried to copy 40+ GB file to d12\butter and it failed. I'm going to load a fresh 6TB drive (formatted to XFS) and setup a new share. Then I'm going to try a move 5TB of data to it to see what happens. This may take a while so I'll post back with my results as soon as it finishes. Quote Link to comment
garycase Posted June 7, 2015 Share Posted June 7, 2015 It seems that the problem share has somehow been corrupted. I'd move all of the data off that share; then delete it. Make sure that ALL top-level folders with that share name are deleted from every disk that had any data from the share on it; then re-create a new share and copy the data back. Seems likely that will resolve this. Sounds like that may be what you're doing now ... unless you're copying a different set of data to your new share. Quote Link to comment
adrian ballard Posted June 7, 2015 Author Share Posted June 7, 2015 I'm in process of what you describe. Hopefully this will work out..... Quote Link to comment
xamindar Posted June 7, 2015 Share Posted June 7, 2015 What is your directory ownership and permissions of the troublesome directory? Is it [dwrxrwxrwx] 777 and owned by 'nobody' and group 'users' ? I searched the thread but did not see any explicit mention of it, but have you performed a filesystem check on the disks with the troubled shares? And that went over my head.... If you will instruct, I will check.... You never got back on this. It is possible that particular share is just set to read only and write is not allowed. Have you tried running "New Permissions" from the unraid tools tab on that drive? Quote Link to comment
adrian ballard Posted June 8, 2015 Author Share Posted June 8, 2015 Fresh 6TB drive, formatted to XFS, new share built. Wrote 5.75TB to drive in 2 different ways: straight to drive - D13\Omega through the share - Omega Both worked without incident so it looks like the old share had indeed become corrupted. Thanks for all the help... Quote Link to comment
garycase Posted June 8, 2015 Share Posted June 8, 2015 Glad it's all working now. Would be interesting to know just what happened ... but that will just have to remain one of life's little mysteries Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.