Sorry for the toll these releases are taking on your signature line!And working fine at v3.02
Keep rolling out them betas with the same numbers my fingers will be fineSorry for the toll these releases are taking on your signature line!
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon-1.40.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"
Hmm...which of the CIFS/SMB Versions is the "true" default? The upper block of text would indicate that the default is Version 2.1, but the screenshot text (when choosing option #9) seems to indicate that "By default, BACKUPMON supports the latest version available (v3.02), ....", so which one is it? Am I being dense here?Thanks to all for your help testing the new features! v1.40 is out! Happy Thanksgiving!
What's new?
v1.40 - (November 20, 2023)
- ADDED: You now have the ability to choose which version of the CIFS/SMB protocol you want to use. Thanks to @vaboro, you can choose between using v1.0, v2.0, v2.1 (default), v3.0 and v3.02. This is especially useful when connecting to older hardware that may not be able to support the later versions, as it is apparent that older NAS or routers are still in use that need this for backwards compatibility.
- FIXED: Changed some of the logic around detecting the primary EXT USB drive in order to determine its label name. This is used to present a warning if the label is blank. Before, it would not let the user proceed, but now it just gives a 10sec warning before continuing, and gives some suggestions on what to label the drive, and that in its current state, may have consequences on the operation of BACKUPMON. Thanks to @_m4t3u_ and @TheMorpN for bringing this to light.
- FIXED: Thanks to a suggestion from @thelonelycoder, after the script downloads an update, it will no longer ask the user to exit and restart. Now using the exec command, the script restarts by itself, and goes back to the -setup menu.
Download link (or update directly within AMTM):
Code:curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon-1.40.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"
Significant Screenshots:
Here with option #9, you now have control over which version of the CIFS/SMB protocol you want to use... definitely helpful for backwards compatibility with older equipment that might be limited to lesser protocol versions.
View attachment 54379
Default version is v2.1, which remains unchanged for those who don't mess with the settings... but by default (out-of-the-box), it also supports the latest version, v3.02... yeah, I see why it's confusing. I'll look at changing the wording.Hmm...which of the CIFS/SMB Versions is the "true" default? The upper block of text would indicate that the default is Version 2.1, but the screenshot text (when choosing option #9) seems to indicate that "By default, BACKUPMON supports the latest version available (v3.02), ....", so which one is it? Am I being dense here?
Either way, it shouldn't interfere with the BACKUPMON process. This is rock solid!Default version is v2.1, which remains unchanged for those who don't mess with the settings... but by default (out-of-the-box), it also supports the latest version, v3.02... yeah, I see why it's confusing. I'll look at changing the wording.
Disabled the built-in Samba and installed more current version in a debian bootstrapped environment:It's not entirely straight forward as the inbuilt Samba code conflicts with the Entware version.
PORT STATE SERVICE
445/tcp open microsoft-ds
MAC Address: 22:33:44:55:66:77 (ASUSTek Computer)
Host script results:
| smb-protocols:
| dialects:
| NT LM 0.12 (SMBv1) [dangerous, but default]
| 2:0:2
| 2:1:0
| 3:0:0
| 3:0:2
|_ 3:1:1
I'm so glad things continue to function and that you're back in working order! Talk about embarrassing... throughout development, I had "accidentally" restored my router at least 2x before realizing I hadn't commented out the necessary code that would have prevented that... and before I knew it, it was too late, and BAM ... reboot. LOLOnce again, rather embarrassingly, I've had reason to test the restoration.
I'm quite proud to announce that this side of the script is still working sweet and dandy
I'd love to hear about your experience!
Happy to help! The goal is to make this whole process as easy as possible... and really appreciate your participation!
RTR_AX_6000# tune2fs -L ms_part /dev/sda1
tune2fs 1.45.6 (20-Mar-2020)
tune2fs: Bad magic number in super-block while trying to open /dev/sda1
RTR_AX_6000# ntfs-3g.probe --readwrite /dev/sda1
NTFS signature is missing.
Disk /dev/sda: 4294967295 sectors, 2047G
Logical sector size: 512
Disk identifier (GUID): 800cea48-20f4-4c4e-8631-daade6f7b784
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7813969886
Number Start (sector) End (sector) Size Code Name
1 34 32767 15.9M 0700 Microsoft reserved partition
2 32768 7813965823 3725G 0700 Basic data partition
RTR_AX_6000# blkid | grep sd
/dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3"
/dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"
Hi again!
Today I've been doing some testing. Sadly I've been unable to re label the NTFS, which was no labeled during its creation, partition located on my /dev/sda device (sda1).
I've tried the following:
1.- The command you provided as for testing purposes only. The results are, as expected, that this command works only with ext(4?) partitions:
Code:RTR_AX_6000# tune2fs -L ms_part /dev/sda1 tune2fs 1.45.6 (20-Mar-2020) tune2fs: Bad magic number in super-block while trying to open /dev/sda1
2.- Installed ntfs-3g package from Entware, the install worked seamesly but, it seems that the tool I needed to change the partition label (ntfslabel) is not included, for Asus-Wrt, with the main package. While ntfs-3g runs without any problem it does not permit to re label partitions without ntfslabel tool. But, it permits to testing access to NTFS partitions, I've tried this with the "rebel" partition.
Code:RTR_AX_6000# ntfs-3g.probe --readwrite /dev/sda1 NTFS signature is missing.
So one of the previous commands may have retired/deleted some info from the unlabeled device and/or from nvram too, but I'm not sure which of two commands was the responsible... The partitions continue the same though:
Code:Disk /dev/sda: 4294967295 sectors, 2047G Logical sector size: 512 Disk identifier (GUID): 800cea48-20f4-4c4e-8631-daade6f7b784 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 7813969886 Number Start (sector) End (sector) Size Code Name 1 34 32767 15.9M 0700 Microsoft reserved partition 2 32768 7813965823 3725G 0700 Basic data partition
But blkid can't get any information about /dev/sda1 that could previously be retrieved with this command
Code:RTR_AX_6000# blkid | grep sd /dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3" /dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"
At this point, I will go with a complete wipe of that mechanical disk and USB FlashDrive. I've bought a new SSD to use in place of FlashDrive, with just one partition. I will allocate there the swap (file) and some data, like BACKUPMON copy data. The mechanical disk will be used as SMB share again but not as backups destination or any else router related data.
Of course, after that I'll go with amtm, BACKUPMON 1.4, Skynet and AdGuardHome as soon I can.
Thanks for your all your work and support!
The MSR partition (/dev/sda1) does not contain a filesystem. Not NTFS or any other type. Therefore it cannot be given a volume label.Today I've been doing some testing. Sadly I've been unable to re label the NTFS, which was no labeled during its creation, partition located on my /dev/sda device (sda1).
Absolutely! Thanks for all this great info... what a pain, all for just a label, right? Well, I'm glad you have a solid plan in place. It will be better than it was before - definitely something to look forward to! Happy Thanksgiving!
This was dealt with several generations ago. Running the restore deletes the config file in /jffs/scripts/ just before the reboot. If your's is leaving the config file then you seriously need to update.The one thing I didn't like about the restore is the initial step to restore both the script and config to the /jffs/scripts directory. After one then does the initial setup you're left with two config files; one in /jffs/scripts and the other in /jffs/add-ons/...
The one thing I didn't like about the restore is the initial step to restore both the script and config to the /jffs/scripts directory. After one then does the initial setup you're left with two config files; one in /jffs/scripts and the other in /jffs/add-ons/...
This was dealt with several generations ago. Running the restore deletes the config file in /jffs/scripts/ just before the reboot. If your's is leaving the config file then you seriously need to update.
So now there's nothing for you to dislike.
I've got lazy. I no longer check the settings, just straight into a restore. Even if I did check the settings because the settings wouldn't need changing the two config files would be identical and not cause a problem.Ah.. that's probably because I didn't actually do the restore; just the copy of the files and the initial run of setup. Surely if the initial setup run reads the "restored" config and writes it to the correct location, wouldn't it make sense to drop it then, and not wait for a restore / reboot cycle?
I'm trying to make the restore process as easy as possible... by copying the main script and its config into the same folder was in my mind, the easiest way to go. It will actually go as far as copying the cfg file back into the /jffs/addons/backupmon.d/ folder, however, if your restore worked, it would have overwritten that folder with all its original contents anyways. Then the very last thing it does before it reboots, is delete the .cfg out of the /jffs/scripts folder.Ah.. that's probably because I didn't actually do the restore; just the copy of the files and the initial run of setup. Surely if the initial setup run reads the "restored" config and writes it to the correct location, wouldn't it make sense to drop it then, and not wait for a restore / reboot cycle?
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!