Error oib already exists in point

Veeam Community discussions and solutions for: Oib already exists in point 'id=...' of Veeam Backup & Replication

rhnb

Enthusiast
Posts: 81
Liked: 2 times
Joined: Jan 27, 2010 2:25 pm
Full Name: Allan Nelson
Contact:

Oib already exists in point ‘id=…’

Case: 5168898

Last night 2 VMs in 2 separate jobs failed with the error….

25/01/2012 00:28:45 :: Unable to truncate transaction logs. Error: KeepSnapshot error: [Freeze job already stopped.]

Subsequent retry’s fail with the error…
25/01/2012 12:09:05 :: Error: Oib already exists in point ‘id=xxxxxx-xxxxx-xxxxx-xxxxx:type=Normal:alg=Increment:creation_time=24/01/2012 19:02:00’

I can back them up without using VSS.

I’ve looked at ‘vssadmin list writers’ and they’re all showing as Stable, no errors on the vm’s in question.
I’ve rebooted one of the servers — still no joy.

Anyone else seen this and know a solution?

Cheeers… allan.


rhnb

Enthusiast
Posts: 81
Liked: 2 times
Joined: Jan 27, 2010 2:25 pm
Full Name: Allan Nelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by rhnb » Jan 26, 2012 2:27 pm

Just in case anyone else has this issue.
The answer from tech support was ‘re-create the job’.

Actually, I didn’t do that in the end as it would have been a real PITA — affecting lots of other VM’s.

So, I moved the offending VM to another folder in vCenter, then ran the job we use to backup that folder. All worked fine.
I could now remove the VM and re-register and put it back where it came from but I’ll leave it where it is for now. I can move some stuff around to even up the job sizes/times. Luckily we use a DataDomain for our repository so retention of deleted VM’s isn’t an issue. We’re seeing >90% de-duplication rate using that.


foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Jan 26, 2012 3:07 pm

Allan, glad to hear you’ve found the resolution. But can you tell how would recreating a job affect the VMs? Did you consider to use backup files mapping to point the new job to the existing backup chain?


rhnb

Enthusiast
Posts: 81
Liked: 2 times
Joined: Jan 27, 2010 2:25 pm
Full Name: Allan Nelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by rhnb » Jan 26, 2012 10:13 pm

Interesting you should ask that foggy. I was wondering that myself, so I’d asked if it’s the ‘job’ that’s affected or the backup ‘files’ of that job. (I wanted to know if I moved that VM back to its original job it would now work or still fail), but I haven’t had a reply yet.
If you can confirm the following, then I’m happy to try it…

Delete the job (lets call it MYJOB) — but leave the VBK files etc.
Create a new job (can I still call it MYJOB? or must it be a new name?) and then map the MYJOB.VBK/VBI files to it?



Vitaliy S.

Product Manager
Posts: 26115
Liked: 2487 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Vitaliy S. » Jan 27, 2012 8:48 am

rhnb wrote:I could now remove the VM and re-register and put it back where it came from but I’ll leave it where it is for now.

I was wondering that myself, so I’d asked if it’s the ‘job’ that’s affected or the backup ‘files’ of that job. (I wanted to know if I moved that VM back to its original job it would now work or still fail), but I haven’t had a reply yet.

Deleting VM from inventory and re-registering it in the VI is similar to job recreation procedure, as this VM gets new ID and is treated as a new one. The corresponding backup job will be successful after that, but a new backup chain will be created for this VM, unless you map this VM into existing backup files.


rhnb

Enthusiast
Posts: 81
Liked: 2 times
Joined: Jan 27, 2010 2:25 pm
Full Name: Allan Nelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by rhnb » Jan 27, 2012 8:58 am

Thanks for all the help with this.
I’m happy to leave the VM in it’s new home (job).
My main concern was that the original job/backups were somehow compromised now and I’d be better off trashing it anyway, but it would seem not.


trichert

Influencer
Posts: 21
Liked: never
Joined: Jun 08, 2011 12:17 pm
Full Name: Todd Richert
Contact:

Error: Oib already exists in point

Post

by trichert » Feb 28, 2012 12:44 pm

[merged]

I know there is another thread on this topic, but it has gotten severely off topic on making Veeam fix this bug in v6.

I’ve been running Veeam for 2 years, from esx 4 to esxi 4.1 to esxi 5. This error has never occured before Veeam v6, now it happens all the time. I got so fed up with it I took the stock answer of rebuild jobs, i deleted ALL my jobs and started them all over, initial full ran fine, on the first reversed incremental poof theres the error on one of my SQL server jobs. This is a problem in the Veeam software, and it needs to be fixed ASAP it is a critical flaw I am not sure why so many in these forums are accepting of answers like «rebuild the job» «remove the vm and readd it to inventory (which all redoes a full backup on that server». Can we get an ETA on what Veeam is doing to resolve this issue internally? Please? Thank you!


foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Error: Oib already exists in point

Post

by foggy » Feb 28, 2012 1:25 pm

Todd, we have several issues reported regarding this error, but our QC could not confirm the issue internally. We still need additional info and if you could open the case and provide full logs for investigation, this would probably help us to localize the possible problem and fix the issue. Thanks.


k00laid

Veeam Vanguard
Posts: 217
Liked: 50 times
Joined: Jan 13, 2011 5:42 pm
Full Name: Jim Jones
Location: Hurricane, WV
Contact:

Re: Oib already exists in point ‘id=…’

Post

by k00laid » Feb 28, 2012 2:34 pm

I’ve been running into this since upgrading to v6 as well. I’ll get a case opened today.

Jim Jones, Sr. Product Infrastructure Architect @iland / @1111systems, Veeam Vanguard


trichert

Influencer
Posts: 21
Liked: never
Joined: Jun 08, 2011 12:17 pm
Full Name: Todd Richert
Contact:

Re: Oib already exists in point ‘id=…’

Post

by trichert » Feb 29, 2012 12:50 pm

We have an open case, and it has been very frustrating. Support treats us like this is a rare us only error and I know that is not the case which is why I brought it to these forums. First call was ‘apply patch 2’, next day same error, ‘oh patch 3 came out last night that will fix it! apply that!’ (obviously shooting completley in the dark, very annoying) apply patch 3 same error. We’ve sent logs, it happens consistently and only since v6.



CCB-IT

Novice
Posts: 4
Liked: never
Joined: Oct 21, 2011 7:16 pm
Full Name: CCB IT
Contact:

Re: Oib already exists in point ‘id=…’

Post

by CCB-IT » Feb 29, 2012 2:09 pm

I am also experiencing this error. I am opening a support case now. My biggest question is what the heck does it mean? And also, did the job actually backup anything on the VM generating the error?


foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Mar 01, 2012 10:11 am

OIB stands for object in backup. After the VM is being backed up, the logs truncation operation fails causing the job to perform a retry and backup this VM again (while it already exists in the backup file). Actually, we’ve managed to reproduce this and it will be addressed in one of the following updates. Thanks.


Ben Milligan

Expert
Posts: 173
Liked: 40 times
Joined: Jan 01, 2006 1:01 am
Contact:

Oib already exists in point ‘id=…’

Post

by Ben Milligan » Mar 01, 2012 1:13 pm

You can workaround this issue for now by expanding the backup set, right-clicking on the problematic vm(s) and deleting from disk (This is also why removal from dynamic org folder did the trick). The next job run will run a full for that particular guest. To avoid this on non SQL/Exchange servers, just disable log truncation as it is not necessary. For SQL/Exchange, we’ll need to ensure VSS is functioning properly for log truncation, if that is how you are leverage Veeam VSS in your restoration planning/process.




foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:


Gostev

SVP, Product Management
Posts: 30153
Liked: 6035 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Gostev » Mar 04, 2012 8:20 pm

Just to update, our support now has the hotfix for one of the OIB issues (there are a few) available. Open a support case to have your issue investigated, and if your issue is the same, you will receive the hotfix. Thanks!


dwoodward

Novice
Posts: 4
Liked: never
Joined: Jan 10, 2012 12:56 pm
Full Name: Don Woodward
Contact:




lobo519

Expert
Posts: 315
Liked: 38 times
Joined: Sep 29, 2010 3:37 pm
Contact:

Re: Oib already exists in point ‘id=…’

Post

by lobo519 » Mar 05, 2012 1:41 pm

Question — This past weekend I got this error on 5 of my VMs. After trying the delete from backup work around I now get this error «3/4/2012 2:06:21 PM :: Error: The remote procedure call failed RPC function call failed. Function name: [DoRpc]. Target machine: [IP or repo].» The first disk seems to process fine but the second fails after processing it for quite some time. with the above error.

Is this related?

Note I was running a new full back in a new repo — normally reverse incremental



averylarry

Expert
Posts: 264
Liked: 30 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: Oib already exists in point ‘id=…’

Post

by averylarry » Mar 05, 2012 7:55 pm

Support case #5177017.

This is the response I just received from tech support:

Hi Ted,
With the error that you are getting:

OIB already exists

You can workaround this issue for now by expanding the backup set, right-clicking on the problematic vm(s) and deleting from disk (This is also why removal from dynamic org folder did the trick). The next job run will run a full for that particular guest. To avoid this on non SQL/Exchange servers, just disable log truncation as it is not necessary. For SQL/Exchange, we’ll need to ensure VSS is functioning properly for log truncation, if that is how you are leverage Veeam VSS in your restoration planning/process.

Thanks,

(the support person’s name)

No warning that the backups will be lost (or acknowledgement that they are already corrupt and lost). No mention of the patch that in theory is available (unless they actually investigated my logs and determined that the patch isn’t relevant).


Cokovic

Expert
Posts: 295
Liked: 59 times
Joined: Sep 06, 2011 8:45 am
Full Name: Haris Cokovic
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Cokovic » Mar 06, 2012 6:57 am

Is it really necessary to delete the backup from disk?

Just asking cause for us it worked to delete the job, recreate it and then map the existing backup. The next run everything was fine again.


foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Mar 06, 2012 9:47 am

There are several OIB issues currently, it is quite possible that some of them do not require deleting backups from disk.



Ben Milligan

Expert
Posts: 173
Liked: 40 times
Joined: Jan 01, 2006 1:01 am
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Ben Milligan » Mar 06, 2012 1:27 pm

All — if you do incur this behavior, I do advise retrying with truncation disabled or set to truncate immediately for this specific error «Oib already exists in point ‘id=…'» following failed log truncation. This is in of course accordance with your SQL/Exchange log truncation recovery policies for your environment in mind. There are instances where this can be recoverable, and deleting from disk is the final, worst case scenario option. Please engage our support directly for assistance with any OIB errors you may have experienced.

Thanks!


Tom Bale

Novice
Posts: 8
Liked: never
Joined: Mar 08, 2011 10:11 am
Full Name: Thomas Bale
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Tom Bale » Mar 07, 2012 9:34 am

Vitality, I have contacted support for the hotfix and even linked to this thread but got this reply:

Hi Tom,
Unfortunately, there is no hotfix for that OIB issue, but the current workaround is:

You can workaround this issue for now by expanding the backup set, right-clicking on the problematic vm(s) and deleting from disk (This is also why removal from dynamic org folder did the trick). The next job run will run a full for that particular guest. To avoid this on non SQL/Exchange servers, just disable log truncation as it is not necessary. For SQL/Exchange, we’ll need to ensure VSS is functioning properly for log truncation, if that is how you are leverage Veeam VSS in your restoration planning/process.

Job Ref#5176842

As someone else says this could be very misguiding to some, suggesting to delete from disk but not mentioning that this will remove previous backups. I am having this problem with an Exchange server and after forcing a full backup I still recieve this error message so I will try to truncate logs at the start of the job but I do not want to disable it entirely. Could this be at all related to the fact that that Exchange backup can take anything up to 20 Hours for us?


Who is online

Users browsing this forum: Bing [Bot] and 80 guests

foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Tom, I’ve looked through your case and it turns out that nobody even asked you to provide full logs for investigation. You’d better do this to find out the exact issue you are experiencing as there are a number of adjacent OIB issues having different workarounds/fixes. Also, I’ve asked support guys to give more descriptive advises regarding this.


averylarry

Expert
Posts: 264
Liked: 30 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: Oib already exists in point ‘id=…’

Post

by averylarry » Mar 07, 2012 7:51 pm

For me, (after a few «are you really sure about this?» emails with tech support), I ended up doing the following:

1) Disabled log truncation in the job.
2) Reboot the server (which is also the proxy server and repository).
3) Ran the job. It worked WOO HOO!
4) Re-enabled the log truncation.
5) Ran the job — it worked and the logs have been truncated.

I have not yet (but likely will soon) attempted to verify that the backup is still valid and that the historical chain is also still valid. (I don’t have enough processing power to test my Exchange server during production hours using surebackup/virtual lab/instant restore).



trichert

Influencer
Posts: 21
Liked: never
Joined: Jun 08, 2011 12:17 pm
Full Name: Todd Richert
Contact:

Re: Oib already exists in point ‘id=…’

Post

by trichert » Mar 12, 2012 12:42 pm

Just set up a new virtual environment in our miami datacenter (seperate from where we currently have this problem) put 2 esxi 5 hosts in it, 20 vm’s, setup backups. Poof within 3 days we have the OIB already exists error on 2 of our jobs. How do we get this fixed ??



foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Mar 12, 2012 12:49 pm

Todd, please open a support case and let our technical team investigate. If your particular issue has the available hotfix, you will get it.


trichert

Influencer
Posts: 21
Liked: never
Joined: Jun 08, 2011 12:17 pm
Full Name: Todd Richert
Contact:

Re: Oib already exists in point ‘id=…’

Post

by trichert » Mar 12, 2012 5:54 pm

Just opened, another, case on this issue..(i can mail you the case # but you should be able to see it on my account) The phone tech knows about the OIB error but nothing about a hotfix, he tried to give me the ‘only fix is to delete the job and start over’ line.

This error does not happen ‘rarely’ for us it is ‘nearly constant’. If i deleted backup jobs every time this happened, I would never have a backup chain, ever. Litteraly this happens between my 2 environments 1-2x/week and eventually goes away but i lose 3-5 days of backups while it works itself out. Please escalate fix for this issue :)


mongie

Expert
Posts: 152
Liked: 24 times
Joined: May 16, 2011 4:00 am
Full Name: Alex Macaronis
Location: Brisbane, Australia
Contact:

Re: Oib already exists in point ‘id=…’

Post

by mongie » Mar 12, 2012 9:29 pm

So, I get this issue as well… some times I am able to just re-run the backup and it starts working again.

I’m wondering though — someone mentioned you can re-map existing backups to a new job. How do you do that? At the moment I’m stuck making a new Full every time, and when your file servers are a 5TB full backup, that hurts.


foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Mar 13, 2012 10:01 am

Backup mapping functionality is described in user guide, p.95 (New Backup Job wizard description, ‘Step 6. Specify Backup Storage Settings’).


htwnrva

Enthusiast
Posts: 32
Liked: never
Joined: Jan 20, 2010 6:59 pm
Full Name: Ronny
Contact:

Re: Oib already exists in point ‘id=…’

Post

by htwnrva » Mar 13, 2012 1:20 pm

Have the same issue in my environment, deleting the offending VM and restarting the job works. But the problem itself needs to be fixed.




ntc09

Novice
Posts: 3
Liked: never
Joined: Apr 14, 2011 2:22 pm
Full Name: Scott Davis
Contact:

Re: Oib already exists in point ‘id=…’

Post

by ntc09 » Apr 04, 2012 7:08 pm

I opened a case and installed the hot fix dll’s. Retreied the job and it was successful however it did not seem to really do anything.
I kicked off the job again and it processed the servers and completed.
Hopefully this will correct the issue.



foggy

Veeam Software
Posts: 20911
Liked: 2063 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Oib already exists in point ‘id=…’

Post

by foggy » Apr 04, 2012 8:58 pm

No, I suppose this was the private hotfix DLL. Please open the case to get it.



jlehman

Novice
Posts: 3
Liked: never
Joined: Aug 26, 2011 8:09 pm
Contact:

Re: Oib already exists in point ‘id=…’

Post

by jlehman » Apr 05, 2012 6:04 pm

Hi.
I did download the fix from the link sent by support and it did fix the problem in that job which is terrific!
Installed it on 6 other backup servers without any side issues as the jobs all ran flawlessly.
Veeam should proactively contact everyone that has submitted a support case and provide the link to the fix.
It will make their day!


Gostev

SVP, Product Management
Posts: 30153
Liked: 6035 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Oib already exists in point ‘id=…’

Post

by Gostev » Apr 05, 2012 6:12 pm

Well, considering there are 3 different issues that may cause similar oib errors, this is not as simple. Our support does need to investigate logs to see which one is it.


mleland

Lurker
Posts: 1
Liked: never
Joined: Jun 01, 2012 8:26 pm
Full Name: Mike Leland
Contact:

Re: Oib already exists in point ‘id=…’

Post

by mleland » Jun 01, 2012 8:32 pm

I just ran into this » OIB already exists» issue while evaluating V6.

I know the cause in my case, as the log from the first attempt to run this job showed a failed attempt to lookup my vSphere Server’s ip address.

For some reason that left the VM with data in the backup set yet I kept getting the «OIB» error.

As this is just an evaluation I did end up deleting the backup data for this one VM and a re-run of the job was successful.

A good question for the QAENG guys would be why this simple error caused a failed backup? I mean it doesn’t look it ever tried to lookup the VS Server address again. It seems there was a maint window on one of the internal DNS servers and the other one was not configured correctly that caused the DNS lookup issue. These issues have been addressed already.

I just wanted to add my experience with this error to the list of possible causes.


AlexLeadingEdge

Expert
Posts: 437
Liked: 56 times
Joined: Dec 14, 2015 9:42 pm
Contact:

Re: Oib already exists in point ‘id=…’

Post

by AlexLeadingEdge » Nov 23, 2017 9:07 pm

Just had the same issue, two Hyper-V Hosts both having the same issue. They both use Veeam Agent 2.0 to backup to a backup server across a network. Stopping the backup attempts and rebooting the backup server seems to have fix this issue for both.

I had this same issue a few months back and I found deleting the backup set also fixes the issue but then we lose the backup history so I had hoped to avoid it this time around.



Who is online

Users browsing this forum: Bing [Bot] and 80 guests

Skip to content

Knowledge Base

  1. Home

  2. Knowledge Base

  3. Windows Agent Backups

  4. Agent Job Errors


  5. Troubleshooting: Job Errors

  1. Home

  2. Knowledge Base

  3. Virtual Machine Backups

  4. VM Job Errors


  5. Troubleshooting: Job Errors

  1. Home

  2. Knowledge Base

  3. Troubleshooting


  4. Troubleshooting: Job Errors

General Troubleshooting: Veeam Backup Job Errors

Below are common host and backup job error messages you may encounter and what they mean.

This article is organized by Alarm Type:

  1. Backup Agent Job State Errors
  2. Job Session State Errors
  3. Job Status Errors
  4. Computer/VM Not Backed Up
  5. Miscellaneous

For Additional Errors Not Listed Below, Consult the Veeam Knowledge Base and/or Forums:

  • Veeam Knowledge Base –  https://www.veeam.com/kb_search_results.html
  • Veeam Community Forums – https://forums.veeam.com/ 

1. Backup Agent Job State Errors

Error: write: An existing connection was forcibly closed by the remote host Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.

What This Means

  • The last backup job was unsuccessful because the remote host (machine backing up) closed the connection to eSilo while the backup was running.

Possible Causes

  • The machine was powered down during the backup. Upon shutdown, the active snapshot taken at the start of the backup is lost.

Troubleshooting Steps

  • No user intervention is typically required.  When the computer is powered back on, a new snapshot will be taken at the next scheduled backup time, and a new backup job will begin.  (Note: If the machine is put to Sleep or Standby during a backup, it should resume when it wakes up. It is only when the machine is completely powered down that this error happens).

Error:  Task failed unexpectedly

What This Means

  • The job was terminated suddenly, resulting in an incomplete backup and restore point.

Possible Causes

  • Host rebooted during the backup, resulting in the loss of the active snapshot.

Troubleshooting Steps

  • Check host’s Event Viewer Windows System logs to see if there was a reboot.
  • Rerun the backup job.

Error:  Root element missing

What This Means

  • The VBM file associated with the backup job has become corrupted.

Possible Causes

  • This may be caused by a connection issue during the backup job or the Veeam repository had an error.

Troubleshooting Steps

  • Locate the VBM file associated with the backup job and rename the file, such as by adding “.old” to end of the file name.
  • Start a new backup job to generate a new VBM file.
  • After the new VBM file gets created, the old file can be safely deleted without waiting for the running job to complete.

Unable to allocate processing resources. Error: Job session with id [STRING] does not exist

What This Means

  • Host requested but was not assigned processing resources by eSilo cloud connect.  This happens because the maximum number of concurrent backup jobs was already reached.

Possible Causes

  • eSilo limits the number of concurrent backup jobs from a single Company when their bandwidth is lower than recommended thresholds.  This max limit ensures hosts queue their backup jobs sequentially (vs. all machines at once) and avoids network slowdowns for the customer.
  • When the first few machines’ backup jobs run long, they can cause subsequent hosts’ jobs to time out while waiting for their turn to backup.

Troubleshooting Steps

  • Hosts should automatically retry backups at their next scheduled interval. No user intervention is typically required.
  • If this is a persistent issue, or if your hosts are connecting from multiple locations (and thus there is little concern that multiple backups may saturate a site’s connection), contact eSilo Support to request the concurrent task limit be increased for your Company.

Failed to start a backup job. Failed to perform the operation. Invalid job configuration: Connection over network is blocked by network throttling rules

What This Means

  • Backup job was unable to complete due to network restrictions.

Possible Causes

  • The host is on a metered connection (ex: hot spot), or on a WiFi connection that has “Set as a metered connection” toggled on in the properties for the currently active WiFi connection.  By default, eSilo Backup Jobs are set to “Disable backups over a metered connection”.
  • Temporary network congestion may also cause this error.
  • Firewall rules that limit or severely restrict certain types of traffic.

Troubleshooting Steps

  • To check if the current WiFi connection is flagged as “metered” by Windows, the user can navigate to the Properties of their WiFi Network, and scroll to “Metered Connection” to verify if this is toggled ON. The preferred setting is to turn this OFF.  Alternatively, if you don’t have remote access to the machine, uncheck the “Disable backups over metered connection” setting in the backup job and rerun it.
  • Wait until the next scheduled backup run to see if the issue persists or was temporary.
  • Contact the network or IT administrator for the site to investigate if there were recent firewall rule changes or upgrades that may have introduced new blocking or throttling settings.

Unable to allocate processing resources. Error: Authentication failed because the remote party has closed the transport stream.

What This Means

  • The backup job failed due to an authentication error between the client machine backing up and the eSilo infrastructure.

Possible Causes

  • Client machine is behind on Windows Updates which include authentication and security enhancements, or they have not checked the box in Windows Update Settings to include updates for other Microsoft Products, such as .NET Framework.

Troubleshooting Steps

  • Apply latest Windows Security updates and .NET Framework updates
  • Check if at the time of the above error on the tenant side, the eSilo Svc.VeeamCloudConnect.log log file displays the following error: “A call to SSPI failed, see inner exception“.  If so, the issue may be related to a Windows Update enforcing a new .Net Framework security check. This check does not allow the client to establish a secure connection between their Veeam backup servers or agents and the eSilo Cloud Connect service, if there is a weak Diffie-Hellman Ephemeral (DHE) key. See this help article from Veeam on the steps needed to confirm and resolve.  https://www.veeam.com/kb3208
  • Subsequent job reattempts may complete successfully without user intervention, although this error may still sporadically cause jobs to fail.

Error: Failed to connect to the port [DNS_Name:Port].

What This Means

  • Host unable to connect to eSilo cloud connect at the specified gateway and port address.

Possible Causes

  • If this issue is occurring for only one or two machines (most common), and not all machines connecting to the eSilo cloud connect infrastructure, it may be indicative of a network issue on the client side.

Troubleshooting Steps

  • The host should reattempt the job at the next scheduled interval.  You can also manually start a backup to reattempt the job.  No other user intervention is typically required.

Error: Insufficient quota to complete the requested service. Asynchronous read operation failed Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: Insufficient quota to complete the requested service. Asynchronous read operation failed Unable to retrieve next block transmission command. Number of already processed blocks: [#]. Failed to download disk ‘[LONG_ID]’.

What This Means

  • The error description may be misleading.  We’ve observed this error previously, and it was unrelated to the Tenant’s Quota, which was well within limits.

Possible Causes

  • When this was observed on an internal testing VM, the cause was that the source VM in the backup job was very low on memory (RAM) resources and was unresponsive.  Restarting the VM brought it back online, and the next automatic job try was successful.

Troubleshooting Steps

  • Verify the source machine is online and responsive. Ensure resource levels look good.
  • Host will reattempt job at the next scheduled interval. No user intervention is typically required.

Error: Invalid backup cache synchronization state.

What This Means

  • Host is currently saving backups to Local Backup Cache.  An attempt to sync cached backups to the eSilo cloud repository failed,  due to a mismatch between what the Veeam Agent for Windows had in its local database for expected restore points and what was actually found in the repository and/or local backup cache.

Possible Causes

  • If an in-progress backup is abruptly stopped, for example due to power failure, Veeam will discard any partially written restore points.  However, if all references to those now discarded restore points are not cleared from the database (which should happen automatically), this can cause a job error on the next run, which highlights a mismatch between restore points expected on disk and what was found.

Troubleshooting Steps

  • In most cases where this has been observed, the job will complete successfully the next time it is run, without any user intervention.
  • If this error persists more than once, contact eSilo Support for assistance troubleshooting Backup Cache issues.

Job session for “[JOB_NAME]” finished with error. Job [JOB_NAME] cannot be started. SessionId: [ID], Timeout: [XX sec]

What This Means

  • The Veeam job could not start due to too many active sessions or jobs running on the host consuming all available memory.

Possible Causes

  • Too many running sessions causes Veeam services to be impacted by the host’s Desktop Heap limitation. This is because the Desktop Heap size for services is much smaller than that for applications.

Troubleshooting Steps

  • To resolve this issue the Desktop Heap size must be increased via a registry modification.
  • See this Veeam Knowledge Base article for detailed resolution steps:  KB1909

Error: The system cannot find the file specified. Failed to open I/O device Failed to open emulated disk. Failed to open disk for read. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}

What This Means

  • An expected disk on the client machine (machine to backup) was unable to be opened and read during the backup job.

Possible Causes

  • Not known at this time.

Troubleshooting Steps

  • The host will reattempt job at the next scheduled interval. No user intervention is typically required.

Error: Oib is complete and cannot be continued

What This Means

  • The “oib” stands for “objects in backup” and is a unique identifier used by Veeam.
  • The error indicates there is a discrepancy; a job is attempting to write to an oib that is already complete or finalized.

Possible Causes

  • This may occur on a backup cache sync job that was interrupted right at very end, during the finalization stage.  The error indicates that the oib was finalized by the previous job (“oib is complete”), however the current job is trying to modify or append to it, which is not allowed.

Troubleshooting Steps

  • This error should resolve itself on next job run.  If not, contact eSilo support.

Job session for “[JOB_NAME]” finished with error. Backup cache size has been exceeded

What This Means

  • The size of the local backup cache has exceeded the maximum allowed size as configured in the backup job, preventing new restore points from being saved to the cache.

Possible Causes

  • Persistent network disruptions may be preventing cached restore points from syncing, or uploading, to the eSilo Backup Cloud and thus they are not rotated out of the local backup cache.  Restore points accumulate until the backup cache location is full.
  • Service provider resources are busy or unable to be allocated to this host, preventing the syncing of cached restore points.

Troubleshooting Steps

  • The Backup Cache Sync should resume in time, once the originating network or resource issues are resolved.
  • The maximum Backup Cache size can be increased in the job settings, so long as there is sufficient local space.
  • For more detail on advanced resolution steps, see this eSilo KB article: How to Resolve Backup Cache Size Exceeded Error

Error: Failed to create snapshot: Backup job failed. Cannot create a shadow copy of the volumes containing writer’s data. A VSS critical writer has failed. Writer name: [NAME]. Class ID: [ID]. Instance ID: [ID]. Writer’s state: [VSS_WS_FAILED_AT_PREPARE_SNAPSHOT]. Error code: [0x800423f0].

What This Means

  • There is an issue with the built-in Windows VSS (Volume Shadow Copy service) on the host machine. Specifically, the VSS writer mentioned was not available at the time of the backup.
  • eSilo Backups powered by Veeam use VSS writers to backup files that may be in-use, open or locked at the time of backup.  This is particularly useful for databases, allowing backups to complete without downtime.  If a writer is not in the proper state and functioning as expected, the backup snapshot will fail.  VSS writer issues must be resolved on the host, and can usually be corrected by restarting the associated service.

Possible Causes

  • The VSS service and/or the VSS Providers service is disabled
  • The VSS writer is not in the Stable state, indicating it is ready and waiting to perform a backup.  Below are alternative states:
    • Failed or Unstable – the Writer encountered a problem, and must be reset .
    • In-Progress or Waiting for Completion – the Writer is currently in use by a backup process. When the backup is finished, the Writer will revert to back to Stable state.  However, if you see this state when no backups are running, the Writer needs to be reset.

Troubleshooting Options

  • Verify the Volume Shadow Copy and Microsoft Software Shadow Copy Provider services are not disabled in services.msc.
  • Check the state of VSS Writers using the following syntax in an admin command prompt.  Also check the Windows Event Viewer for additional error information.
vssadmin list writers​
    • For the specified Writer in the error message, verify it is in a Stable state.  If not, restart the respective Service related to that writer as mentioned in the table here.  Then run the above command a second time to ensure the writer has returned to a stable state.
    • Note that Services often have dependencies on one another.  When one service is reset it may require others to be reset as well.  Restarting a service will momentarily disrupt any application services that rely on it.  For example, while resetting the MEIS service (Microsoft Exchange Information Store), MS Exchange will be unable to send and receive emails.
  • A system reboot can also resolve most VSS writer problems, although it requires downtime.
  • This Veeam KB article can also be useful in troubleshooting VSS issues for servers.

Job Session for [JOB_NAME] finished with error.  Job [JOB_NAME] cannot be started. SessionID: [ID], Timeout: [VALUE]

What This Means:

  • The job could not start, due to timeout waiting for required Veeam resources

Possible Causes:

  • The Concurrent Task limit set at the Company level is too low for the number of hosts and disks schedule to be backup within a defined backup window.

Troubleshooting Options:

  • Increase the number of concurrent tasks (e.g. disks that can be processed at once).  This setting can be found in the eSilo Backup Portal under Companies >> Edit >> Bandwidth >> Max Concurrent Tasks.  The minimum value should be 2, but greater numbers may be needed based on the timing and staggering of host backups.

Job session for “[JOB_NAME]” finished with error.
Error: Service provider side storage commander failed to perform an operation: CreateStorage

What this Means:

  • eSilo was not able to allocate repository storage for the backup job.

Possible Causes:

  • The assigned repository quota for this Tenant has been exceeded, thus preventing new backups from initiating.

Troubleshooting Options: 

  • Increase the Company’s repository quota.
  • Remove existing backup chains or reduce the retention period to free space.

Job Status Warning: Unable to truncate SQL server transaction logs. Details: Failed to truncate SQL server transaction logs for instances: [MSSQLSERVER].

What this Means:

  • Veeam was unable to truncate SQL server logs as specified in the job settings.

Possible Causes:

  • This most commonly due to a permissions issue.

Troubleshooting Options: 

  • This Veeam Helpcenter article discusses the Log Truncation settings.
  • You can confirm if this is a permissions issue by reviewing the Backup Job log for Warning items. Ex:  Description = The server principal “[HOST][ACCOUNT]” is not able to access the database “[HOSTNAME]” under the current security context.
  •  Grant necessary permissions and rerun the job.
  • Alternatively, you can modify the Backup Job settings to not truncate SQL Logs.
    • Edit the Backup Job
    • Under Guest Processing, click to “Customize application handling options for individual applications…”
    • On the SQL tab, select the option for “Do not truncate logs”


2. Job Session State Errors (for VMs)

Host [LOCAL_IP] is not available. Error: Cannot complete login due to an incorrect user name or password. Virtual Machine [NAME] is unavailable and will be skipped from processing. Nothing to process. [#] machines were excluded from task list.

What This Means

  • Veeam Backup and Replication was unable to access the Virtual Machine (VM) to perform the backup.

Possible Causes

  • Incorrect user name or password specified to access the source VM.  The password may have expired or the account credentials or permissions may have been changed.

Troubleshooting Steps

  • Contact the IT Administrator for the VM to troubleshoot the credentials saved in the Backup Job.


3. Job Status Errors

SQL VSS Writer is missing: databases will be backed up in crash-consistent state and transaction log processing will be skipped

What This Means

  • The SQL Writer for the Windows Volume Shadow Copy Service (VSS) is not available on the host machine, or is not configured with adequate permissions.  This issue is related to the setup of the SQL database, and not specific to eSilo provided software or the backup itself.

Steps to Confirm the Issue

  • Running ‘vssadmin list writers’ in an Administrator Command Prompt shows that SqlServerWriter is not in the list, or is in a State other than ‘Stable’.

Possible Causes

  • The SQL instance has at least one database with name starting or ending in a space character
  • The account under which SQL VSS Writer service is running doesn’t have sysadmin role on a SQL server – most frequently encountered 
  • SQL VSS Writer service is stuck in an invalid state, e.g. other than ‘Stable’

Troubleshooting Steps

  • Depending on a particular cause:
  • Rename the database to a new name (without a space in it).  To check if your database has space in the name you can run the following query:
    select name from sys.databases where name like '% '

    If you notice any spaces in the database names, then you will need to remove the spaces from the database names.

  • Grant the SQL VSS Writer service user a sysadmin role (Instructions in KB here: https://www.veeam.com/kb1978)
  • Restart SQL VSS Writer service (Instructions in KB here: https://www.veeam.com/kb2041)
  • In the case of SBS machines that are also Domain Controllers, ensure that the SQL Writer is running as a domain administrator and not local system.
  • Allow the SQL Writer service account access to the Volume Shadow Copy service via the registry:
    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesVSSVssAccessControl

    • If the DWORD value “NT SERVICESQLWriter” is present in this key, it must be set to 1.
    • If the Volume Shadow Copy service is running, stop it after changing this registry value. Do not disable it.

For More Information

See this Veeam Knowledgebase article: https://www.veeam.com/kb2095

Microsoft documentation states that the SQL Writer service must run as Local System.

  • In SQL Server 2008R2 and earlier, this means that the writer service account appears to SQL Server as “NT AUTHORITYSystem”.
  • In SQL Server 2012 and later, the writer service account appears to SQL Server as “NT ServiceSQLWriter”.


4. Computer/VM  Not Backed Up Errors

Backup Agent ‘[HOSTNAME]’ has fallen out of the configured RPO interval ([#]days). Last backup: [#] days, [#] hours ago.

What This Means

  • The host’s most recent eSilo cloud backup is greater than the specified RPO (Recovery Point Objective) interval.

Possible Causes

  • Host has been powered off or offline.
  • Backups are being saved to the host’s Local Backup Cache and all restore points in the cache have not yet synced to the eSilo Cloud Repository (e.g. eSilo has not yet received the backups).
  • Veeam Backup Agent Service or Veeam Management Agent Service is not running on host.
  • The backups and/or backup schedule have been manually disabled (uncommon).

Troubleshooting Steps

  • Verify host is online and connected to network.
  • Check Backup Job to determine if Backup Cache is enabled.  View cache folder on host to see if populated with recent restore points (default location: C:VeeamCache).
  • Verify ‘VeeamManagementAgentSvc’ service is running on host.  Status should be ‘Running’ and Startup Type should be ‘Automatic (Delayed Start)’.  If the service is ‘Stopped’, check the Event Viewer for possible error details.  See this article for more troubleshooting steps.
  • Verify ‘VeeamEndpointBackupSvc’ service is running on host.  Status should be ‘Running’ and Startup Type should be ‘Automatic’.  Restart or reinstall if necessary.
  • Check Backup Job to verify schedule and ensure not ‘Disabled’


Other Errors – Full Details Coming Soon

Error: Reconnectable protocol device was closed. Agent failed to process method {FileBackup.SyncDirs}. Exception from server: Reconnectable protocol device was closed.

Troubleshooting Steps

  • Host will reattempt job at the next scheduled interval. No user intervention is typically required.

Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Troubleshooting Steps

  • Host will reattempt job at the next scheduled interval. No user intervention is typically required.

[In Backup Job Log] Error: [CStorageLinksHelper] Link Id=[LONG_ID] doesn’t exist for storage [JOBNAME_SUBTENANTNAME]yyy-mm-ddTxxxxxx.vib

What This Means

  • While the restore point exists on the repository, the Link ID to that restore point in the metadata (.vbm) file is missing.
  • Note: If the Backup Job is configured to use Backup Cache, this error does not by itself trigger a Backup Job Failure, since the restore points are successfully written to local cache. You will notice it however, because the eSilo Backup Portal will warn that a new restore point has not been uploaded in X days (according to the RPO alarm thresholds set for this tenant).

Possible Causes

  • This can be a symptom of a network drop, where a handshake was missed in the final stages of job completion for the last restore point uploaded to eSilo. The local Veeam Agent database (on the subtenant’s machine) saw the restore point created, but the finalization step didn’t update the metadata file on the repository side with eSilo.

Troubleshooting Steps

  • In the repository, we will force the job to recreate the metadata file by editing the existing metadata file to append “.old” at the end. At the next job run, this will force a recheck of all restore points in the backup chain and recreate the metadata file from that chain.

[In Svc.VeeamEndpointBackup.log] Error: Warning  [CertificateError] Validation complete with warnings, AND/OR Warning Remote certificate chain errors, AND/OR Warning   WarningRevocationStatusUnknown (The revocation function was unable to check revocation for the certificate.

What This Means

  • The subtenant was unable to validate the eSilo Cloud Connect server’s certificate.

Possible Causes

  • If this is happening for only one tenant, as opposed to all tenants, it suggests an issue with how this specific subtenant is connecting to eSilo.
  • If no firewall or other changes have been made recently, you can recheck the credentials used by the subtenant in the backup job.
  • This Veeam KB article is also helpful for investigating common causes of certificate errors: https://www.veeam.com/kb2323

Troubleshooting Steps

  • Verify the Management Agent status shows as Connected.  You can force a reconnect by changing a property in the dialog box, then changing it back and clicking “Apply“.
  • Pause and unpause sync of Backup Cache files by right-clicking on the Veeam Backup Agent icon in the taskbar.
  • Edit the Backup Job to specify the correct sub-tenant login credentials.  Save and rerun the job. Upon the next job run, you should see “Uploading cached restore points” when you hover over the Veeam Backup Agent icon in the taskbar.

Was this article helpful?

Related Articles

Page load link

Go to Top

If you have the same resources (ie secrets) in a chart, (or more likely, multiple subcharts create the same secret) helm upgrade --install fails with

Error: release releaseName failed: secrets "secret-name" already exists


To reproduce:

  • helm create test
  • add secrets file to test/templates
  • make a copy of the secrets file in the same path
  • helm upgrade --install releaseName test/

Work-around:

  • run the same cmd again: helm upgrade --install releaseName test/

It seems that after the namespace exists, upgrade allows for the duplicate resources. It switches from creating 3 resource(s) to checking 3 resources for changes.

This workaround defeats the whole purpose of having an --install option to upgrade. But it’s worth noting that this error also appears when running helm install test/ --name releaseName


Logs in the tiller:

[tiller] 2017/09/18 15:28:13 getting history for release t2
[storage] 2017/09/18 15:28:13 getting release history for "t2"
[tiller] 2017/09/18 15:28:13 preparing install for t2
[storage] 2017/09/18 15:28:13 getting release history for "t2"
[tiller] 2017/09/18 15:28:13 rendering test2 chart using values
2017/09/18 15:28:13 info: manifest "test2/templates/ingress.yaml" is empty. Skipping.
[tiller] 2017/09/18 15:28:13 performing install for t2
[tiller] 2017/09/18 15:28:13 executing 0 pre-install hooks for t2
[tiller] 2017/09/18 15:28:13 hooks complete for pre-install t2
[storage] 2017/09/18 15:28:13 getting release history for "t2"
[storage] 2017/09/18 15:28:13 creating release "t2.v1"
[kube] 2017/09/18 15:28:13 building resources from manifest
[kube] 2017/09/18 15:28:13 creating 3 resource(s)
[tiller] 2017/09/18 15:28:13 warning: Release "t2" failed: secrets "secret-name" already exists
[storage] 2017/09/18 15:28:13 updating release "t2.v1"
[tiller] 2017/09/18 15:28:13 failed install perform step: release t2 failed: secrets "secret-name" already exists

and if you run the same command again (ie: workaround):

[tiller] 2017/09/18 15:23:27 getting history for release t2
[storage] 2017/09/18 15:23:27 getting release history for "t2"
[tiller] 2017/09/18 15:23:28 preparing update for t2
[storage] 2017/09/18 15:23:28 getting last revision of "t2"
[storage] 2017/09/18 15:23:28 getting release history for "t2"
[tiller] 2017/09/18 15:23:28 rendering test2 chart using values
2017/09/18 15:23:28 info: manifest "test2/templates/ingress.yaml" is empty. Skipping.
[tiller] 2017/09/18 15:23:28 creating updated release for t2
[storage] 2017/09/18 15:23:28 creating release "t2.v2"
[tiller] 2017/09/18 15:23:28 performing update for t2
[tiller] 2017/09/18 15:23:28 executing 0 pre-upgrade hooks for t2
[tiller] 2017/09/18 15:23:28 hooks complete for pre-upgrade t2
[kube] 2017/09/18 15:23:28 building resources from updated manifest
[kube] 2017/09/18 15:23:28 checking 3 resources for changes
[kube] 2017/09/18 15:23:28 Looks like there are no changes for Secret "secret-name"
[kube] 2017/09/18 15:23:28 Looks like there are no changes for Secret "secret-name"
[kube] 2017/09/18 15:23:28 Looks like there are no changes for Secret "secret-name"
[tiller] 2017/09/18 15:23:28 executing 0 post-upgrade hooks for t2
[tiller] 2017/09/18 15:23:28 hooks complete for post-upgrade t2
[storage] 2017/09/18 15:23:28 updating release "t2.v1"
[tiller] 2017/09/18 15:23:28 updating status for updated release for t2
[storage] 2017/09/18 15:23:28 updating release "t2.v2"
[storage] 2017/09/18 15:23:29 getting last revision of "t2"
[storage] 2017/09/18 15:23:29 getting release history for "t2"
[kube] 2017/09/18 15:23:29 Doing get for Secret: "secret-name"
[kube] 2017/09/18 15:23:29 Doing get for Secret: "secret-name"
[kube] 2017/09/18 15:23:29 Doing get for Secret: "secret-name"

Я новичок в Git и был бы признателен за помощь в добавлении подмодулей. Я получил два проекта с общим кодом. Общий код был просто скопирован в два проекта. Я создал отдельное git-репо для общего кода и удалил его из проектов, планируя добавить его как подмодуль git.

Я использовал параметр пути в git submodule add, чтобы указать папку:

git submodule add url_to_repo projectfolder

но потом получил ошибку:

'projectfolder' already exists in the index"

Это желаемая структура моего хранилища:

repo
|-- projectfolder
    |-- folder with common code

Подмодуль git можно добавить прямо в репозиторий или в новую папку там, но не в папке проекта. Проблема в том, что он действительно должен быть в папке проекта. Что я могу с этим поделать, и что я неправильно понял в опции пути добавления git submodule?





Ответы:


Боюсь, в вашем вопросе недостаточно информации, чтобы быть уверенным в том, что происходит, поскольку вы не ответили на мой дополнительный вопрос, но в любом случае это может помочь.

Эта ошибка означает, что projectfolderона уже подготовлена ​​(«уже существует в индексе»). Чтобы узнать, что здесь происходит, попробуйте перечислить все в индексе в этой папке с помощью:

git ls-files --stage projectfolder

Первый столбец этого вывода скажет вам, какой тип объекта находится в индексе projectfolder. (Они похожи на файловые режимы Unix, но имеют особое значение в git.)

Я подозреваю, что вы увидите что-то вроде:

160000 d00cf29f23627fc54eb992dde6a79112677cd86c 0   projectfolder

(т. е. строка, начинающаяся с 160000), и в этом случае хранилище в projectfolderуже добавлено как «gitlink». Если он не появляется в выходных данных git submodule, и вы хотите добавить его как подмодуль, вы можете сделать:

git rm --cached projectfolder

… чтобы удалить его, а затем:

git submodule add url_to_repo projectfolder

… чтобы добавить хранилище как подмодуль.

Тем не менее, также возможно, что вы увидите много больших двоичных объектов в списке (с режимами файлов 100644и 100755), что подсказывает мне, что вы не удалили файлы должным образом projectfolderперед копированием нового репозитория на место. Если это так, вы можете сделать следующее, чтобы удалить все эти файлы:

git rm -r --cached projectfolder

… а затем добавьте субмодуль с помощью:

git submodule add url_to_repo projectfolder







Удаление субмодуля вручную включает в себя несколько шагов, и это сработало для меня.

Предполагая, что вы находитесь в корневом каталоге проекта, и пример git-модуля называется «c3-pro-ios-framework»

Удалить файлы, связанные с субмодулем

rm -rf .git/modules/c3-pro-ios-framework/

Удалите все ссылки на субмодуль в конфигурации

vim .git/config

введите описание изображения здесь

Удалить .gitmodules

rm -rf .gitmodules

Удалите его из кеша без «мерзавца»

git rm --cached c3-pro-ios-framework

Добавить субмодуль

git submodule add https://github.com/chb/c3-pro-ios-framework.git







Вам нужно сначала удалить подмодуль git-репозиторий (в данном случае это папка проекта) для пути к git.

rm -rf projectfolder

git rm -r projectfolder

а затем добавить субмодуль

git submodule add <git_submodule_repository> projectfolder




У меня была такая же проблема, и после долгих поисков нашел ответ.

Ошибка, которую я получал, была немного другой: <path> already exists and is not a valid git repo(и добавлена ​​здесь для ценности SEO)

Решение — НЕ создавать каталог, в котором будет размещаться субмодуль. Каталог будет создан как часть git submodule addкоманды.

Также ожидается, что аргумент будет относиться к корню parent-repo, а не к вашему рабочему каталогу, так что следите за этим.

Решение для примера выше:

  1. Это нормально, если ваш родительский репозиторий уже клонирован.
  2. Убедитесь, что common_codeкаталог не существует.
  3. cd Repo
  4. git submodule add git://url_to_repo projectfolder/common_code/( Обратите внимание на обязательную косую черту. )
  5. Здравомыслие восстановлено.

Я надеюсь, что это кому-то поможет, так как об этом очень мало информации.





если существует папка с именем xпод управлением git, вы хотите добавить субмодуль с тем же именем, вы должны удалить папку xи зафиксировать ее в первую очередь .

Обновлено @ ujjwal-singh:

Фиксация не нужна, достаточно постановки .. git add/git rm -r




Просто чтобы уточнить на человеческом языке, что ошибка пытается сказать вам:

Вы не можете создать репозиторий в этой папке, который уже отслеживается в основном репозитории.

Например: у вас есть папка с темой, AwesomeThemeкоторая называется выделенным репозиторием, вы пытаетесь сделать дамп непосредственно в свой основной репозиторий, как это происходит, git submodule add sites/themesи вы получаете это "AwesomeTheme" index already exists.

Вам просто нужно убедиться, что sites/themes/AwesomeThemeотслеживания версий в главном репозитории еще нет, поэтому подмодуль может быть создан там.

Чтобы исправить, в вашем главном хранилище, если у вас есть пустой sites/theme/AwesomeThemeкаталог, затем удалите его. Если вы уже сделали коммиты с sites/theme/AwesomeThemeкаталогом в вашем главном репозитории, вам нужно удалить всю историю этого с помощью команды, подобной этой:

git filter-branch --index-filter 
              'git rm -r --cached --ignore-unmatch sites/theme/AwesomeTheme'     HEAD

Теперь вы можете запустить git submodule add git@AwesomeTheme.repowhateverurlthing sites/themes/AwesomeTheme

Поскольку главный репозиторий никогда не видел ничего (он же index’d) sites/themes/AwesomeTheme, он теперь может его создать.


Я получил это, работая наоборот. Начиная с пустого репо, добавляя субмодуль в новую папку с именем «projectfolder / common_code». После этого можно было добавить код проекта в проектную папку. Детали показаны ниже.

В пустом репо введите:

git submodule add url_to_repo projectfolder/common_code

Это создаст желаемую структуру папок:

repo
|-- projectfolder
    |-- common_code

Теперь можно добавить больше подмодулей, а код проекта можно добавить в папку проекта.

Я пока не могу сказать, почему это работает так, а не иначе.


Не знаю, насколько это полезно, хотя у меня возникла та же проблема при попытке зафиксировать мои файлы из IntelliJ 15. В конце я открыл SourceTree, и там я мог просто зафиксировать файл. Задача решена. Нет необходимости вводить какие-либо необычные команды git. Просто упомяну это на тот случай, если у кого-то возникнет такая же проблема.


Перейдите в папку хранилища. Удалите соответствующие подмодули из .gitmodules. Выберите показать скрытые файлы. Перейдите в папку .git, удалите подмодули из папки модуля и настройте.


Это происходит, если в целевом пути отсутствует файл .git. Это случилось со мной после того, как я казнил git clean -f -d.

Мне пришлось удалить все целевые папки, показанные в сообщении, а затем выполнить git submodule update --remote


Предположим, в вашем git dir синхронизированы все изменения.

rm -rf .git 

rm -rf .gitmodules

Затем сделайте:

git init
git submodule add url_to_repo projectfolder


Понравилась статья? Поделить с друзьями:
  • Error of set pic flash addr
  • Error of principle
  • Error of loading of the data перевод
  • Error of judgement перевод
  • Error of indirect measurements