GL-iNet MT1300 Some Apple Time Machine Issues (ext-Root + Block-Mount + Samba4)

Installing and Using OpenWrt
1

Attempting via a GL-MT1300 (GL-iNet) running a clean install of OpenWrt 19.07.8 -> 22.03.02.

And, willing to use the prebuilt GL firmware 3.215 w/ OpenWrt 19.07.8.
** NOTE ** Device has a SD card slot (mmcblk0p1) and USB port (sda1).

First off, Hi :wave: I'm new here but willing to learn and earn some good karma!

Currently my goal for the device is to use it as a portable modern day "Airport Time Capsule" for a MacOS computer with an ext-Root partition hosting (adGuard/adBlock) on a SD card.

  • I've accomplished so far in separate instances but never together :face_with_raised_eyebrow::
    • Getting the device to read and write to a USB (sda1) Master Boot Record formatted HFS+ drive this works for all instances below. (:trophy:)
      • Creating an ext-Root on a SD Card (mmcblk0p1) in a EXT4 format with an installation of AdGuard Home/AdBlock just to confirm new overlay works.
      • Creating a samba4 based Apple Time Machine that connects to macOS via (SMB). So far works with (Big SUR -> Monterey -> Ventura)

ISSUE #0 (Block-Mount)
After an accidental loss of power (Unplugging power cable)

  • The router losses write access to the HFS+ USB (sda1). This of course cascades to Samba4.
    • Somehow this returns the USB (sda1) back to a read only device. Even with it set to force,rw,noatime in mount options.
      • FIX so far I found unplugging the USB from the router and connecting it to MacOS. And, running first aid on the volume in disk utility. Then reconnecting the USB to the device followed by a reboot of the router.
      • While this does work It’s not ideal. I rather the router “run first aid” on the USB + remount it as a read/write partition.

ISSUE #1 (Block-Mount + Samba4) "Rare chance"
After an accidental loss of power (Unplugging power cable)

  • The router automatically sets the HFS+ USB to (sdb1).
    • FIX log into the luci and reconfigure the drive back to /dev/sda1.
      • While this does work its not ideal. I rather the device set any USB plugged in as (/dev/sda1 /mnt/sda1) automatically
      • Or, recognise the "timeMachine" USB always as (sda1).

ISSUE #2 (Block-Mount + ext-Root + Samba4)
I've gotten ext-Root to work, migrated all of the packages over to the SD Card (mmcblk0p1).

Unfortunately, when I list the actual mount location (Path ->) of the USB (mnt/sda1) in samba4 it does not appear via SMB this goes for any USB sans format.

  • I’ve tried setting it to /mnt/sda1 I can definitely find the USB there when I SSH into the device location with read and write privileges.
    • I think it’s true location is somewhere else on the system due to ext-Root. :thinking:
    • Or, ext-Root even though it’s hosted in the SD Card. May be interfering with samba4 as it's now in a SD-Card instead of the usual standard USB drive.
      • Could use some assistance on keeping samba4 on the devices internal memory while establishing an ext-Root to host packages like AdGuard Home/AdBlock.
      • Or, finding the true path of the USB (mnt/sda1) location.

TL:DR/Summary
I’m currently documenting my notes on how to recreate this device from scratch to be submitted for review. Post completion and a brief stress test.

I’m not ungrateful, but I’ve noticed a lot of the guides here are deprecated and some solutions are spread out via multiple sources/websites. And, because of this I was inspired to leave a slight mark here as good karma. But, I need a bit more professional support.

If you have any questions, comments or concerns. I’m happy to provide content! :grin:

And, would really appreciate it if individuals lists options and solutions to each issues via the (#) number above. I’m new•ish to programming. But, dedicated life long learner.

And, again thank you for your time. :pray::star_struck: I’ll be checking this forum post periodically.

2

Sounds like a GL.inet firmware, you should ask/help them.

3

What leads you to believe that? I'm not saying it can't be. :grin: But, your answer does comes off a bit dismissive. This issue can be seen via other users attempting similar designs. (Block-Mount + ext-Root + Samba4)

4

What makes you belive it isn't?

You're not the 1st (or last) person asking for help about a black box fw released by a 3rd party.

That's too bad, but the error should be reported to gl.inet, or install proper openwrt.

6

I've removed their software still received the same issues. And, I'm not denying this could be a device specific problem. But, this is my second router. I've converted to openWRT and I am not using their (GUI).

I've installed everything via SSH and configured samba4 and block-mount via Luci. And, corrected my post to show this.

7

Then start by upgrading, 19.07 is EOL.

9

That is still a gl.inet release.

Use the file provided on the wiki page, or direct your questions to gl.inet.

10

If your firmware comes from any location other than openwrt's own servers (i.e. downloads.openwrt.org), it is (almost certainly) not an official OpenWrt version.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

11

:thinking: I'm sure I mentioned in the post that this device is easily capable of running a clean version of openWRT via a Uboot reset. And, that I am willing to try and correct these issues via multiple sources of firmware. OpenWRT, Gl-inet or other...

As I know the information here can be limited. As this is a public forum provided via volunteers. Testing multiple streams of open source firmware may be confusing to some.

And, I do not want to give the impression to a random person from google that this is an easy task.

12

I only mention this because the "22.03 based" version you mentioned/linked is still not pure OpenWrt... if you are running anything other than the official OpenWrt, you need to ask at the GL-inet support channels instead of here.

It's not entirely clear to me if you're still trying to use the GL-inet firmware based on 22.03, or if you're using an official version from the OpenWrt downloads site.

To be clear, nobody here is testing multiple streams of open source firmware... OpenWrt developers develop the official version of OpenWrt, and the forum contributors are users of the official version. This forum doesn't offer support for other forks... sometimes there is a 'best effort' when the problem is simple, but it is limited.

All of the testing for OpenWrt forks is the responsibility of the respective developers and supported by those developers and/or the companies that supply the forks (such as GL-inet among others).

You may already know this (so please accept my apologies if this is all obvious to you), but I say it just in case you and/or future readers of this thread don't have a clear understanding of how OpenWrt and the "based on OpenWrt" forks are related.

1 Like
13

I have mentioned numerous times that I am testing all copies of the firmware that the machine is capable of running. ("official" openWRT, or otherwise) As a certain FAANG corporation while generous does have a limited return window....

And, this thread is getting a bit long in the tooth.

I would not recommend anyone run unstable "beta" software or other heroic developer feats without using caution. :warning:

As a form of de-escalation I have redacted the link.

But, still require some assistance on the issues listed above.

14

So all of the problems still occur as exactly as written when using 22.03.2 or 22.03.3 (just released)?

what's in your fstab file?

15

These issues arise on all versions. Can you provide me a list of all diagnostic questions.(or a link to)

As I would like to help speed up the diagnoses.

root@GL-MT1300:/# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>

This is from a version not using ext-root.
(ISSUE #0 (Block-Mount))
(ISSUE #1 (Block-Mount + Samba4) "Rare chance")

16

it would likely be
cat /etc/config/fstab

You'll probably need to do this both for the extoot as well as pre-extroot (I can't remember how to access that location -- I want to say it is lower when the extoot is active but I don't see how to get access to that filesystem)... you can pull the extroot media and boot normally to view that file.

Also, it seems likely that you're still running GL-inet's firmware. If you want help here, install OpenWrt 22.03.3 and stay on that version until we either resolve the issue or exhaust all ideas. Using any other firmware from any other source is not a viable option here.

1 Like
17

In your first post you say you’re using hfs+, don’t do this, it’s unreliable in Linux and will get locked read only on any unscheduled reboot to protect the data.

It’s also slow as hell.

Time Machine works fine on ext4 or other ‘proper’ Linux file systems.

18

I am posting from a clean version. Just wise enough to keep the manufacturer name so I don't :brick: my main router especially when swapping firmware back and forth.

Pre ext-Root

root@GL-MT1300:/# cat /etc/config/stab

config global
	option anon_swap '0'
	option anon_mount '0'
	option auto_swap '1'
	option auto_mount '1'
	option delay_root '5'
	option check_fs '0'

config mount
	option target '/mnt/sda1'
	option fstype 'hfsplus'
	option options 'force,rw,noatime'
	option label 'Standard Flash Drive Media'
	option enabled '1'

Running ext-Root

root@GL-MT1300:/# cat /etc/config/fstab

config global
	option anon_swap '0'
	option anon_mount '0'
	option auto_swap '1'
	option auto_mount '1'
	option delay_root '5'
	option check_fs '0'

config mount
	option target '/mnt/sda1'
	option fstype 'hfsplus'
	option options 'force,rw,noatime'
	option label 'Standard Flash Drive Media'
	option enabled '1'

config mount 'rwm'
	option device '/dev/mtdblock6'
	option target '/rwm'

config mount 'overlay'
	option uuid ‘REDACTED`
	option target '/overlay'
19

if you use UUIDs to mount the drives, it should theoretically prevent the issue you're experiencing.

20

I have not experienced any speed issues. The usb port on the device is USB 3.0 and the "Standard Flash Drive Media" is showing the correct read and write speeds.

21

Found this in my notes. I probably copied it somewhere. I can't remember where though. I've been entrenched in this design for the last few weeks.

-> ## Do you need, to configure extRoot path, or temporarily disable it?
Once booted into your extRoot, you can edit /rwm/upper/etc/config/fstab to change your extRoot configuration (or temporarily disable it) should you ever need to.

22

the /rwm directory doesn't exist on my device, so I'm guessing that that method is either a bit old or from a different context (such as the overlay pivot instead of an extroot, which IIRC are different in some nuances, but similar in principle... I've only ever used the formal extroot process).