- This topic is empty.
October 29, 2009 at 11:31 pm #29921MalcolmParticipant
I couldn’t find any reference to this issue searching the forums so I think it’s not reported but also unsure if it’s a bug or just a setup weirdness that I don’t know about…
I am running Cerberus FTP latest release version 3.0.8 on a Win2003 Server VM guest (VMware 1; the host OS is also Win2003 Server) alongside several other similar VMs on this host and other hosts, all guests and hosts Cerberus is connecting to are either Win2003Svr or Win2kAdvSvr. I do connect from the guest level back down to the host level in some cases. I have several Group accounts set up so that any users added will inherit folder mappings and permissions without having to do this individually. When a server reboot happens (with monotonous regularity due to Windows update restarts) Cerberus FTP user accounts lose all folders that are network mappings – any folder on the local machine appears to be fine.
This seems to happen (though I haven’t confirmed with certainty) due to the sequence of servers coming back up – if the Cerberus server comes up before the mapped servers are fully up then Cerberus FTP can’t find the mappings later. (And unfortunately it seems this server VM is a bit quicker than the others, never thought I’d complain about a computer being too fast! Shifting the Cerberus FTP to a different server is not really an option at this point.) If I reboot the Cerberus server afterwards, all mapped folders magically reappear.
If anyone has a fix, work-around or other suggestion I’d be most grateful.
ThanksOctober 30, 2009 at 1:26 am #35406imported_SerinParticipant
I haven’t heard of this problem before but one option might be to introduce a delay when starting up the the VM hosting Cerberus. I know this is easy to do with ESXi. I’m not sure about other VMWare flavors.
Does this only happen when a client actually tries to connect to a mapped account before the servers come up? Put another way, if Cerberus starts up first and no client tries to connect before the other servers are up, then does everything work fine when a user tries to connect?October 30, 2009 at 2:46 am #35407MalcolmParticipant
Thanks for the quick reply. I had thought of a delay to the boot but haven’t yet looked into how to do this – I may upgrade to VMware 2.x first since it’s management seems better.
On your question, the answer is a partial no as I haven’t tried connecting a client before the other servers are fully up. I’ve only noticed this occurring relatively recently, on 3 separate occasions, simply because I was only told about it by a colleague about 3 weeks ago. On each occasion, I’ve connected a client (Filezilla Client 18.104.22.168) only after both CFTP and all of the other servers were fully up. On the last occasion I checked in Windows Explorer on the CFTP server and the mappings from the server VM itself were present but CFTP apparently couldn’t see them (they were actually present but appeared grayed out in the Groups and User’s listings in CFTP and were not visible to the Filezilla Client – only the root and the C: folder, tried multiple login/logouts from the client and refreshes also but same deal; Admin login was used). I was after I rebooted that time (it was when I updated CFTP to 3.0.8 and I think it was this required a restart) that I noted that the mappings came back – I haven’t yet replicated this but will try to do so this evening (my time) since they’re gone again right now
In the meantime I think I’ll set all Windows updates on that host and its guests to manual (a bit of a pain but it should prevent relapses I guess).
I’m running CFTP as a Windows service so maybe an alternative would be to run it as an app using a timer and the command console to invoke CFTP after startup?
It’s otherwise a great product, btw.October 30, 2009 at 8:51 am #35408mdjParticipant
Just a wild suggestion: You could program your own little service app, which is looking at the same network mappings, and doesn’t report “started” to the SCM until the network mappings are available. Then Cerberus should be set to depend on this service, meaning it will not be started up until the little service has ensured the mappings are ready. It is a somewhat “nerdy” solution…. You could also just have the little service take half a minute to start, and there is your delay. (I think Windows allows a service up to 40 seconds to start, before it is killed as a malfunctioning service. Regular progress reporting might even improve on that too.)
Of course the right fix is for Cerberus to allow the mappings to be missing on startup and then just use them, when they are there.
- You must be logged in to reply to this topic.