What's new

BACKUPMON BACKUPMON v1.8.20 -Oct 12, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! CIFS/SMB/NFS! (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

BTW... when creating a Windows share... you can add the "Everyone" group to the share name... give it read/write access. Then it doesn't need a password. Or you can just use "admin / admin" in that case. But please know... that's the "I'm going to leave the door unlocked and wide-open" insecure approach of doing things, but if you don't have curious users on your network on a mission to destroy your backups in unsecured backup folders like this, it's a good start... then start experimenting with locking things down with usernames/passwords after you get this working.

Please be sure to share a screenshot your configuration screen or /jffs/addons/backupmon.d/backupmon.cfg file, to make sure everything looks right... happy to help! :)
You probably already have this in your script, but I found that I needed the following in my services-start script on my AX86 Pro to get Win 10 shares to work:
Bash:
#!/bin/sh
/sbin/modprobe md4
 
You probably already have this in your script, but I found that I needed the following in my services-start script on my AX86 Pro to get Win 10 shares to work:
Bash:
#!/bin/sh
/sbin/modprobe md4

I do believe this is what he uses as per this post:

I use "modprobe md4"... which seems to do the trick? I'll look into your suggestion!
 
I do believe this is what he uses as per this post:

Correctamundo! :)

1717978857680.png
 
BTW... when creating a Windows share... you can add the "Everyone" group to the share name... give it read/write access. Then it doesn't need a password. Or you can just use "admin / admin" in that case. But please know... that's the "I'm going to leave the door unlocked and wide-open" insecure approach of doing things, but if you don't have curious users on your network on a mission to destroy your backups in unsecured backup folders like this, it's a good start... then start experimenting with locking things down with usernames/passwords after you get this working.

Please be sure to share a screenshot your configuration screen or /jffs/addons/backupmon.d/backupmon.cfg file, to make sure everything looks right... happy to help! :)
1718147242585.png


Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.
 
View attachment 59374

Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.
It really sounds like something might be up with the storage end. It seems to be creating other files fine... but then it bombs on the .tar file. First, try this:

Under the testing & dianostics, hit the (ts) option:
1718147737651.png


Then hit the (p) option, to import your primary backup settings... then hit (t) to test it out.
1718147778898.png


Share the output of your screen so we can see the results?

Windows 10 machine, right? Do you have any AV or anything that might be preventing .tar.gz files from writing to your harddrive? Never mind... the jffs written right before this was a tar.gz. ;) So that's not it.
 
Last edited:
Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.
I suppose it could also be that your attached USBdrive is bombing out maybe due to errors? Have you taken a look at the (dcl) option under AMTM? Perhaps that might shed some light on the health of your /tmp/mnt/usbdrive device?

1718148210777.png
 
I don't mean to send us all the way back to the start. But I didn't see confirmation the network share is actually functional.

Is the created network share (Routerbackups) accessible and working from any other windows computer on the same network? (I.e test from any device other than the router and the computer it's created on)
If the share is created on computer "A", find another PC (computer "B") and open windows file explorer, and type in the network share path in the address bar or map a network drive.

This would be a good test to validate if everything is configured correctly for the network share, or if it's really a configuration issue of Backupmon.
Edit: Or an issue with the usbdrive, etc.
 
Last edited:
I suppose it could also be that your attached USBdrive is bombing out maybe due to errors? Have you taken a look at the (dcl) option under AMTM? Perhaps that might shed some light on the health of your /tmp/mnt/usbdrive device?

View attachment 59377
1718149478905.png
1718149545239.png
 
I don't mean to send us all the way back to the start. But I didn't see confirmation the network share is actually functional.

Is the created network share (Routerbackups) accessible and working from any other windows computer on the same network? (I.e test from any device other than the router and the computer it's created on)

If the share is created on computer "A", find another PC (computer "B") and open windows file explorer, and type in the network share path in the address bar or map a network drive.

This would be a good test to validate if everything is configured correctly for the network share, or if it's really a configuration issue of Backupmon.

Edit: Or an issue with the usbdrive, etc.
I actually just accesed the shared folder via my W11 PC. The share is on a W10 machine. Since I had everyone configured for access it let me right into the folder without authentication.
 
Well that rules out my theory, seems the share is functional from the router and other devices.

Back you to @Viktor Jaep 🤣😉
 
Thanks buddy!!

@Gen10 ... I think it might be your USB drive. When you continually see these "recovering journal" messages, that's usually bad news. @ColinTaylor may have some better advice. I would see about taking it offline, and trying to repair it some other way. Is it a flashdrive? They typically don't hold up well. Worse comes to worst, you may need to replace it with a more capable SSD.
 
Thanks buddy!!

@Gen10 ... I think it might be your USB drive. When you continually see these "recovering journal" messages, that's usually bad news. @ColinTaylor may have some better advice. I would see about taking it offline, and trying to repair it some other way. Is it a flashdrive? They typically don't hold up well. Worse comes to worst, you may need to replace it with a more capable SSD.
Funny enough it actually is an SSD. This one to be exact. https://www.amazon.com/dp/B076XMH2JT?tag=snbforums-20

I can certainly try some basic windows drive repairs on it unless there's better ways to repair.
 
Well, I didn't see anyone asking for the "ve" output.
It should tell us some important information (mine was the bad USB drive mounting point).

Enjoy!
 
Well, I didn't see anyone asking for the "ve" output.
It should tell us some important information (mine was the bad USB drive mounting point).

Enjoy!
Right you are... might give some more clues. @Gen10 ... Can you post your (ve) logs please?
 
Right you are... might give some more clues. @Gen10 ... Can you post your (ve) logs please?

Code:
GNU nano 7.2                                     /jffs/addons/backupmon.d/backupmonerrors.log
 1 BEGIN ERRORLOG ->
 2 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - tar: can't change directory to '/tmp/mnt/usbdrive': No such file or directory
 3 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - **ERROR**: Errors detected creating EXT Drive tar file.

Yup that was it! I derped and didn't change the USB directory as I thought only the network drive was used initially. It was set to default this whole time! Once I modified the usbdrive value to my actual directory I was able to succesfully backup.
 
Code:
GNU nano 7.2                                     /jffs/addons/backupmon.d/backupmonerrors.log
 1 BEGIN ERRORLOG ->
 2 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - tar: can't change directory to '/tmp/mnt/usbdrive': No such file or directory
 3 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - **ERROR**: Errors detected creating EXT Drive tar file.

Yup that was it! I derped and didn't change the USB directory as I thought only the network drive was used initially. It was set to default this whole time! Once I modified the usbdrive value to my actual directory I was able to succesfully backup.
OMG! I'm so glad that made a lightbulb go off on your end. Thanks to @Wendigogo for doing the same to me and reminding me of this recently-implemented feature. ;)
 
I might go ahead and change the default to something that stands out more, so it's easier to identify. Like:

/tmp/mnt/<NAMEOFYOURUSBDRIVE>

or something like that. 😉
 
I might go ahead and change the default to something that stands out more, so it's easier to identify. Like:

/tmp/mnt/<NAMEOFYOURUSBDRIVE>

or something like that. 😉
/tmp/mnt/<FILLINTHEBLANK>
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top