bedna

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.

Samba has one gazillion options, you can read about all of them here: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html You can read the wiki with examples here: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Standalone_Server I would NOT use a samba server without a password.

Also: # apt install -y iptables # iptables -v iptables v1.8.11 (nftables): no command specified https://wiki.debian.org/nftables AFAIK using iptables syntax should still work, but nft is what you probably should learn to use instead. https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

It really is as simple as possible on Armbian. Pretty good documentation too, I posted it before, but here you go again: https://docs.armbian.com/ All you have to do is to login as root from an ssh client following standards. I do not have access to a windows installation where I can confirm if what you say is true, that the ssh client does not let you login with "ssh root@xxx.xxx.xxx.xxx", so maybe you are correct, but it sounds very unlikely to me. But what I can guarantee is using an ssh client from another unix system will definitely let you connect. So use a mac or a linux computer to access. Or install wsl on windows and do it from there. https://learn.microsoft.com/en-us/windows/wsl/install Edit: I actually forgot, but I had putty installed on my system. I used it to check colors in a script I maintain and it exists in the extras repo on arch. Downloaded latest minimal image for rpi (so not same hardware as you) and... No settings changed in putty, just a standard root@192.168.99.60 that I added into the "Host Name (or IP address)" field and clicked "open". Name : putty Version : 0.83-1 So I don't know what to tell you...

"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 -vv root@xyz" Let's try again, but this will be my last time typing this: The normal way to use ssh, is to type: "ssh user@xxx.xxx.xxx.xxx" where x is the ip number. So for Armbian first login, it's "ssh root@xxx.xxx.xxx.xxx", NOTHING ELSE. Just glancing at the few first lines in that log: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2 debug2: resolve_canonicalize: hostname xyz is address debug1: Connecting to xyz [xyz] port 22. debug1: Connection established. debug1: identity file C:\\Users\\sebas/.ssh/id_rsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_rsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519 type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.0 debug1: compat_banner: match: OpenSSH_6.6.0 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to xyz:22 as 'root' debug1: load_hostkeys: fopen C:\\Users\\sebas/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory As I suspected, it looks like it is somehow trying to use keys and whatnot. Since you refuse to listen, yeah, this might be frustrating and "bad for morale". If you instead listen and do what is suggested, your morale would likely not suffer at all.

Stop providing false information, I disproved your theory earlier, please stop. On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian. This works, and is the way I have ALWAYS done it on Armbian, for years. Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234." If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

Might be because at first login, you enter 1234, it then asks for you to change that, create a user and whatnot. Not so sure putty will have any idea of what to do with those prompts. When you wrote: "once more: tried ssh through a raspi in the network. the raspi cannot connect to the armbian:" What do you mean by that? You logged in to a rpi OS with putty, and you then tried to connect to this device via the rpi? Was this before or AFTER you already tried logging in to it using putty? In your log: ### [firstrun] Recreated SSH keys (entropy: 256 256) I don't know what this means, but sounds like keys are enrolled and maybe assumed to be used in future. You will have to look into putty (and ask the devs of putty) to learn what is happening, unless you are willing to use a "normal" ssh client that will tell you what is going on by providing STDOUT & STDERR to your monitor. With a NORMAL ssh client, type "ssh root@xxx.xxx.xxx.xxx" (the ip to the device) and it will ask for passw, it will then require you to CHANGE passwd etc. Seems very likely putty has no idea how to deal with that and are doing some strange things at first login, witch then probably leads to it borking your system.

Unless they have changed something very recently, you can login as root via ssh on first-run. I double checked /etc/ssh/sshd_config on an armbian install image I had downloaded, and: # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes <snip> # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no And inside /etc/shadow (default 1234 passwd): root:$y$j9T$SAPCtO/l2ZIj6A2frqTza/$.Z8dP41gzqRHoIS8PvXFn9fghf9rgkGqAWgXVRW4dg6:20234:0:99999:7::: Edit. That can be verified: export PASS=1234 SALT='$y$j9T$SAPCtO/l2ZIj6A2frqTza/$' && perl -le 'print crypt($ENV{PASS}, $ENV{SALT})' # the output verifies the shadow file is correctly setup for passwd 1234 $y$j9T$SAPCtO/l2ZIj6A2frqTza/$.Z8dP41gzqRHoIS8PvXFn9fghf9rgkGqAWgXVRW4dg6 End edit. So that should not be an issue here. (and there are keys inside /etc/ssh that I assume can be used at first login, I have never tried) Sounds more like a faulty sd-card that gets mounted read-only, that can cause stuff like this happening. (as mentioned earlier by Igor) Try with a different sd-card (and use armbian-imager instead of balena) and see if the same happens on another card.

Yeah, don't do that.. At least read "<application> --help" before doing sensitive stuff like that if you are unfamiliar. If that happened to you, and that is the reason you typed that.. For future reference: If you have a root account, you can change to root user with "su root" and enter passwd. You are then root and can add your user back to the groups needed. Or you can use the debian "child safe" way, "adduser <user> <group>" (only works on already existing users and groups) instead of usermod to begin with. But best is you learn usermod, since that will let you utilize that knowledge on pretty much any unix system.

Tried this? https://gist.github.com/c0m4r/b3fea6342bcf5a1b25b608fc36100d68#pwm-fan-control Ie: download the script and systemd service, edit the script to your liking (or try default) and activate the service. As default It configures to user_space and checks temps every 10s. https://raw.githubusercontent.com/c0m4r/radxa_rock5c_lite/refs/heads/main/usr/local/bin/rock5c_fan_pwm ########################################################## # Radxa Rock 5C fan PWM control script # Author: https:///github.com/c0m4r # License: Public Domain ########################################################## # PWM control path PWM_PATH="/sys/devices/platform/pwm-fan/hwmon" # Configuration INTERVAL=10 # Temperature check interval (seconds) FAN_OFF=1 # 1 = turn off fan below MIN_TEMP after cooldown, 0 = keep at min RPM COOLDOWN=300 # time to wait before turning off the fan when FAN_OFF=1 # Critical temp protection POWEROFF_ON_CRIT=1 # 1 = shutdown when the temperature reaches a critical value, 0 = disable CRITICAL_TEMP=70 # Critical temperature (shutdown) # PWM Values (proper) SAFE_PWM_MIN=105 # Safe minimum PWM to keep fan spinning PWM_LOW=125 # 45–50°C (~50% speed) PWM_MID=165 # 50–55°C (~65% speed) PWM_HIGH=200 # 55–60°C (~80% speed) PWM_MAX=255 # >60°C (100% speed) # PWM Values (temporary - use these instead of proper if the fan spins at max all the time) #SAFE_PWM_MIN=50 # Safe minimum PWM to keep fan spinning #PWM_LOW=60 # 45–50°C (~50% speed) #PWM_MID=70 # 50–55°C (~65% speed) #PWM_HIGH=80 # 55–60°C (~80% speed) #PWM_MAX=255 # >60°C (100% speed) # Constants (requires also changes in code) MIN_TEMP=47 # Minimum temperature (PWM_MIN) MAX_TEMP=60 # Maximum temperature (PWM_MAX) # Set thermal policy thermal_zones=$(ls -1 /sys/class/thermal | grep thermal_zone) if [[ "$thermal_zones" ]]; then for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done else echo "No sensors found, check kernel support, setting fan to high for now!" echo $PWM_HIGH > ${PWM_PATH}/hwmon*/pwm1 exit 1 fi # Set PWM_MIN based on FAN_OFF mode if [ "$FAN_OFF" -eq 1 ]; then PWM_MIN=0 # Allow fan to turn off after cooldown else PWM_MIN=$SAFE_PWM_MIN # Keep fan at minimal safe RPM all the time fi # Validate PWM path if [ ! -d "$PWM_PATH" ]; then echo "Error: PWM control file not found: $PWM_PATH" exit 1 fi # Initialize variables current_pwm=$(cat ${PWM_PATH}/hwmon*/pwm1) # Start at current PWM last_high_temp_time=0 # Track last high temp for cooldown echo "Initializing fan at PWM $current_pwm" echo "$current_pwm" > ${PWM_PATH}/hwmon*/pwm1 # Main loop while true; do for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done <snip>

What happens if your start armbian-resize-filesystem.service manually? IE "sudo systemctl start armbian-resize-filesystem.service" and then check the log for the service?

I would use systemd. Depending on what application you are talking about, a simple or oneshot service should do the trick. Read the first two examples in the manual: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Examples Assuming you mean an application started by the system and not your user, select the version that fits your situation, create/edit the file /etc/systemd/system/name_your_service.service with the contents needed, for example: [Unit] Description=Service to start "application" [Service] Type=simple ExecStart=/path/to/application [Install] WantedBy=multi-user.target Then enable the service and reboot. sudo systemctl enable name_your_service.service sudo reboot now You can use "systemctl status name_your_service.service" to see status, or "journalctl -u name_your_service.service" to see logs. You should obv change the name of the service from name_your_service to something fitting. If you want the application to run even earlier at boot, you can change multi-user.target to basic.target instead, but be mindful that if you do that and the application requires for example network to be available, you then also need to add "After=network-online.target". Instead, it's usually better to use "Before" and "After" variables and stay on multi-user.target. Please see manual in link above and https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html for more advanced usage.

LMAO! So... What exactly is your question? Did you try "the mouse & keyboard" and they did not work? I would say you will get basic functionality on almost any usb mouse or keyboard on linux. wifi on the other hand can be a hit or miss. A quick search on "USB Logitech Unifier Nano dongle" gave me this: https://forums.linuxmint.com/viewtopic.php?t=373365 so it seems you might want to use solaar to configure the stuff. As for the Inovato Quadra4K, it looks like it is an allwinner H6 processor so I suspect it should work using armbian....

Best do what? Disable a systemd service? sudo systemctl disable --now systemd-resolved.service https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html

I have experienced something similar in the past and it made me very puzzled until I figured out what was wrong in that situation. Make sure the clock on both systems are synchronized to an NTP server. IIRC SSH just threw a fit exactly like this without logging why, and it turned out to be a security feature where the ssh server suspected the communication to be intercepted by man-in-the-middle due to clocks not being synchronized. And if logging in physically to the system, apt refused to work as-well until clock was synced. Could be worth to check next time... As for dhcp and systemd. Check if systemd-resolved.service is messing something up for you, maybe try to disable it?