To add to this post: Powering off Via SSH and Home Assistant
So my read is the UPS part is irrelevant. What youâre really looking for is the option to shutdown your NAS from HA. Does your NAS not have SSH?
2 Likes
Yes! You got it! Thanks!
My NAS has ssh, the problem seems, as I breefly mentioned, that itâs not possible to ssh login to NAS OS (Terramaster TOS 5.1) without user interaction, thus no automation is possible.
I tried creating:
shell_command:
shutdown_tnas: echo YOURTNAS_ADMIN_PASSWORD | ssh -i /config/ssh/id_rsa -o 'StrictHostKeyChecking=no' -p 9222 admin@YOUR_TNAS_IP sudo -S poweroff
and various modifications of this code using my credentials, but calling shell_command service never worked, giving back login errors in logs. I could replicate the problem and paste the code if needed, but searches made a while ago brought me to someone elseâs conclusion that itâs a TOS security limitation. Further research would be neededâŚ
I also tried to understand how to make HA act as a SNMP server (which should be possible somehow), since TOS should be able to monitor it and react consequently, but I couldnât find anything about such configuration hence a way to make it work either. Also, for this to work, HA should have to be able to change the states of SNMP server entities while running and, again, I donât know if itâs even possible. Again further research would be neededâŚ
Thatâs why I was asking for a direct integration or another, possibly the simplest, way to tell the damn NAS to shut off remotely.
As you correctly stated, in my circumstance UPS has nothing to do with this job, it just has to keep router, NAS and RPi5 (HA) running while the âpower offâ automation is launched by HA and NAS shuts off. Once the job is done and NAS is off, the UPS can quietly die and hopefully resurrect as soon as AC is back, it doesnât matter. Any battery with sufficient juice can do that.
Moreover, creating trigger conditions to eventually lanch a âshutdown NAS service callâ within an automation is easy indeed on HA. I can monitor any plug, switch, light etc. connected to HA to tell that my home main power supply is gone, so, in my ignorant opinion, thereâs no need for a smart UPS. Literally everything controlled by HA thatâs not under UPS (and that then goes off as soon as AC goes off) can be monitored for this purpose directly by HA.
So what I actually need and asked for since the beginning (my english must have rot lately) is: once power has gone, HA red that all conditions were met (different devices unavailables), and triggered the automation I wrote to protect fragile devices such as NAS, what kind of service, if existing, can lauch a Power off signal to NAS without using ssh?
I think this is the best explanation I can give, so
thanks everyone for help,
but a lot more thanks to you and to those who took time to read and understand.
P.s. Sorry for late reply, I couldnât post more than 5 in few hours since itâs my first day.
P.p.s. building a mechanical finger to physically push the power button on command would require way more than just further research for me and probably cost more than a compatible network APC, so this solution wonât be considered untill further research tells Iâm wrong.
This is something that could turn out to be useful, but I wouldnât know how since itâs just reading TOS sensors, no active interaction is involved. Maybe someone more skilled than me could know something more
The phisical finger statement let me think about a device that i know as âfinger botâ, but i donât know if its true name. 
There are many versions, wifi or zigbee, and you can create a custom padding with some plaster if the gap between the actuator and NAS power button is too wide.
However, i suggest to leave the SNMP server idea and focus on Terramaster OS. The link i poste previously state that IS possible to connect giĂ SSH the NAS. Note that the procedure is different for TOS 5. Please ala check if SSH should be enabled from the TOS management interface.
I suggest you do some test from your pc and when youâll find the correct login procedure, you can configure SSHD on the NAS to accept connection without password from a pc that provide a know public key (so called âSSH key based authâ), and even istruct âsudoâ command to perform the âpoweroffâ without a password. But all of this is âadvancedâ Unix stuff, not an Homeassistant problem. Donât mean to be rude, my apologize in advance.
Federico
1 Like
Tried that, as I said, it didnât work. TOS 5.1 apearently wonât let me automatically login. I regularly use linux ssh on different systems and I thought that would have made things easier. Sure enough I can ssh login from ubuntu terminal to TOS cli and act sudo as much as I want, but I cannot create a service to shut it down automatically.
Iâd like to keep autentication on since the system is partly exposed to the web.
I didnât know about finger-bots, but they actually exist. If noone finds a software solution, you got it.
Thanks
Basically create a script on pi that ssh into server and shuts it down. Run script from an automation. Sounds like you also need to add device to monitor power that works with HA
Do you mean like this?
shell_command:
shutdown_tnas: echo YOURTNAS_ADMIN_PASSWORD | ssh -i /config/ssh/id_rsa -o 'StrictHostKeyChecking=no' -p 9222 admin@YOUR_TNAS_IP sudo -S poweroff
or another method?
1 Like
Ahhh but this is wonderful. If you can login you can configure ssh key login only for root. Take a look at this https://www.sectigo.com/resource-library/what-is-an-ssh-key to better understand how it work.
If you can enable key login for root user, than you can achive your result. If you canât do that for root, you can try with the âadminâ account and configure âsudoâ to accept the poweroff command without asking for the password.
How to Run sudo Without Password
Federico
Thanks for your help! I must say I already gave keys a try, but I followed poor non specific instructions and that could be the reason it didnât work. Your instructions are surely more accurate. As soon as I can Iâll study them and try again.
Thank you so much!
Edit: after the first excitement, I found out and remembered why it didnât work, and thatâs because TOS appearently only accepts username and password ssh login.
Sorry, thanks for the effort and forgive me, I tried so many times in so many different ways I cannot recall them all toghether.
Would you mind posting the output the connection to the NAS using âssh -vvv user@ipâ?
Federico
Yes, but I have to edit config.yaml and restart, but I just started HA back up and update and I have to sleep few hoursâŚ
As soon as I can Iâll set up what needed and send you logs.
Thank you very much!!!
You can do it from your PC. The thing Iâm looking for is indipendent from the source. Basically, when you start a new connection, ssh client and server must exchange various information, since they had to find common set of parameters before estahlishing the connection. During this phase (handshake) the server will print all the accepted login method. And also will do the client, print the list of proposed login method.
Not sure if this should be done as root user
I would normally create a user and give it proper system permissions. Not sure if it ultimately matters and maybe itâs the same in the end.
Yes
I donât think it was that. I think a lot of folks got hooked on the title of the thread and the direct request to have HA send the same single an UPS normally would. From there, everyoneâs recommendation focused on those things.
This is a good example of the XY problem.
Reading through this, are you sure that your account is the first one that was setup?
I saw that too crawling the Terramaster forums but i donât understand why theyâre trying to use password AND RSA authentication. Iâm wagering this person setup the NAS for RSA auth and werenât actually using username/password.
1 Like
As a general rule, you are right. But ssh key login is far more secure than password login. You canât âguessâ the ssh key, but you can brute force the password if you chose a poor one.
Didnât know about that, but if fit perfectly. Also only after a lot of message the OP clarified that he ACTUALLY CAN do interactive SSH login in the NAS.
But if he can use SSH, then⌠In Italy we would say âsiamo a cavalloâ!
Thatâs why i asked for âssh -vvvâ. To be able to check what the server is accepting and then understand what to do to help him.
Federico
2 Likes
I have 2 of the latter with one currently dedicated to my HDMI switch connected to my top monitor to allow change of input between my PC and a wireless HDMI adapter I use when working on machines.
1 Like
Thank you all guys, sadly theese are rush days.
This is what I get when ssh connecting from Ubuntu to NAS:
ssh -vvv -p 9222 [email protected]
OpenSSH_8.9p1 Ubuntu-3ubuntu0.7, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.224 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/laptop/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/laptop/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.224 [192.168.1.224] port 9222.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/laptop/.ssh/id_rsa type -1
debug1: identity file /home/laptop/.ssh/id_rsa-cert type -1
debug1: identity file /home/laptop/.ssh/id_ecdsa type -1
debug1: identity file /home/laptop/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/laptop/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/laptop/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/laptop/.ssh/id_ed25519 type -1
debug1: identity file /home/laptop/.ssh/id_ed25519-cert type -1
debug1: identity file /home/laptop/.ssh/id_ed25519_sk type -1
debug1: identity file /home/laptop/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/laptop/.ssh/id_xmss type -1
debug1: identity file /home/laptop/.ssh/id_xmss-cert type -1
debug1: identity file /home/laptop/.ssh/id_dsa type -1
debug1: identity file /home/laptop/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8
debug1: compat_banner: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.224:9222 as 'Master'
debug3: put_host_port: [192.168.1.224]:9222
debug3: record_hostkey: found key type ED25519 in file /home/laptop/.ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file /home/laptop/.ssh/known_hosts:2
debug3: load_hostkeys_file: loaded 2 keys from [192.168.1.224]:9222
debug1: load_hostkeys: fopen /home/laptop/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type [email protected], using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,[email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,[email protected]
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:3LknRVnek9ZtMZUTuLK53BbIKg08t8S9pTgx/3/jYS4
debug3: put_host_port: [192.168.1.224]:9222
debug3: put_host_port: [192.168.1.224]:9222
debug3: record_hostkey: found key type ED25519 in file /home/laptop/.ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file /home/laptop/.ssh/known_hosts:2
debug3: load_hostkeys_file: loaded 2 keys from [192.168.1.224]:9222
debug1: load_hostkeys: fopen /home/laptop/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[192.168.1.224]:9222' is known and matches the ED25519 host key.
debug1: Found key in /home/laptop/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: ssh_set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: ssh_set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /home/laptop/.ssh/id_rsa
debug1: Will attempt key: /home/laptop/.ssh/id_ecdsa
debug1: Will attempt key: /home/laptop/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/laptop/.ssh/id_ed25519
debug1: Will attempt key: /home/laptop/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/laptop/.ssh/id_xmss
debug1: Will attempt key: /home/laptop/.ssh/id_dsa
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/laptop/.ssh/id_rsa
debug3: no such identity: /home/laptop/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_ecdsa
debug3: no such identity: /home/laptop/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_ecdsa_sk
debug3: no such identity: /home/laptop/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_ed25519
debug3: no such identity: /home/laptop/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_ed25519_sk
debug3: no such identity: /home/laptop/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_xmss
debug3: no such identity: /home/laptop/.ssh/id_xmss: No such file or directory
debug1: Trying private key: /home/laptop/.ssh/id_dsa
debug3: no such identity: /home/laptop/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req: entering
debug2: input_userauth_info_req: num_prompts 1
([email protected]) Password:
Mypassword
debug3: send packet: type 61
debug3: receive packet: type 60
debug2: input_userauth_info_req: entering
debug2: input_userauth_info_req: num_prompts 0
debug3: send packet: type 61
debug3: receive packet: type 52
Authenticated to 192.168.1.224 ([192.168.1.224]:9222) using "keyboard-interactive".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: client_input_hostkeys: received RSA key SHA256:QNf3wms0d7XOEcN+bJpWVcikTEk95p18tzFQK0T3YB8
debug3: client_input_hostkeys: received ECDSA key SHA256:JooC125yf6R60ywOtfxfJ0qmsK0a/LDfzKPIv9swu7o
debug3: client_input_hostkeys: received ED25519 key SHA256:3LknRVnek9ZtMZUTuLK53BbIKg08t8S9pTgx/3/jYS4
debug3: put_host_port: [192.168.1.224]:9222
debug1: client_input_hostkeys: searching /home/laptop/.ssh/known_hosts for [192.168.1.224]:9222 / (none)
debug3: hostkeys_foreach: reading file "/home/laptop/.ssh/known_hosts"
debug3: hostkeys_find: found ssh-ed25519 key at /home/laptop/.ssh/known_hosts:1
debug3: hostkeys_find: found ecdsa-sha2-nistp256 key at /home/laptop/.ssh/known_hosts:2
debug1: client_input_hostkeys: searching /home/laptop/.ssh/known_hosts2 for [192.168.1.224]:9222 / (none)
debug1: client_input_hostkeys: hostkeys file /home/laptop/.ssh/known_hosts2 does not exist
debug3: client_input_hostkeys: 3 server keys: 1 new, 1 retained, 1 incomplete match. 0 to remove
debug3: client_input_hostkeys: asking server to prove ownership for 1 keys
debug3: send packet: type 80
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env COLORTERM
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env SSH_AGENT_LAUNCHER
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env GNOME_SHELL_SESSION_MODE
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env XMODIFIERS
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env PWD
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env SYSTEMD_EXEC_PID
debug3: Ignored env XAUTHORITY
debug3: Ignored env HOME
debug3: Ignored env USERNAME
debug3: Ignored env IM_CONFIG_PHASE
debug1: channel 0: setting env LANG = "it_IT.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LS_COLORS
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env VTE_VERSION
debug3: Ignored env WAYLAND_DISPLAY
debug3: Ignored env GNOME_TERMINAL_SCREEN
debug3: Ignored env GNOME_SETUP_DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env XDG_SESSION_CLASS
debug3: Ignored env TERM
debug3: Ignored env LESSOPEN
debug3: Ignored env USER
debug3: Ignored env GNOME_TERMINAL_SERVICE
debug3: Ignored env DISPLAY
debug3: Ignored env SHLVL
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env PATH
debug3: Ignored env GDMSESSION
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 81
debug1: client_global_hostkeys_private_confirm: server used untrusted RSA signature algorithm ssh-rsa for key 0, disregarding
debug3: hostkeys_foreach: reading file "/home/laptop/.ssh/known_hosts"
debug3: host_delete: ED25519 key already at /home/laptop/.ssh/known_hosts:1
debug3: host_delete: ECDSA key already at /home/laptop/.ssh/known_hosts:2
debug1: update_known_hosts: known hosts file /home/laptop/.ssh/known_hosts2 does not exist
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to TNAS!
[Master@TNAS-001 ~]#
âŚfingerbots are getting more and more appealingâŚ
P.s. On TOS 5.1, only root user can ssh into NAS and, as mentioned, only through username and password (at least this is what Terramaster settings page shows). As I said at a certain long gone point in this topic, I tried ssh for a long time, but never succeeded. If the shell_command could be corrected somehow, that would be the easiest way to go. I tried as many permutations of the code I could imagine, before giving up, but Iâm just a beginner, I donât actually know what Iâm doing 90% of the time so I expect things not to work 99% of the times.
As suggested, I changed the misleading title.
Thanks
1 Like