Error creating (mirror) file

Can anyone tell me what could cause the sort of failures listed below?

I have my mirror setup on a locally attached SNAP server and have update configured with no login name and password, but under Advanced, I have connect to update server as setup with the userid and password of an account configured as one of the SNAP administrators. This seems to work about half the time, but fails the other half with this error 65. How should mirror update be configured in this scenario? The meaning of the various mirror update configuration options is not entirely clear to me.

Bob

Time Module Event User
5/23/2005 22:20:43 PM Mirror Error creating file.
5/23/2005 22:20:43 PM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/23/2005 22:20:38 PM Kernel The virus signature database has been successfully updated to version 1.1106 (20050523).
5/22/2005 18:37:41 PM Mirror Error creating file.
5/22/2005 18:37:41 PM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/22/2005 18:37:36 PM Kernel The virus signature database has been successfully updated to version 1.1105 (20050522).

 

Bob - I've been running the admin/mirror version of NOD32 for some time now, and was never able to get the "connect to a share" update version to work consistently, so I've been using the http: update method exclusively since 'way back. Do you have your admin version of the software on a machine that can be used to feed your users? If so, then you can still store your files on your SNAP server, just have the other machine (admin machine) serve the http: files to the users for updating. Let me know if you need specifics.

Jack

 

try to put your mirror in a local folder, not on network drive.
As I remember, and just try, you can only use a local drive to create your mirror.

Regards

 

If you intend to create mirror on a network disk, be sure to use a correct user name and password for authenticating to the share.

 

UOTE=Marcos]If you intend to create mirror on a network disk, be sure to use a correct user name and password for authenticating to the share.[/QUOTE]

Thanks too Marcos, I tried again, but now I changed the account settings I use.
Maybe the default setting could be 'Current user' instead of 'System account' I don't know if a lot of people can use the system account to have access to a shared folder ?

I hope this will help bcronin too ...

 

It's ok to leave the selection to System account. However, in this case you need to set the username in the main update panel to domain(workgroup)/username and the appropriate password to authenticate to the share you want to save the mirror files to.

 

And don't forget to write your domain/workgroup with your username ( ie: 'domain\username' ) if needed ...

 

The SNAP is the only box that is guaranteed to be on 24x7x365, so I would prefer to serve the files from there.

Bob

 

Thats the problem. It IS the correct userid and password ... It works some of the time. I suspect the times it does not are those times when Nod32 tries to kick off the update "too soon" after the box running the admin version of Nod wakes up from sleep mode. You may recall I had issues with this during the beta.

Can you tell me exactly what the error code means?

I suspect the underlying issue here is that for a brief period after waking up, DNS queries seem to fail and then spontaneously start working again. I am betting that error code says the UNC name \\snap\eset can't be resolved. Am I correct?

It would be nice if there were a way to get Nod to wait a wee bit longer after wakeup before trying to do the update.

 

Thanks too Marcos, I tried again, but now I changed the account settings I use.
Maybe the default setting could be 'Current user' instead of 'System account' I don't know if a lot of people can use the system account to have access to a shared folder ?

I hope this will help bcronin too ... [/QUOTE]
I configure a specific userid and password under "Connect to update server as" (that you get to by hitting the "Advanced" button in the Mirror Update configuration dialog. The userid/password is of a user that is a member of the Admin group on the Snap. I have left the "Login name" and "Password" fields under "Access to update files" blank (as I have found that they don't seem to work). However it is by no means 100% clear what the difference is between the userid/password requested there and the userid/password requested under the Advanced tab.

Bob

 

I have to agree with Jack, I use the http setup. Never gives me any problems. I would advise to use it.

Another reason I don't like to use shares that viruses tend to love shared drives to spread itself.

 

The Snap is the only box guaranteed to be on 24x7x365, so http does not work for me. I'd be happy to assist Eset in debuggging whatever problems their share-support has, but I absolutely need it to work and the fact this support was offered was instrumental in my purchasing decision (so I need and expect it to work all the time, or else I have to start looking for a different solution).

Bob

 

Do you have your mirror configured as shown below?

 

Did you ever successfully update the mirror ?
In this exemple, the mirror was not updated, only the virus database or your local Nod32. Have you a log showing a successfull update of the mirror or not ?

 

Maybe I'm missing something but, all the http does is give it access to the update files on the server you want it to.

For example: http://snap:8081

 

I don't have a domain. Just a peer-to-peer workgroup. Where you show the login name and password, I have blanks. Then, under the Advanced dialog, I have the userid and password of the Snap administrator under "Connect to update server as specified user". That works most of the time. I attached the log below. The top entry shows it working. The rc 1312 entries in there are from when I tried configuring mirror update the same way you did (although instead of \\domain\username, I just had "username", since the server in question is the Snap box and not a domain controller per se). Does that make any sense?

Bob

Time Module Event User
5/24/2005 18:03:30 PM Mirror Mirror has been updated successfully.
5/24/2005 18:02:49 PM Mirror Error accessing the update folder. BCRONIN\Bob
5/24/2005 18:02:49 PM Mirror Function MapNetworkDrive, parameters:\\Snap\Eset, ADMINISTRATOR, Return code: 1312 BCRONIN\Bob
5/24/2005 18:01:35 PM Mirror Error accessing the update folder. BCRONIN\Bob
5/24/2005 18:01:35 PM Mirror Function MapNetworkDrive, parameters:\\Snap\Eset, Administrator, Return code: 1312 BCRONIN\Bob
5/24/2005 17:40:06 PM Mirror Error creating file.
5/24/2005 17:40:06 PM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/24/2005 17:40:03 PM Kernel The virus signature database has been successfully updated to version 1.1107 (20050524).
5/23/2005 22:20:43 PM Mirror Error creating file.
5/23/2005 22:20:43 PM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/23/2005 22:20:38 PM Kernel The virus signature database has been successfully updated to version 1.1106 (20050523).
5/22/2005 18:37:41 PM Mirror Error creating file.
5/22/2005 18:37:41 PM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/22/2005 18:37:36 PM Kernel The virus signature database has been successfully updated to version 1.1105 (20050522).

 

No you're probably not missing anything, I'm just not following ... Could you give me a complete example of such a configuration? What gets filled in in each of the mirror update configuration fields?

Sorry for being so slow ...

Bob

 

No Need to appologize, just trying to understand why you wouldn't use the http version. Also if you are using a workgroup you have to make sure that the user has rights to that share.

Here's a pic of the config:
http://www.iuploads.com/free_image_hosting/images/silvas2004/mirror.jpg

Then on the workstations, in the update settings you put your server name.
Mine would be http://test:8081. That way you don't have to worry about rights to the shared folder. Then in the user name you can create one like test user name and password test for example.

 

Ok, I got the http stuff working, but I still have the problem with the mirror update failing. Here's the log:

Time Module Event User
5/26/2005 10:30:28 AM Mirror Mirror has been updated successfully.
5/26/2005 5:55:19 AM Mirror Error creating file.
5/26/2005 5:55:19 AM Mirror Function CreateFile, parameters:\\Snap\Eset\nod%04X.nup, Return code: 65
5/26/2005 5:55:15 AM Kernel The virus signature database has been successfully updated to version 1.1108 (20050525).


Note that the admin PC woke up from suspend at 5:55:00 AM (as it does every morning). So, this activity took place less than 20 seconds after that and it failed. The successfuly run at 10:30 AM was the result of me manually initiating an update. In my experience, these failures only occur when the attempt takes place within 30 seconds or so of a resume-from-sleep (that is, if I had been awake and at the PC at 5:55 AM and had manually initiated the update 10 or 20 seconds later than it got kicked off automatically, it would have worked). So I think this is more of a timing issue caused by the network not being fully awake until 30 seconds or so after the resume. I think it is possibly a DNS issue, but am not sure. Does anyone know what that return code 65 really means?

Is there any way I can get NOD to wait a bit longer before deciding to do the update? Ideally I'd like some way to get it to wait 30 seconds or so after it has decided the time for the update has come before it actually tries to do it. Or else, perhaps it could react to the rc 65 by waiting 30 seconds and retrying (once). Or something ...

Bob

 

Hello Bob,

Referring to the Windows errors returned by the GetLastError() function, error 65 mean ERROR_NETWORK_ACCESS_DENIED.
As far as I know, Nod32 returns the GetLastError() errors.

Regards

 

Yeesh, good old MS. So, now, I wonder why I'd get that error but only for 30 seconds or so after a resume-from-sleep. Sigh.

 

I guess it is because your computer need a little time to be reactivated, load all parameters, aspecially network parameters.
When you put a new computer in a network, it is not immediately seen by others, and don't have access to others even if it gots the good rights, good accounts. I tell you about my little experiencies about this

Do you have a special task in Nod32 to update as soon as it wake up, or it is the standard update task ?

 

It is the standard update task. Runs every hour. Is set to run ASAP if could not be run at the scheduled time (although I still get the failures if I change that to wait until the next scheduled instant). The PC in question has usually been sleeping since late the previous day (10PM to 11PM) and wakes up at 5:55 AM the following morning (as the result of a scheduled task), at which time NOD seems to kick the update process off (since it has been more than an hour since the previous atttempt). I'd just like to try to find a way to get it to wait a bit longer before kicking it off after it has discovered the time for the update task has arrived. I think that would solve the issue. Or else, I've got to find out why the network is not fully ready for use until 30 seconds or so after resume and solve that somehow ...

Bob

 

I find that sleep mode causes more problems then good. We do not use here at my work, because sometimes computers wouldn't come out of sleep mode.

 

I have no issues with sleep mode (other than this). Works great.