Pancakes

How long are the logs stored? I don't want to submit them now and have you guys go through tons of logs only to find it hasn't done it in the time the logs were there

Reboot twice again and I can safely say this is solved Is it worth editing my title to say "Losing shared on reboot" to help SEO for other people if they have the same problem?

Good deal, thanks! I will probably cut the cache down to 10GB and see what happens. This is for backing up data so performance pretty much doesn't matter at all

I am switching my main storage system to Synology (I really need parity..) however I have a 1TB OneDrive for Business volume mounted on my fileserver VM using CloudDrive CloudDrive has worked perfectly for all 26 days of my trial, and I have not had a single problem. So I have no desire to stop using it, and will be purchasing a licence. However I am only getting my Synology in around 2 weeks time so I want to prepare for how it will work, and if I can keep using it how I want to I currently have an ESXi server which has my FS01 VM. It has a 30GB vDisk and has an LSI HBA passed through to it. When I setup my CloudDrive, I just threw the cache onto one of my drives (Used in DrivePool), however when I get my synology the FS01 VM will no longer have any direct attach storage. It will only have the 30GB vDisk 1. Can I store the cache file on the NAS? 2. Can I store the cache file on my 30GB volume, and tell it to use NO MORE than lets say 2GB of space? 3. How do I "move" the cache file while leaving everything else as is? I have no data pinned, as its purely a backup

Sadly it looks like this is still a problem. I still don't really know if its a Deluge or a Drivepool problem. I can't find a single thread anywhere about Deluge doing the same thing for anyone else I am going to try and change some things in Deluge and see if it fixes the problem

I switched it to the Automatic (Delayed) option and I think it might have solved it, although I have only rebooted twice in total so far

So far so good, Ill wait a little while longer before calling it completely solved on my end, but I think its fixed

I sometimes have a problem where I reboot my server, and it loses all the shares. I suspect this is happening because my fileserver is starting up so fast, its having to wait on DrivePool I found a similar problem unrelated to Drivepool here: https://serverfault.com/questions/752895/windows-2008-r2-shares-disappear-on-reboot It looks like the fix was to make the LanmanServer service dependant on the (In this case) Drobo service using this commant: sc config LanmanServer depend= SamSS/Srv/DDServer If I want to do this for DrivePool, what is the correct service I would add? And does anyone see any problems with doing this?

I have played with other software that claims to do the same thing, but they all worked terribly. The only concern I have is Ransomware, is there any added protection I can configure for CloudDrive? Backing up with Syncovery means the data is completely shielded from Ransomware, but with CloudDrive, could it just wipe out all my backups on CloudDrive?

Honestly I am not all that happy with Deluge anyway, and all my other systems are Debian based so its kind of annoying I set it up on CentOS all those years ago Tomorrow I will install the latest DrivePool version and see what happens, if its still acting funny then I will just rebuild my torrenting setup

I just tried out CloudDrive for mouting my OneDrive For Business storage as a drive letter, so Syncovery can back-up to it. Holy smokes it works great It literally just works. With Syncovery connecting to OneDrive For Business I was having problem after problem, so I just deleted all the data and went with Cloud Drive, now its working perfectly

Thanks for the suggestions, you were kind of correct On the CentOS VM, I have \\FS01\Data\Downloads\ mapped via SMB/CIFS Torrents download directly to \\FS01\Data\Downloads\Incomplete, and then when they are done, they are moved to \\FS01\Data\Downloads. So the files reside on the pool all the time Once they are there, I rename them and move them. But I guess CentOS is still holding onto the original file, even though i successfully renamed and moved the file. I even gave the Deluge account explicit DENY NTFS permissions on the media share, so its weird how its still holding onto the file that it thinks is still in downloads Ill install the latest and see how it goes, I am on 734 so I am a few behind. I may look into downloading to a different volume all together, that might make more sense

For a while now I have had issues where files will not duplicate properly after downloading and moving them, It doesn't happen all the time, and I have been busy so I never bothered looking into it Today I noticed that a TV show would not duplicate So I checked to see if anything had it open, and it didn't. HOWEVER my "deluge" account which is used by Deluge running on a CentOS 7 VM had the original download file open, which no longer existed. I thought this was weird, because how can you have a file open which doesn't exist? So I closed the file, and then the file in /Data/Media/TV Shows/wherver duplicated fine Is this a DrivePool issue, or a Windows SMB issue, or a CentOS/Deluge issue? Related to this, sometimes I have a problem where I will download a file, move it and find that the file is now also back in the downloads folder, because Deluge is still hanging onto it. Closing the session/open file makes the file disappear When I add a torrent, the file will start downloading to \\FS01\Data\Downloads\Incomplete, and when done it will move to \\FS01\Data\Downloads. From there I will remove the torrent from Deluge, and move it to \\FS01\Data\Media\ and then a subfolder All of these folder are on the same pool. \\FS01\Data\Downloads is NOT duplicated, the rest of pool is Does anyone have any suggestions on how I should resolve this?

Nope I am using NTFS, I have StableBit Scanner installed, and the drives all show as good I did have two drives show as having filesystem damage around a month ago, but I followed some advice on here and moved to a later BETA of scanner which fixed the issue, one still showed as having filesystem damage, but a quick checkdisk fixed it I am 100% that duplication was set to X1 vs X2 which it should have been If its helps, the folder used to be a root folder with X2, and then got moved inside a child folder which also had X2 (Probably a year ogo) but I never had any problems When I went in to check after noticing the problem, it was on blue with X1, so I set it to X2, but its still blue. It used to be Green with X2

Nope I'm on WS2016 Standard running BETA 2.2.0.734 Should I still give that BETA a shot? Thanks!