Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Junos] Commit Error: "error: could not copy to juniper.save+ "

0

0

Article ID: KB35899 KB Last Updated: 15 Jun 2020Version: 1.0
Summary:

This article details the steps to follow when users run into the "error: could not copy to juniper.save+" error while committing a configuration.

 

Symptoms:

The following error is reported when configuration changes are committed:

user@host#commit

configuration check succeeds
fpc1:
error: could not copy to juniper.save+
fpc0:
error: remote commit-configuration failed on fpc1
fpc2:
error: could not copy to juniper.save+
fpc0:
error: remote commit-configuration failed on fpc2
fpc3:
error: could not copy to juniper.save+
fpc0:
error: remote commit-configuration failed on fpc3
fpc4:
error: could not copy to juniper.save+
fpc0:
error: remote commit-configuration failed on fpc4
error: commit failed

 

Solution:

To identify the root cause and recover the device from fault state, perform the following steps:

  • Perform a file system cleanup.

  1. This step cleans up the directories and files that are not mandatory for the device. These are mostly files and folders that the user has flooded. Before directly removing the files through "clean-up," perform a dry-run that will list all the files that will be deleted during the clean-up process.

user@host>request system storage cleanup dry-run
  1. Verify the files to be deleted. You may consider taking a backup of these files in case you want to use them later. After backing up the files, perform a clean-up:

user@host>request system storage cleanup
  • If a cleanup does not help, check for corrupt partitions, if any, and repair them:

You can run the fsck command manually although the device will repair any corruption during the boot cycle when the file system check is run. To run fsck manually, refer to Example: Using Fsck to Check and Repair a Filesystem.

  • If the above two steps do not resolve the problem, clear the directory where the problematic file is stored (in this case, the error log shows the problematic file to be juniper.save+):

Save the current configuration in a text file. From the CLI,  go to the shell by using the command start shell.

user@host> start shell

If you are not logged in as root, use the su command to log in as root. Run the following commands:

root@host:~ #  find / -name juniper.save
/var/run/db/juniper.save

root@host:~ # cd /var/run/db
root@host:/var/run/db #

Confirm that the directory has been changed by running the pwd and ls commands.

root@host:/var/run/db # pwd
/var/run/db

root@host:/var/run/db # ls
.db_lock                juniper.data            private
.mustd.lock             juniper.db              schema.db
agentd                  juniper.dyn             schema.db.cache
chassisd.dynamic.db     juniper.save

Enter the following command to remove files starting with "juniper."

root@host:/var/run/db # rm juniper.*

Enter the following command:

root@host:/var/run/db # mgd -I

After the command is run, verify the storage from Operational mode:

root@host> show system storage | match rundb
/dev/md17               118M        61M        48M       56%  /var/rundb
/dev/md17               118M        61M        48M       56%  /var/rundb
/dev/md17               118M        61M        48M       56%  /var/rundb
/dev/md17               118M        35M        74M       32%  /var/rundb
/dev/md17               118M        81M        27M       75%  /var/rundb

If you have any problems with the configuration after performing these steps, you can use the backed up and saved configuration in the first step to perform recovery.

Verification

Verify by trying to commit a basic configuration:

root@host# set system commit synchronize

root@host# commit check
fpc3:
configuration check succeeds
fpc0:
configuration check succeeds
fpc1:
configuration check succeeds
fpc2:
configuration check succeeds
fpc4:
configuration check succeeds

root@host# commit confirmed 5
fpc3:
configuration check succeeds
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
fpc0:
commit complete
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
fpc1:
commit complete
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
fpc2:
commit complete
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
fpc4:
commit complete
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
fpc3:
commit complete

Commit confirmed will be rolled back in 5 minutes.

root@host# commit
fpc3:
configuration check succeeds
fpc0:
commit complete
fpc1:
commit complete
fpc2:
commit complete
fpc4:
commit complete
fpc3:
commit complete

Note: If this does not solve the problem, you may need to perform a format-install of the device. Since the user will lose existing configuration during this procedure, it is recommended to exercise caution and contact Support for assistance.

 

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search