bedna

First of all, spamming balance on an SSD will significantly lower the lifespan of it. What you do is ask btrfs to relocate data-chunks that are occupying the % of a block, so that 1 goes fast is because they are very small (1%), but when you ask it to scan and look for a position to move chunks that occupy +50% it WILL take a long time, a veeeeery long time, not to mention 95%. You are basically just moving around data slowly killing your SSD. Read here: https://btrfs.readthedocs.io/en/latest/Balance.html#compact-under-used-chunks Btrfs will do this automatically in the background constantly when your computer is having extra cycles to do so. The only time it will be useful is if you remove massive amounts of data, then you can notice neither data nor metadata freeing up space. It can also be useful if you are using RAID because then it can move data between the disks. IIRC -susage is irrelevant for most users, what you want to move is the data and metadata, ie -musage & -dusage. If ever run a balance, it's when I remove big, and I mean BIG chunks of data, like 25% of the drive, and when I do, I start with 5, increment by 5 up to 35, NEVER more. But it is ONLY if I actually need the space immediately for something else, otherwise I just wait and let btrfs handle it by itself. So, with what you are doing with your cron running every day is literally killing your ssd... You should probably stop, IMMEDIATELY. With a --full-balance, you rewrite ALL DATA on the ENTIRE DRIVE! Better to have a scrub running once per month or every second week or so to know that your drive is in healthy condition... So what you are experiencing is not a bug, it's how it works, and in worst case scenario it might be your ssd about to give up... This link, albeit reddit describes it pretty good: https://www.reddit.com/r/btrfs/comments/hfpot9/what_does_balance_actually_balance BTW, you can check what it is doing while running by typing: sudo watch -n1 'btrfs balance status /path' But again, I HIGHLY discourage you do balance unless you ABSOLUTELY need to. Edit I missed that the filesystem has become read only when responding to this at 4am so lets edit this with a bit more info. Well, I'm sorry, it looks like you killed your drive, or at least the filesystem. The best you can do is try to copy all files on it to another drive (probably not worth trying to save the filesystem), format this one and pray that it's only your filesystem that became corrupt. But after reading how you treated that drive I think you should be prepared for it being damaged beyond a reformat, or that if you manage to format it, it will become corrupted pretty soon again, so I would not rely on that drive for backups... I have found SMART to not be reliable when it comes to health. If you like btrfs, I would recommend buying a rpi, a 6TB spinning drive, a hd case and run urbackup on that. That is what I use (rpi4 8gb, which is overkill, it never utilizes more than 2-3G memory on it, even though I use it as a backup server, nfs network drive AND is running a plex server on it) and it has been running flawlessly for years. (that reminds me, I might want to install something newer than rpi os bullseye on it, maybe armbian xD) I only make file backups, no images. Not very fast, but what does that matter when you only use it for backups. (I run the NFS network drive from another storage device, but that is beside the point) If you also use btrfs on the system you backup from, it creates a snapshot at runtime that it transfers files from, so there is no risk of corrupting files while the backup is running due to files changing during the backup. You would probably get all that for the same price as one ssd, or at least close to, spinning dives cost close to nothing. I have 5 clients connected to that backup solution, with 4 backups daily saved for about 2,5 months (one backup every 5hrs and backups paused between 3am-7am), and one archived every month to save for three years. ie 240 incremental backups per device. One of the clients backing up 1.13T (the others are smaller, between 100-350G each) but all of it only taking up about 5.5TB, and backups runs fast af, only copying changed data due btrfs and de-duplication (COW). I have NEVER had to run a balance on that device (only done it once before for testing). But since it is getting close to the threshold, let's make an experiment and run a balance on it with chunks up to 30%. There are 987 snapshots on that device (not all 5 clients has reached 240 backups due to not being constantly turned on, my laptop and my installed "fallback" os for example) $ sudo btrfs subvol list /media/backup | wc -l 987 This is before balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B The balance up to 20% took about 5 seconds, then on 25 and 30 it took a while, about 10 minutes (I forgot to run it with time so this is an estimate with me looking at the clock when starting and when saw it had it ended) It only moved a minimum amount of chunks $ sudo bin/btrfs-balance.sh --backup If balancing takes a long time, open another terminal and run: sudo watch -n1 'btrfs balance status /path' btrfs balance will run on /media/backup Do you want to continue? [y/n] y Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=5 SYSTEM (flags 0x2): balancing, usage=5 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=5 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=10 SYSTEM (flags 0x2): balancing, usage=10 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=10 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=15 SYSTEM (flags 0x2): balancing, usage=15 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=15 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=20 SYSTEM (flags 0x2): balancing, usage=20 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=20 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=25 SYSTEM (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks This is after balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B As you can see, no change whatsoever because btrfs does this in the background all by itself. And running higher % would not save any space, only take a ton of time, I'm pretty sure of that. If you want the script I used, here you go: (I have two btrfs filesystems on that rpi, modify to your liking if adopting) !/usr/bin/env bash # Check if script is run as root if [ "$EUID" != 0 ]; then echo 'THIS SCRIPT MUST BE RUN AS ROOT! (WITH SUDO)' exit 1 fi if [ "$1" == '--backup' ]; then METHOD='/media/backup' elif [ "$1" == '--usr' ]; then METHOD='/media/usr' else METHOD='all' fi echo 'If balancing takes a long time, open another terminal and run:' echo -e "sudo watch -n1 'btrfs balance status /path'\n" echo "btrfs balance will run on $METHOD" read -p "Do you want to continue? [y/n] " -n 1 -r if ! [[ "$REPLY" =~ ^[Yy]$ ]]; then echo '' echo 'Aborting...' exit 4 fi echo '' if [ "$METHOD" == '/media/usr' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/usr btrfs balance start -v -dusage=5 /media/usr btrfs balance start -v -musage=10 /media/usr btrfs balance start -v -dusage=10 /media/usr btrfs balance start -v -musage=15 /media/usr btrfs balance start -v -dusage=15 /media/usr btrfs balance start -v -musage=20 /media/usr btrfs balance start -v -dusage=20 /media/usr btrfs balance start -v -musage=25 /media/usr btrfs balance start -v -dusage=25 /media/usr btrfs balance start -v -musage=30 /media/usr btrfs balance start -v -dusage=30 /media/usr btrfs balance start -v -musage=35 /media/usr btrfs balance start -v -dusage=35 /media/usr fi if [ "$METHOD" == '/media/backup' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/backup btrfs balance start -v -dusage=5 /media/backup btrfs balance start -v -musage=10 /media/backup btrfs balance start -v -dusage=10 /media/backup btrfs balance start -v -musage=15 /media/backup btrfs balance start -v -dusage=15 /media/backup btrfs balance start -v -musage=20 /media/backup btrfs balance start -v -dusage=20 /media/backup btrfs balance start -v -musage=25 /media/backup btrfs balance start -v -dusage=25 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup fi exit 0 This probably means I should manually remove some snapshots, because I did make a few massive changes that caused a lot of new data to be created, I do NOT want it to become filled. Conclusion: Don't run btrfs balance unless absolutely necessary, especially on SSD:s!

I assume you are talking about local connection here, not from the internet, so it's ngiinx webserver you are talking about, not nginx-reverse-proxy? Can you at least ping the ip of the server? Syncing apps might not connect over http or https (or rather, they probably don't), which your browser does. Are you sure letsencrypt works properly and it's not just your browsers refusing to connect over https due to missing/miss-configured ssl certificates? Does forcing http connection at least give you some response? As for using wget to test: "wget --spider <url>" should get you some info. It should look something like this for correct setup using https: (enter url without http or https, I have redacted url and ip for obvious privacy reasons) $ wget --spider <your_url_here> Prepended http:// to '<redacted>' URL transformed to HTTPS due to an HSTS policy Spider mode enabled. Check if remote file exists. --2026-05-23 14:48:27-- https://<redacted> Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving <redacted> (<redacted>)... xxx.xxx.xxx.xxx Connecting to <redacted> (<redacted>)|xxx.xxx.xxx.xxx|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 0 Remote file exists and could contain further links, but recursion is disabled -- not retrieving. But as eselarm said above, we need way more information to be able to help.

For mate IIRC they use gnome's gnome-language-selector (start it in a terminal if you are missing the icon in settings), but it was a while since I used that desktop-env so I could be wrong. My old notes says the setting should be in: System > Control Center > Language Support For your information (as a fellow Swedish person): there is a locale called en_DK.UTF-8 that you might want to use instead. That way you get the correct settings for Scandinavian (like date/clock format for example) but the language is English. Or you can probably do it in terminal altogether: sudo dpkg-reconfigure locales # select en_DK.UTF-8 here, or whatever locale you want to use, I will use the dk version in this example localectl set-locale LANG=en_DK.UTF-8 sed -i "s/sv_SE/en_DK/" ~/.dmrc

Really? You changed the network config, installed a massive application AND enabled apparmor in the same boot... Cmon dude... It probably does, if you don't also change the network.

Ok, just wanted to know if you used the flatpak since they indicate on their wiki that could be troublesome. When you say "none of them can start automatically", what methods did you use to configure autostart? As they state at the top of the wiki/setup: "Distribution may provides some specific tool for autostart Fcitx and usually also set up environment variable together." Take notice of the word MAY. Seems Armbian does not. So what does im-config do as described on the next line after that on the wiki page? Does it fail or give you some hints of why autostart is not working? https://fcitx-im.org/wiki/Special:MyLanguage/Setup_Fcitx_5#im-config_(Debian/Debian-based/Ubuntu) This question is more fitting to ask the devs of the application, not the operating system. If you have problems with an application on windows for example, you generally don't ask microsoft for help but rather the developers of the application. But if you provide good enough information, we might be able to help you figure it out on this forum...

More information is needed. What armbian release do you use? How did you install fcitx5? Have you followed the instructions on their wiki? https://fcitx-im.org/wiki/Special:MyLanguage/Setup_Fcitx_5 Or read the FAQ? https://fcitx-im.org/wiki/Special:MyLanguage/FAQ Are you using a chromium based browser?

Are you using the rolling release? Otherwise you should not use "full-upgrade" but rather just "upgrade". Not saying that is the reason for missing deps, but it definitely could be.

@Giunti & @samlevy0515 It would be helpful to the community if you responded to the developer trying to fix this issue rather than state a workaround. Thank you.

(I am not part of Armbian other than the community, and have donated money, so I feel no obligation to be "professional") Ok, if you want to act like a clown, I'll treat you like a clown: Don't click unknown links, don't download unknown scripts or applications and you are fine. You know, use common sense. I'm sorry you feel "wronged" by this free and open source project because it doesn't focus the tiny amount of assets they have to manually remove something that pretty much is a nothing burger (and will be solved in the next update), unless you make yourself vulnerable by infecting yourself with with an RCE malware/virus or give physical access to people you can't trust. If you think making a text on their website would "protect" people, when this exploit has been mentioned by more or less every single linux outlet in existence, I don't know what to say. You are not doing this to "protect others", you do it for ego reasons. (Sorry mods, I won't respond more with the risk of starting a war, but if being mentioned in the way op did, I WILL defend myself.) Also, a link about Dirty Frag: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html Mitigation:

This, even though serious, it's "only" a privilege escalation, not remote code execution (RCE), so if someone were to use this on you, they would first need to have physical access OR access remotely (RCE) to be able to run the exploit and escalate to root. And if you have a malware with RCE, you are already f**ed. In time, I'm pretty sure upstream patches will spread down to armbian builds too. In the meantime if you think someone might be able to get access and escalate, you can disable algif_aead (or try to apply patches yourself) as mentioned in https://xint.io/blog/copy-fail-linux-distributions Another solution is for you to pay a developer to do changes/testing needed If you don't "demand more labor", then why are you requesting more labor? (don't answer, it's a rhetorical question)

He meant this forum-post was moved to "staging". Maybe someone in the community will be able to help. (I can't help much with your problem, only explain what he meant with the post) Try what yourself suggested, run fsck from another system and see. But if a filesystem becomes readonly, it can mean that the drive is starting to fail physically.

"mmc1(part 0) is current device". Is that really a usb? Never seen a usb be named that, sound more like an internal storage.

I see. I actually tried to educate myself to see if I could help out, that is why I extracted the code in the first place. I would love to be able to help, but it seems outside of my capabilities. But I'll keep reading trying to learn, and maybe some day I will be able to make a pr rather than just a post on the forum. Thank you AGAIN for ALL you do!!

Maybe you already know, but to be sure (you guys are most likely always swamped), the keyrings workflow has failed the last two runs with the same error, on April 8 & April 15... https://github.com/armbian/armbian.github.io/actions/workflows/generate-keyring-data.yaml ERROR: Unable to find debian-archive-keyring package URL from https://packages.debian.org/sid/all/debian-archive-keyring/download Thanks for all you do! Edit With the limited understanding I have of this, I extracted relevant code and just ran a check on my local machine, and it returned: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3012 100 3012 0 0 509 0 00:05 00:05 509 Debian debian-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2025.1_all.deb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3021 100 3021 0 0 532 0 00:05 00:05 532 Debian debian-ports-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2026.02.04_all.deb (the reason it took 5s was due to the time it took me to press "allow" on the outgoing curl connection in my firewall) So maybe it was just a fluke, and it was just really unlucky failing resolving to packages.debian.org instead of ftp.debian.org those two times. Idk, just wanted to make sure everything was correctly configured. Ignore this if all is ok.

@MMGen First, thanks for a great tutorial! I have a question about gpt. I maintain shrink-backup and I use dd to copy "boot sector" and rsync the rest (VERY easily described) But I do not distinguish any difference between if it's mbr or gpt when using dd, I just copy everything before root partition with dd (and a few MiB extra) then format root, rsync, yadayadayada... (not important) So I got curious why you skip the first 64 512b blocks in the dd for gpt? (for others reading, the 512 is because fdisk ALWAYS returns 512b blocks, even though gpt is actually 4k blocks) dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704 Can you explain why? I tried to find something online referencing the first 64 512b blocks of a gpt partition table, but could not find anything. I would really appreciate you educating me, or some links where I can read up on the reason. Thank you!

It's most likely a local ipv6 op is talking about, not a public. ipv6 in range fe80::/10 is local only. To remove ipv6 in that regard, ipv6 has to be disabled on the device or it will get an address like that. And according to what is provided: 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether be:63:9c:35:dd:4f brd ff:ff:ff:ff:ff:ff inet 192.168.71.2/24 brd 192.168.71.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::bc63:9cff:fe35:dd4f/64 scope link valid_lft forever preferred_lft forever Today I learned a bit more about systemd-resolved, seems 127.0.0.53 IS the correct config for systemd-resolved: https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53 And: If dhcp server is configured correctly, nothing has to be done on the devices (except resolving domains to local ip unless that is done on the LAN by dnsmasq)

I'm sorry but, lmao, this is entertaining to read. The sd card is OBVIOUSLY corrupt, it even TELLS YOU THAT in what you posted. It's probably a good idea to go back to the basics and learn linux properly if you don't know what a msdos (MBR) partition table is. https://unix.stackexchange.com/questions/289389/what-are-the-differences-between-the-various-partition-tables As for how to NORMALLY SETUP A NETWORK, you can read my earlier responses, no host files on the devices, no hardcoded ip, just a correctly configured dhcp server that delivers the CORRECT IP:s to all devices. Then the dns server on the network (dnsmaq in this case) resolves desired domains to local ip:s. That way, there is NO NEED to do ANY CONFIG on the devices, it is all done on the entire network.

You are telling me to forget the thing I suspect is the reason for the network not working correctly...? If it is "working perfectly", why does it not resolve addresses from the bpi? Why is your bpi setting 127.0.0.53 (witch would be incorrect even if you ran a dns server ON that device, it should then be 127.0.0.1 (or the device ip), potentially at port 53 but IIRC, port 53 IS dns requests and where it will go without defining it) as dns server and not 192.168.71.1? There you go, there is another culprit. If writing 4k in each iteration fails, but 512 works, 99,99% chance the reason is the sd card is starting to completely fail. Armbian imager would have told you verification failed when verifying the image after writing it, there is zero verification when using dd. There should be no issue writing 4096 bytes (4k) each iteration with dd on a functioning sd-card. Seems you are more interested in screaming and complaining than actually getting to the bottom of it all and set it up like a NORMAL network where NOTHING has to be done on the devices because the settings will be configured correctly with the dhcp lease. Btw, here is the dev documentation for armbian imager (and the source code ofc), took me 30 seconds to find... https://github.com/armbian/imager/blob/main/DEVELOPMENT.md Not sure what useful things you expect to find in there that is not mentioned in the help. It writes an image and does verification of that image (and you can download images), that's it. Good luck I guess, I have nothing further to add.

Does it? Does not look like 192.168.71.1 to me... And: That is not correct, that is the global scope, no ip can end with 0. Ehhh... What do you call dnsmasq on your router then?!? If you don't "maintain" that, yes, things like this can happen, especially since you have set the leases to never expire. I have no idea if this is the case, it's for YOU as sysadmin of your network to know. Nobody knows what you did after install. All that is known after all things written in this thread: You have a dhcp server you have a dns server (dnsmasq) you installed Armbian_26.2.1_Bananapim5_noble_current_6.18.15_xfce_desktop.img (that comes with network manager according to documentation) It seems you have systemd-networkd enabled Unless you can prove the default config was with both systemd AND network manager, YOU have made changes that breaks the installation. Nobody can answer what you did, only you. The normal way if having a local dns server (even if it ONLY forwards request to outside dns server) is to configure the resolving for local domains in the dns server and not touch it at device level. For example a consumer grade router, it will set dns to router ip in the dhcp lease and when requests come in, resolve with asking your ISP dns servers. Hence, if looking up what dns server is used on the devices, they will NOT point to your ISP dns servers (or google or cloudflare etc), it will point to your router ip. Lets say you have a pihole on your network that acts as dns server, then you configure the router (dhcp server) to point to THAT ip for dns, hence, the dhcp lease will deliver THAT ip. And then you configure the pihole to resolve local ip:s and what outside dns servers to use. The DEVICES will ONLY see the local ip where the pihole lives in this situation. Resolving domains to local ip:s (/etc/hosts on your device) has nothing to do with your dns detection failing. This is all pretty basic networking... Edit For reference, this is what your /etc/resolve.conf should look like (or similar) if you configure your dhcp server to point at the ip where dnsmaq lives (same ip as the router itself) then propagate those settings via the dhcp lease. Then nothing has to be done on any device except for resolving local ip:s if you refuse to do that with dnsmasq. If you configure dnsmasq to do that, resolving will be done on the router instead of the devices and absolutely nothing has to be done on any device. With systemd: # Generated by resolvconf domain home nameserver 192.168.71.1 With network manager: # Generated by NetworkManager search home nameserver 192.168.71.1 If you don't want to reinstall again, make sure systemd network services are disabled and network manager is enabled and then reboot. But be mindfull you might need physical access if network completely fails at boot. IIRC relevant services are (I could be wrong here, you should read up on documentation) systemd_networkd.service, systemd_resolved.service & networkmanager.service I'm in the middle of moving, so I only have an arch desktop and laptop up and running at the moment, so I can not confirm on any armbian installation that I provide 100% accurate information.

That is supposed to be using network manager, again, see documentation Your question was about networking. How to configure your raid is a completely different question and has nothing to do with network. Since both systemd-networkd AND network manager (and you also mention dnsmasq) is enabled, you have most likely done changes to the system way outside of what you should. If you claim the image you downloaded CAME with all that installed and enabled by default, I would suggest you provide proof of that and then report back as a bug. As for your general network setup, I gave you my opinion earlier: Not on every specific device if there is a local dns server available on the network. Then it's normally done on the local dns itself by first checking local configs (like /etc/hosts) and if not available, resolve using online dns servers and then send the response to the device. And the dhcp server is obv configured to point to the local dns server. That way the configs gets propagated via the dhcp lease to all devices on the network.

If you want to use network manager you have to make sure systemd is not overriding your configs, ie disable relevant systemd services. To me, it sounds easier to just use what is installed default, in this case systemd and use networkctl to interact. But it should be irrelevant. If you configure your dhcp server and dns server correctly, both systemd and network manager should pick up correct config in default config state so you should not even have to interact with either of them. (I started assuming you are using a minimal image, therefore systemd as default. You haven't disclosed what version you use, just something 26.3)

Either the config on the device is wrong, there is supposed to be a dns ON the device or the dhcp server is handing out wrong dns to the device. Not on every specific device if there is a local dns server available on the network. Then it's normally done on the local dns itself by first checking local configs (like /etc/hosts) and if not available, resolve using online dns servers and then send the response to the device. And the dhcp server is obv configured to point to the local dns server. That way the configs gets propagated via the dhcp lease to all devices on the network. Edit As far as I know, network manager is default on armbian (correct me if I'm wrong) and that should have edited your /etc/resolv.conf. So since it's not, you have made changes outside of default config somehow. Could be that the specific release and device you use does not utilize network manager. But since you have not disclosed that info, hard to know. But it looks like you use systemd-resolved so you should check how that works. Edit2 I was wrong about network manager, see https://docs.armbian.com/User-Guide_Networking/

I repeat, what is in your /etc/resolv.conf?

What's in your /etc/resolv.conf? And what do you mean with "dhcp isn't working"? Is 192.168.71.2 not the correct ip? Where is your dhcp? Your router?

I haven't used samba for a long time so I'm probably not the best to ask, but I checked my old notes about samba, and this was my goto config: [samba] # edit, or whatever name you want to give it path = /path/to/mountlocation/ browsable = yes writable = yes read only = no force user = <your_username> force group = <your_usergroup> create mask = 0644 # edit, you should probably set this to 0640. This is for files, no need for 7 here, unless you want every file to be executable on the samba share? direcotry mask = 0755 # make sure this works on debian, errors on arch (edit, this was in my notes, so I guess 755 instead of 0755.. maybe.. Or rather 0750 or 750 to only give access to your user and group) public = no This was the only thing I changed from default IIRC, so no guest access or anything, just a uname and passwd to connect. Changing the directory permissions on the server filesystem (chmod) does not matter at all when it comes to samba. As you can see in the conf I provided, the mask is defined there, and all files will get that user/mask (if ext4, exfat does not support user/group/all masks, what you see in your filesystem is what you set in fstab for exfat) and is the mask you will se when looking through a samba mount on another computer. And as a rule of thumb, don't use 777 or 666, the solution is very rarely to completely open up everything, that's a "windows thing" (run as administrator or give everybody access to the directory/application), try to get rid of that habit.