You aren't telling us much, like what software you are using. I would expect you to need to give it something like smb://10.10.2.101/NAME_OF_SHARE/ or sftp://10.10.2.101:/path/to/folder You will also need to give it a username and password somehow. But first; have you checked you can reach it on the network?

On my Debian13 VM that I use to build images for my boards, I have started to notice new errors that I have not seen before after this part of the logs... [🐳|🌱] After updating and cleaning image apt list cache [ 30 files ] [🐳|🌱] Image installed package hash [ ✅ base-files = 1-trixie-1armbian1-Bb095-U13.8--deb13u4-R55fa ] [🐳|🌱] Image installed package hash [ ✅ linux-image-current-rockchip64 = 6.18.26-S1fe0-Dedd0-P1f35-Cc077-H8200-HK01ba-Vc222-Bed86-R448a ] [🐳|🌱] Image installed package hash [ ✅ armbian-firmware = 1-SAa38b-B96c8-R448a ] [🐳|🌱] Image installed package hash [ ✅ armbian-bsp-cli-rockpro64-current = 1-PC1e15-V9ab0-H3400-Bd2e9-Rf36a ] [🐳|🌱] Image installed package hash [ ✅ linux-u-boot-rockpro64-current = 2025.01-S6d41-P6e2c-Hbf76-V6f3c-Be4e9-R448a ] [🐳|🌱] Image installed package hash [ ✅ linux-dtb-current-rockchip64 = 6.18.26-S1fe0-Dedd0-P1f35-Cc077-H8200-HK01ba-Vc222-Bed86-R448a ] [🐳|🔨] removed '/armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/etc/resolv.conf' [🐳|🔨] removed '/armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/sbin/initctl' [🐳|🔨] removed '/armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/sbin/start-stop-daemon' [🐳|🔨] removed '/armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/usr/sbin/policy-rc.d' [🐳|🌱] Removing qemu-user-static binary from chroot [ qemu-aarch64-static during image ] [🐳|🔨] removed '/armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/usr/bin/qemu-aarch64-static' [🐳|🌱] Unmounting [ /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210 ] Once the unmounting of rootfs-nouuidgen-yet begins I notice the following errors spam in the logs, 1000+ lines, and finally the target unmounts successfully and the image finishes building. The images still boot fine. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/dev: target is busy. [🐳|🔨] tmpfs /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/dev tmpfs rw,nosuid,size=65536k,mode=755,inode64 0 0 umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/dev/pts: not mounted. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/dev: target is busy. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/proc: not mounted. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/sys: not mounted umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/tmp: not mounted. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/var/tmp: not mounted. umount: /armbian/.tmp/rootfs-no-uuidgen-yet-15898-49210/run/user/0: not mounted. Is there a way to adjust some kind of timeout for this to prevent the massive amount of "target is busy" outputs in the logs? Thank you for any help or insights!

Hi, I have a Samba server on a TV Box. I installed Samba, defined a location for the server (srv/Public), created and user and UFW (firewall) allowing Samba protocols. I also defined srv/Public in /etc/fstab (Windows uses NTFS). Pls, tell if you need additional info. Regards, Sergioclr

I don't own that box so I can only give you generic help. You really would need to hook up a usb-uart adapter to access the uboot debug output to see what is happening. The second thing I would say is that I have no idea what ophub builds do as they are not Armbian builds, ophub is a fork, they don't contribute to Armbian development nor do they participate in these forums. So per the Armbian amlogic TV box instructions, the boot environment must be a clean android boot environment. Installing or running any other distribution may cause Armbian to not boot. So I'd recommend either reinstalling a clean Android image to test from, or investigate any differences in boot scripts to see what might be going on. But again getting access to the new boot serial console would help a lot.

Hi all, I'm trying to boot Armbian from USB on a Foxconn BANDOTT BA101 (Amlogic S905D, 2GB RAM, 8GB eMMC — same SoC/RAM/storage as a Phicomm N1, originally shipped with Android TV 7.1.2). I'm running purely from USB, never touching eMMC. What works Armbian_24.5.0_amlogic_s905d_jammy_6.6.28_server_2024.04.25.img (ophub build) Flashed to USB with balenaEtcher Plugged into the box, powered on Boots directly with no modifications — no manual u-boot.ext, no dtb edits, no extlinux changes Network, IR, HDMI all good What doesn't work Armbian_community_26.2.0-trunk.821_Aml-s9xx-box_resolute_current_6.18.26.img (official community build) I tried the following on this image, in order: As-is flash to USB → stuck at the Android boot logo, never proceeds. Generated/copied u-boot.ext for S905D into the boot partition → still stuck at Android logo. Selected meson-gxl-s905d-phicomm-n1.dtb as the FDT (this is the dtb that the working 24.5.0 image uses). Edited /boot/extlinux/extlinux.conf to match the working 24.5.0 image exactly — same kernel/initrd path style, same APPEND line (root=, rootflags, console=, etc.), same FDT pointing at meson-gxl-s905d-phicomm-n1.dtb. After all four steps, the 26.2.0 image still won't boot — the box hangs at the Android logo and never hands off to U-Boot/kernel from USB. Question Given that the 24.5.0 ophub S905D server image works out of the box, and the 26.2.0 community Aml-s9xx-box image fails even after replicating the working boot chain (u-boot.ext + N1 dtb + matching extlinux.conf), what else differs between these two images that could prevent USB boot on a stock-Android S905D box? Specifically I'd like to understand: Does the community 26.2.0 / kernel 6.18 image use a different boot script signature (aml_autoscript / s905_autoscript) that the stock Android U-Boot on these boxes won't chain-load? Is there a known incompatibility between kernel 6.18 / the resolute-current package set and the S905D mainline u-boot used by the 24.5.0 build? Is the official "Aml-s9xx-box" community image even intended to boot on locked Android TV boxes from USB, or is it built only for boards that already run mainline u-boot from eMMC? Any pointers appreciated. Happy to attach a serial console log if someone can suggest where in the boot chain to look. Thanks! extlinux.conf uEnv.txt