It does sync the snapins fine. Also reset owner and permissions on /images folder. This is the result of switching OS’s on the storage node as Ubuntu 14 was seeing issues on the latest SVN upgrades. I am testing Debian 8.1 prior to reloading the main server.

FTP settings seem to be ok even tried removing fog and the fog user and reinstalling from scratch on the storage node.

Fog replicator service seems to launch on the storage node and then immediately exit with a code 0 without adding anything to the replicator log.

Master node is ubuntu 14.04 storage node is debian 8.1 both running svn 3728 everything appears ok i can see the disk info for the storage node but the images do not appear to be syncing.

Two quick questions I have setup my storage node server with a fresh install of Debian 8.1 and wanted to know if I can install the appropriate SVN version directly or do I need to install 1.2 first. Second question if I during the install select FOG server instead of Storage Node will it still function as a storage node if I address it from the main server. I want to do this so I am ready for a quick switch over later as I will reload the OS on my main server soon.

Untold bug fixes, greater speed on upload and download, additional features. It is well worth it in my opinion.

it unzips in the windows temp folder

You could run a script task as a snapin drop the pc’s from the domain and then just change your AD settings in fog so they rejoin the new one.

Someone also mentioned to allocate at least 4 cores to it or performance suffers.

svn 3728 fixed this for me.

I am also seeing this on SVN 3713

In SVN they will add them selves automatically to an approval list under the wireless mac. When you approve the pending macs they will run tasks as normal under the fog client. This is for name change, add to AD, and snapins tasks; tasks that require pxe boot will not run wirelessly.

Is this fixed in 3565?

Be aware there was a batch of the nanostation’s that are known to corrupt packets try monitoring the traffic while transferring some data to test it.

I suspect you are running some sort of traffic management device and the reason your desktop can wake on lan across vlans is that it is authenticated to the traffic shaper and the linux server is not.

If the error occurs after you image the machine I really suspect you are having an issue with the hard drive partition table. When I ran into a similar issue we ran the windows repair on the newly imaged pc and then uploaded the fixed image which seemed to solve future issues from then on.

You may need to update to SVN latest version there is 4.0.5.

I second that emotion you guys are awesome.

That would be perfect.