February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. About 12 hours after upgrading to B14 (from B13, which was working great for me), I noticed my XBMC boxes could no longer connect to my MariaDB docker container. Tried stopping and restarting MariaDB, tried connecting to MariaDB with HeidiSQL, no luck. Decided to reboot unraid. After reboot, docker reporting no docker containers installed, SSH into unraid, it appears I'm missing one of my docker folders, I believe it's the docker config folder /mnt/cache/docker/apps folder that is completely missing from my btrfs cache drive. I also noticed that my Xen VM is no longer loading, it appears I'm missing the .cfg file from the mnt/cache/domains/Windows folder on the cache drive. Anything I should check before I start rebuilding my containers, and Xen VM etc ? Does the cache drive still need to be formatted btrfs for Docker ? I thought I read somewhere that this was no longer a requirement. Would consider using XFS like my other drives. Appreciate the feedback.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. You also need to check that you do not already have a folder on any of the array disks corresponding to the share name or you can get mover moving files even for 'cache-only' shares.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. Hmm, I just tested a beta12 server and created three shares (cache no, cache yes, and cache only). Wrote some data to each and everything went where it was expected. Did an upgrade to 14 and all my share settings for Use Cache are fine. Next test will be to create the shares on an unRAID 5 build, upgrade to 6.0 beta 14, and see what happens.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. WOOOO im not a special snowflake. Just had this happen a few days ago, moved my Apps share from cache only to cache+disk1, Had to restore all of my sonarr/plex databases since half the data was overwritten on boot since the plugins reinstalled themselves and i got dupes.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. WOOOO im not a special snowflake. Just had this happen a few days ago, moved my Apps share from cache only to cache+disk1, Had to restore all of my sonarr/plex databases since half the data was overwritten on boot since the plugins reinstalled themselves and i got dupes. Folks, we need to see defect reports on this issue with syslog included. I've been desperately trying to recreate this issue every which way I can and I'm coming up empty. I've attempted creating shares on v5 and earlier v6 betas then upgrading to 14 and my "cache only" settings are persisting fine. With beta14, we made it so that even if a folder for the share exists on both the cache and array, if the setting for the share is set to "cache only," the mover should ignore the share and not move the data inside.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. WOOOO im not a special snowflake. Just had this happen a few days ago, moved my Apps share from cache only to cache+disk1, Had to restore all of my sonarr/plex databases since half the data was overwritten on boot since the plugins reinstalled themselves and i got dupes. I deleted some comments yesterday about this issue because i thought it was something i had done, but now i see other people with similar issue. I had a cache only share for docker appdata and the first mover run after updating to b14 i ended up with some of the data on the array. I'll be watching like a hawk when the mover runs again later. I made a new share and moved everything over to it and zapped the original share that was playing up.
February 23, 201511 yr Just wanted to update, it *appears* some of my folders may have been moved somehow, I'm seeing my docker and an xen domain folders on disk 1, I'm 100% positive I didn't put them here, is it possible they were somehow moved during a cache move or something ? Going to dig a bit deeper, this may be easy to fix. You should check that a share has not lost its 'cache-only' setting. It sounds as if this might have happened and the files got moved to the main array by mover. I've had this happen as well, and even when re-enforcing cache-only it's still moved data. I ended up create a .foldername to stop mover from screwing up the docker containers. Hmm, I just tested a beta12 server and created three shares (cache no, cache yes, and cache only). Wrote some data to each and everything went where it was expected. Did an upgrade to 14 and all my share settings for Use Cache are fine. Next test will be to create the shares on an unRAID 5 build, upgrade to 6.0 beta 14, and see what happens. I had built an UnRAID server for a friend that was running b12. His dockers were behaving strange and when I checked the Shares the cache-only share was now cache and data. I moved all the data back to the cache drive, made sure there were no directories on the data disks, then re-set the share to cache only. A few hours later it was the same thing. I did this 3 times before I gave up and created the .directory on the cache drive which fixed it. I still don't know what was going on, but since I managed to get a workaround going I didn't spend any more time trying to figure it out (like I would have if it had been my own server). I just assumed it was a one-off so didn't bother reporting it.
February 23, 201511 yr I may have been seeing something similar as well. My downloads directory is set to cache only. Several times recently i have noticed that the share is showing as Cache, Disk1 Checking Disk 1 manually shows an empty set of folders created matching a folder structure on the downloads folder something like /downloads/complete/movies I do have a top level share called movies. When check the settings for the downloads share this morning, i noticed split was set to "automatically split directories" i have now changed this to "do not split directories" and have manually deleted the directories off Disk 1.
February 23, 201511 yr Moved this thread into the defect report board. We need folks experiencing this issue to post a copy of their syslog after seeing this issue so we can investigate further.
February 23, 201511 yr Syslog is a bit big, but it shows rsync errors trying to move things in my cache only downloads folder https://drive.google.com/file/d/0B7xuNcO5FjjYdl9xVEMzUkU2Rlk/view?usp=sharing
February 23, 201511 yr Syslog is a bit big, but it shows rsync errors trying to move things in my cache only downloads folder https://drive.google.com/file/d/0B7xuNcO5FjjYdl9xVEMzUkU2Rlk/view?usp=sharing Please update to beta14 and report back if this issue persists (your syslog indicates beta13). There is a change in beta14 where the errors shouldn't show up anymore and instead, the mover should indicate that it is skipping shares set to cache-only.
February 23, 201511 yr Folks, we need to see defect reports on this issue with syslog included. I've been desperately trying to recreate this issue every which way I can and I'm coming up empty. I've attempted creating shares on v5 and earlier v6 betas then upgrading to 14 and my "cache only" settings are persisting fine. With beta14, we made it so that even if a folder for the share exists on both the cache and array, if the setting for the share is set to "cache only," the mover should ignore the share and not move the data inside. In previous versions, if a user share was created by putting a top level folder on the cache drive, the mover would not move any files in that share because the top level folder did not exist in /mnt/user0/. So this share was implicitly "cache only". In order to get mover to move that share, you had to create the top level folder on an array disk. In v6beta14, the mover checks the cache settings and moves any share that is not explicitly "cache only". Any share that was implicitly "cache only" in a previous version will be moved.
February 24, 201511 yr I replaced a share that was set cache only and was putting data on the array after the b14 update. It did that after the first mover run after update, no problems now after another mover run. Note :- not suggesting this is a solution, far from it. just reporting no reoccurence of the issue.
February 24, 201511 yr In previous versions, if a user share was created by putting a top level folder on the cache drive, the mover would not move any files in that share because the top level folder did not exist in /mnt/user0/. So this share was implicitly "cache only". In order to get mover to move that share, you had to create the top level folder on an array disk. In v6beta14, the mover checks the cache settings and moves any share that is not explicitly "cache only". Any share that was implicitly "cache only" in a previous version will be moved. Exactly right, and I will add that text to release announcement post. In addition to this: To prevent the mover from moving files off the cache to the array you should make sure "Use cache disk" is set to "Only" in the share's Share Settings page.
February 24, 201511 yr Folks, I am desperately trying to get more data on this issue to ensure this isn't affecting shares that in the webGui have their Use Cache setting set to Only. If a folder/directory was created by command line or just creating a folder under the cache disk/pool directly, that's one thing, but if you have a share that's set to only use the cache in beta14, it should not move that to the array, regardless of the presence of the folder in /mnt/user0. Please post a copy of the syslog and a screenshot showing the share's settings page if you can recreate this issue consistently or have had to resort to a workaround with hidden folders to solve it. Thank you.
March 5, 201511 yr I can confirm that in ß14b, shares that were automatically created by creating folders on the cache drive (not explicitly defining the share) were being moved if the shares were not set to 'Use cache disk: Only'. I was using ß12 and upgraded to ß14a, then to ß14b. I use Midnight Commander via SSH to move the files back, changed the shares to 'Use cache disk: Only', removed the share folders from the non-cache disk, ran mover, and the files stayed on cache as expected. Hope this helps others. twkd
March 5, 201511 yr I can confirm that in ß14b, shares that were automatically created by creating folders on the cache drive (not explicitly defining the share) were being moved if the shares were not set to 'Use cache disk: Only'. I was using ß12 and upgraded to ß14a, then to ß14b. I use Midnight Commander via SSH to move the files back, changed the shares to 'Use cache disk: Only', removed the share folders from the non-cache disk, ran mover, and the files stayed on cache as expected. Hope this helps others. twkd That is expected behavior. The real thing I'm looking for is someone who has a created a cache only share through the webgui where the data is getting moved to the array anyway.
October 17, 20169 yr similar things happened to my server just now. was checking around for mounting a zfs drive outside array unraid 6.2.1 enabled docker, set the required paths to cache only share in cache disc then i guess mover kicked in and moved (empty) cache share to disk2. in smb cache disk folder was not looking right (empty, without my silly test files and cache only share folder) then i gone to web gui disk shares> cache> compute and i saw my cache is inside disk2. after clicking browse revealed there is another cache share in cache share. none of those seemed right so i launched midnight commander deleted cache folder in cache disk and in disk2 everything went back to normal. disabled docker again since i dont use/need it. long story short its docker related and there is no data loss at least to my case
October 17, 20169 yr Did you, perhaps, set some configured path to /mnt/user0 instead of /mnt/user? user0 encompasses only the array drives, while user includes the cache.
October 17, 20169 yr i don't know i picked the paths from drop down menu cant remember much but i dont think so now that i checked it. here is the copy paste of set paths /mnt/cache/cache only/- docker -/docker.img /mnt/user/cache only/- docker -/
October 17, 20169 yr the weird thing was /mnt/cache/cache only was there and there was a new cache /mnt/cache (/mnt/cache/cache) and it was in disk2 lol
October 17, 20169 yr the weird thing was /mnt/cache/cache only was there and there was a new cache /mnt/cache (/mnt/cache/cache) and it was in disk2 lol This suggests that you create a User share called cache, and that caused things to get confused between the user share and the disk share both called cache. I think the GUI should stop a user Share called cache being created (it may already do this), but it will always be possible for users to go 'under-the-covers' and create a folder called 'cache' on a disk and thus as a by-product create a user Share with this name.
October 17, 20169 yr The GUI checks for reserved names when creating user shares and prohibits them. There isn't any protection against users creating folders directly however.
Archived
This topic is now archived and is closed to further replies.