March 27, 201610 yr For some reason, new files that are copied/moved to shares on my data drives are being placed in the cache drive. The cache drive's size is now being included in the mapped drive I have in Windows; The share's size was reported as 9T before I moved the file, now it's 10T I originally thought it was some weird issue with Sickbeard/sabnzbd, but it just happened when I moved a file manually in Midnight Commander; when I moved a movie file from /mnt/user/apps/utserver/finished to mnt/user/Movies/Sci-fi, 2 new folders are created on the root of the cache drive, Movies/Sci-fi/, and the movie is put there. This was happening with sabnzbd/sickbeard, and I had assumed that somebody made a folder on the cache drive with the same name as a share, but that's not the case. Just a few days ago I moved all the files that were accumulating on the cache drive, all my new TV shows, to their proper location without any problems, (I renamed the root folder and moved the data to the share in Midnight Commander) now there are more shows there again as well as a movie. I've never used the cache drive for anything other than apps and temp data, I haven't messed with anything in ages, none of my shares are set to use the cache drive and each drive has at least 150G free. Aside from the split level, the share are the same It appears that this has been happening for some time with sickbeard, that's automated and I never noticed, but this is the first time it's happened when I moved a file myself. Free space: TV and Movies share info: I have no idea what's going on and would appreciate any help. I don't want to upgrade the server while there's something weird going on. Thanks!!
March 27, 201610 yr I'm having the exact same problem. I replied to your other post as well. The user shares keep getting created on the cache drive somehow. I don't know the solution to this yet but hopefully someone here will be able to help us.
March 27, 201610 yr When a file is "moved" rather than copied, if it thinks it is art of the same file-system then Linux will typically just issue a rename that leaves it on the same physical drive. Since I presume /user/apps is on the cache drive then the move command is probably leaving them there as well. I expect that the only sensible workaround in the scenario you describe is to actually configure the shares concerned to Use Cache=Yes so that mover kicks in and moves the files from the cache drive to the array data drives when mover runs.
March 27, 201610 yr When a file is "moved" rather than copied, if it thinks it is art of the same file-system then Linux will typically just issue a rename that leaves it on the same physical drive. Since I presume /user/apps is on the cache drive then the move command is probably leaving them there as well. I expect that the only sensible workaround in the scenario you describe is to actually configure the shares concerned to Use Cache=Yes so that mover kicks in and moves the files from the cache drive to the array data drives when mover runs. good point. would probably happen if passing /mnt mapped to /mnt and the incomplete folder (cache only) is based upon /mnt If so, pass a separate /downloads. Set everything to download to it, then it'll copy from /downloads to /mnt/user/whatever
March 27, 201610 yr I thank you guys for the help. I've got some things I've got to do over the next couple hours but I'll work on this later this afternoon and see if I can get something figured out.
March 28, 201610 yr Author I'm having the exact same problem. I replied to your other post as well. The user shares keep getting created on the cache drive somehow. I don't know the solution to this yet but hopefully someone here will be able to help us. You know, I looked for my old post, didn't see it. I expect that the only sensible workaround in the scenario you describe is to actually configure the shares concerned to Use Cache=Yes so that mover kicks in and moves the files from the cache drive to the array data drives when mover runs. But I've been running this same server for years, just the way it is, using the same processes and locations for my data and apps. Mover's never been used, the files I need/want moved to the array, I've always moved via Midnight Commander. Regardless of the apps, why would this happen moving a file within Midnight Commander? If I move a file from the cache drive to a share that does not use the cache drive, the file should move to a drive in the array. Period. This is how it's supposed to function and how it's been functioning since I set it up. It's not supposed to expand the share onto a drive it's not supposed to use, create the file structure for the share and then move the file there. To save my files, I had to rename the folder on the cache drive (which caused the files to disappear from the share, then Windows reported the right share size again), then move the data to the share, via Midnight Commander. (Trying to move the files before renaming the folder caused an error and the file was lost.) After that, all the files were in the correct location and none of them were on the cache drive. Now, two shares are using the cache drive for files and neither of them are supposed to. I could see that happening, as an option, if the shares were out of space, but they aren't.
March 29, 201610 yr I don't know if anything changed, but this may work for you: instead of moving from e.g.: /mnt/user/apps/utserver/finished to mnt/user/Movies/Sci-fi move from /mnt/user/apps/utserver/finished to mnt/user0/Movies/Sci-fi user0 does not includ cache share, so it will always be moved to the array.
March 31, 201610 yr Author I don't have a user0 dir. However, when I went to look for that, I poked around more and found that some files that supposed to only be on the cache drive are on some the data drives. I found this looking through he drives via Midnight Commander. I normally just look through the shares, so I never noticed, but it seems this has been going on for a while, but not consistently. Some of the files are new, some are years old and way out of date. (like and old copy of my mysql db) It's like Unraid used that location for a while then just stopped updating it. So it looks like Unraid is basically putting data wherever it feels like it, ignoring any share/disk settings. Awesome. Grrr. There has to be a way to figure out how and why this is happening. I really don't want to upgrade till I get this fixed!
March 31, 201610 yr I don't know how it worked before as this is how it's supposed do work, like itimpi mentioned above, this is why LT created user0, so the mover can work and move the files from cache to the array. One more thing, never move from /mnt/user/folder to /mnt/user0/folder (same folder), some files will appear on both sides and lost if copied onto themselves. Best to way would be to move from /mnt/cache/folder to /mnt/user0/folder.
March 31, 201610 yr Author I don't have a user0 folder. I have /mnt/user/ /mnt/cache/ /mnt/disk1 ... /mnt/disk5/
April 1, 201610 yr Author One more thing, never move from /mnt/user/folder to /mnt/user0/folder (same folder), some files will appear on both sides and lost if copied onto themselves. That sounds like what happened when I experimented and tried to move a file from /mnt/cache/TV Shows/(show) to /mnt/user/TV Shows/(show). I got an error and the file was gone. Any ideas as to why I don't have a user0 folder?
April 1, 201610 yr Post syslog and SMART for cache drive. I suspect a problem with the cache or its filesystem has broken the user shares. See v5 help in my sig.
April 1, 201610 yr Yep, like trurl said there's something wrong with your shares, user0 should always exist when a cache drive is assigned.
April 1, 201610 yr Author Yep, like trurl said there's something wrong with your shares, user0 should always exist when a cache drive is assigned. So how can I fix this?
April 2, 201610 yr Author Just noticed the reboot restored the user0 folder... but I rebooted 3 months ago and never saw that folder come back. Maybe I'm just losing my mind. Let's go with that one.
Archived
This topic is now archived and is closed to further replies.