I have three new Raspberry Pis running this OS:
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
I cannot get Remote Desktop to connect properly. I have xrdp and all updates installed on the Pi. SSH is on and I can connect via a gitbash terminal fine. VNC connection is enabled and viewer connects just fine. I keep getting the following error after logging in to the Pi's ip address (192.168.4.84):
Connecting to sesman IP 127.0.0.1 port 3350
sesman connect ok sending
login info to session manager, please wait...
login successful for display 10
started connecting
connection problem, giving up
some problem
Per many other posts, I have tried:
restarting the xrdp service
adding auto lo to /etc/network/interfaces
reinstalling xrdp, vnc4server, and tightvnc in various orders per this answer.
adding allowed_users = anybody to /etc/X11/Xwrapper.config per this answer.
per this post, I tried purging xrdp, then purge vnc server, then reinstalling xrdp with no luck.
I tried installing an older version of xrdp per this answer, but the package is no longer available.
I tried adding this to sesman.ini, no luck
I have another Raspberry Pi running version 10 OS with no issues:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
Any suggestions to get the newer OS working properly?
I have found the reason for the issue in this answer.
Turns out you cannot login twice with the same account using xrdp on Raspbian Bullseye (Debian 11). So you need to either disable autologin using "Raspberry Pi Configuration"/sudo raspi-config or create another user.
I created a second user and confirmed that this works. Thanks #A.J.Bauer
I got my Pi 4 today and ran into exactly your problem. Took me 1 hour to figure out how to fix, hope it can help:
Remove and purge all VNC server and then install/reinstall XRDP
sudo raspi-config
Go to (1) System Options -> S5 Boot/Auto Login -> select "B3 Desktop GUI - requiring user to login". It should works with this option. Otherwise you can give a try with the automatically logging in as pi user option.
Reboot and have fun !
The problem is that there is some process
still using the login name.
I solved this way:
add a new user, give sudo privs
rdp with that, it should work
deluser the previous one
kill any process that gives error in point 3 and repeat
set autologin to console no auto w/ raspi-config
reboot
rdp with new user
adduser the old one
rdp with that
you're good to go
Related
I try to enable SSH on my raspberryPi 4. I don't have screen and it's for that I created ssh file (without extansion) in D:boot. When I try to log in I get an 'Acces denied' response from ssh terminal. I try with pi id and raspberry password. I created/default new raspberry image (x64). when I take back my sd card to check, ssh file doesn't exist.
Have you any issue.
I was running into the same problem, but in this case its not a problem about SSH itself.
The real problem is RaspberryPiOS removed the default User "pi" since the lastest version (April 4th, 2022). Means you get "access denied" because there is no User named "pi". (Release notes here: https://downloads.raspberrypi.org/raspios_arm64/release_notes.txt)
To create a user you have 3 options: (use 1 out of 3)
Plug in a display and keyboard on your RasPi and follow the steps on screen to create a User.
Use the Raspberry Pi Imager tool to create a new Image on your SD-card. Under advanced settings you can set a username.
Flash the Image again and beside creating a "ssh"-file you need to create a "userconf.txt", containing a single line of text, consisting of "username:encrypted-password".
For example: (to get standard-user "pi" and password "raspberry" again.)
"pi:$6$/4.VdYgDm7RJ0qM1$FwXCeQgDKkqrOU3RIRuDSKpauAbBvP11msq9X58c8Que2l1Dwq3vdJMgiZlQSbEXGaY5esVHGBNbCxKLVNqZW1"
More information here: https://discourse.pi-hole.net/t/warning-latest-raspberry-pi-os-image-april-4th-2022/54778
Hope i could help, have a great day!
WhisperFromDarkness
What is so maddening about this is that the latest Imager (at least the macOS version) pre-populates the user name in the advanced screen with "pi", which is no longer a valid user. After about 3 attempts, it dawned on me that I had to put in a different username and password to get SSH to work. They should definitely update the Imager with a blank username.
Did you manage to solve this yet? You can solve this using the Raspberry Pi Imager application.
To begin, when referring to the fact you have no screen, I assume you mean you are running the raspberry pi 'headless', meaning controlling it through secure shell (SSH) over your local network.
If you have not already installed the raspberry pi imager application, this can be found on the official raspberry pi website. On this application, you must select the relevant SD Card and operating system, before pressing CTRL+SHIFT+X, which will take you to the advanced settings page. Here, select 'enable SSH', before entering your WIFI SSID and password.
Once you have completed these steps and re-entered the SD card into the raspberry pi, you may open the terminal and enter 'SSH pi#ipaddress', followed by the password you created during setup, or the default password, which I believe is simply 'pi'. You will now have access to the Pi through SSH. Enter the command
sudo raspi-config
and you may alter the configuration settings as you like. Here, you may wish to change the VNC settings, so that you can view your raspberry pi GUI through remote desktop SSH.
I hope this was relevant and solved your query.
I am following the steps here, to setup a CloudSQL DB in Google Cloud Platform. I'm stuck at the step with:
./cloud_sql_proxy -instances="[YOUR_INSTANCE_CONNECTION_NAME]"=tcp:3306
I get the message below:
2018/02/07 19:44:10 listen tcp 127.0.0.1:3306: bind: address already in use
I've tried: lsof -i tcp:3306 but nothing shows up. Alternatively, I am able to start a connection to tcp:3307, but that's not what's required in the tutorial, and may prevent the rest of the tutorial from working. When I do lsof -i tcp:3307 however, I am able to see the PID, and kill the SQL connection.
How is the port address 3306 already in use?? Even rebooted my computer.
My Steps I took to fix
I stop Mysql on my local machine
brew services stop mysql
But I had a problem of giving a directory for
Directory to use for placing Unix sockets representing database instances as seen by the console error
Then I did
sudo mkdir /cloudsql; sudo chmod 777 /cloudsql
My Final Script
./cloud_sql_proxy -instances=MyInstanceConnName=tcp:3306 -projects=myproject -dir=/cloudsql/
UPDATE: After trying to dig through many methods to kill the sql process, find out whats actually running on it, joining the gcloud slack group to ask around, etc etc, I ended up uninstalling mysql, and reinstalling it. Fixed it. :shrug:
I currently am using Cmder (which is effectively conemu) to SSH into a university cluster from my Windows machine. I want to enable x-forwarding, and I have Xming installed. I followed the instructions here, which I swear I've used before but doesn't seem to work right now. Specifically, I type
DISPLAY=localhost:0.0;export DISPLAY;
once I open up a Cmder terminal (with Xming already loaded), but the error I get back is
Error: cannot open display: localhost:0.0
despite Xming saying it is Xming server:0.0. Any suggestions? I should add that the x-forwarding works perfectly fine with MobaXterm, but I'd prefer to stick with Cmder.
The issue was that I was setting the display variable on the client server, not the host computer. On my Windows machine, I opened Xming and then did
set DISPLAY=127.0.0.1:0.
Afterwards, I SSH'd into the client server via
ssh -X myname#address.
Now everything works as intended.
I have exactly the same problem. However, I have observed that if I open up a Putty session with x11 forwarding set, then add the display number to my ConEmu session that is ssh'd into the Linux box, then x11 works from ConEmu. Weird.
It is an inconvenient workaround at best.
I made it work for me.
Even so Xming was telling me "localhost:0.0", after connecting to the my server (using the "-x" ssh's option) I rather did :
DISPLAY=:10.0;export DISPLAY;
The following worked for me:
export DISPLAY=127.0.0.1:0
ssh -XC <hostname>
I just purchased new raspberry pi and tried to install raspbian using Noobs.
So the installation goes successfully and I boot into raspbian GUI successfully and make changes to raspi-config like to ask for the password when booting into GUI and enable various option like SSH,SCI and more. Then it reboots and gives me following error:
Raspberry pi Fatal server error: could not create lock file in /inp/.1xd-lock Please consult the X.org Foundation support at http://wiki.x.org for help
init: giving up
init: unable to connect to X server: Connection not sucessfull
init: server error nuth: error in locking authority file /home/pi/.xauthority
I have done this process so many time it is giving me same error every time. Any suggestion.......
Check your .xauthority file to make sure it's owned by the user you're logging in as rather than root. If it's owned by root, you can either change the ownership, or simply delete it and it will be recreated next time you attempt a login.
This has happened to me before!
It is likely your .xauthority file is corrupted, or root owns that file which means it won't let you boot into the GUI. Try this code and it seemed to work for me...
sudo chown -R pi:pi /home/pi
Basically what this is doing is it is reverting all the files' permission settings back to you, so the .Xauthority file for your account will be yours again.
BUT...
If the actual file itself is corrupt, then do this:
xauth -b
.Xauthority is not needed on startup, so it is safe to just delete it off your SD card, since a new version will be generated when you boot into the GUI.
I've got a Windows 7 machine setup with vagrant/virtualBox - each morning when I try to access my development site it always a 'Unable to connect' error message in my Firefox browser.
Even though I have booted the machine using the 'vagrant up' command for some reason it only seems to be accessible via the browser once I have done the 'vagrant provision' command. This is obviously annoying as it starts doing stuff from scratch.. eg installing my mysql database again.
Can anyone provide any light into this, and why it seems to fail to connect all the time - as this provision command is only a temporary fix as i'll need to amend the DB everytime which is only feasible in the short term.
Might just be my own setup - but I noticed nginx was restarting so have to restart this each time