Restarting the steps in this tutorial shouldn't take much longer than 40 minutes. That will get your local server up and running, and you'll have a starting point for your future customisations. Much quicker than trying to diagnose anything that may have gone wrong in the last few days.Ughhhh, don't tell me that it all got ruined because I changed to NAT?
I am so exhausted of all this rocket science and I just want to play. I don't want to have to give up when everything is done and I almost made it through this incredibly difficult journey to fulfill my dream. But there's no way I'm starting over again after working hard on this for over a week, I can't go through all of this again, there's so much stuff and there's no way I'll even remember half of it
Please tell me I can just change back to Bridged Adapter without the files being ruined. Although them being ruined would explain why the server didn't work. Ah man, just kill me
Edit: There's just one card or whatever to choose from when I put bridged adapter. It says Ethernet Connection in it, so it doesn't even sound like a card to me. I changed back to bridged adapter and tried to start the server again before giving up, and it worked to load it again now. You nearly gave me a heart attack lol. I checked the IP again and I'm back to having the non-functional one which my Tibia can't connect to. Bridged adapter is selected and the only card thing is selected, how do I change from this bad IP to one I can connect to?
Edit again: Could it maybe be a port issue? I haven't seen anything about the port anywhere other than on top of my Tibia client when the IP shows up there from the IP changer, and it puts 7171 as the port. Is it maybe the wrong port or it needs to be forwarded or something? I know it doesn't change the fact that I only get one IP and it doesn't have the numbers you wanted it to have, but it's just a thought, I know ports tend to be important.
Restarting the steps in this tutorial shouldn't take much longer than 40 minutes. That will get your local server up and running, and you'll have a starting point for your future customisations. Much quicker than trying to diagnose anything that may have gone wrong in the last few days.
Calling it rocket science is a bit of an exaggeration, it's just that the entry level for this kind of task comes with an assumed experience that you simply haven't got yet. I can't provide an all-in-one installer for legal reasons, so currently this tutorial is as close as you can get to that.
But you should be much better now than a couple of days ago. You've learned a lot and that will help you specially now that everything is still fresh in your mind.
As long as you insist in using an ip changer or trying to customise anything before the server is playable, I can't be of much help. I've already given my advice that I believe will help you the most, but there's only so much hand holding I'm willing to do. Try that first, then I'll be happy to help should any other issues arise.
Good. Now, with that out of the way, we can finally make some real progress on the diagnosis.I gave up and reinstalled it.
You said yourself: you tried so many solutions, you can't retrace everything, you don't understand any of it... As you become more experienced, you'll realise that any change you make matters, and we need to start with a clean slate to better diagnose your issues.I just don't get why doing it all from the start again would make any difference
Without knowing how your network is set up at your place, we'll need to first try to figure out why it's getting different IPs. Here's a few things you have to do:I seem to always find the problems no one else has, I don't get how I could be the only person who's ever been given a faulty IP, and why no one seems to have a fix for it.
ip -4 addr show | awk '/inet/ && $2 !~ /^127\./ {gsub(/\/.*/, "", $2); print $2}'
ipconfig | findstr /R /C:"IPv4.*[^127.0.0.1]"
sudo tcpdump port 7171
telnet YOUR_UBUNTU_IP 7171
'telnet' is not recognized as an internal or external command, operable program or batch file.
, you'll need to enabled it in your Windows.If I remember correctly, all chars are premium by default.Since this is all vanilla, how does premium work? I won't be without access to premium areas, will I?
Good. Now, with that out of the way, we can finally make some real progress on the diagnosis.
I hope you listened to my advice and created a VM snapshot before running the install script, because if something goes wrong (and it likely will) we'll need to go back to that state, otherwise you'll need to reinstall everything once again.
You said yourself: you tried so many solutions, you can't retrace everything, you don't understand any of it... As you become more experienced, you'll realise that any change you make matters, and we need to start with a clean slate to better diagnose your issues.
Also, you mentioned you configured port forwarding, set static ip, etc. Either you need to restore all of that to how it was, or you'll have to restore the snapshot to a moment before these changes.
Without knowing how your network is set up at your place, we'll need to first try to figure out why it's getting different IPs. Here's a few things you have to do:
One issue that could happen when your Ubuntu gets an IP with same prefix as your Windows, is that the automatic IP might conflict with another existing IP in your network (e.g.: a smartphone, another PC, smart home devices, etc). So when you successfully manage to communicate with your server, only then it's a good idea to set a static IP by going to the Network settings and setting something like this:
- Take note of the internal IPs on Ubuntu
- Make sure the network mode in your VM is Bridged Adapter. Under "Advanced", "Promiscuous Mode" should be "Deny", and "Cable Connected" should be checked.
- On the Ubuntu terminal, paste and run this command to list all internal IPs available:
ip -4 addr show | awk '/inet/ && $2 !~ /^127\./ {gsub(/\/.*/, "", $2); print $2}'
- Take note of the internal IPs on Windows
- On your Windows cmd, paste and run this command to do the same:
ipconfig | findstr /R /C:"IPv4.*[^127.0.0.1]"
- View attachment 78642
- You should have at least 2 entries there. Notice how the prefix of one of the IPs (192.168.1.7) coincides with the prefix of Ubuntu's IP (192.168.1.166). But this doesn't seem to be the case with your setup, which is what we need to investigate.
- The other IP address is probably your VirtualBox simulated adapter.
- Listen to traffic on port 7171
- Back to Ubuntu terminal, run this command to listen to port 7171:
sudo tcpdump port 7171
- You'll be asked for your user password
- Nothing will happen yet, because there's currently no traffic going through that port
- On Windows cmd, run this command to "ping" to the port being listened:
telnet YOUR_UBUNTU_IP 7171
- Replace YOUR_UBUNTU_IP accordingly. In my example, that would be 192.168.1.166
- If you get the error
'telnet' is not recognized as an internal or external command, operable program or batch file.
, you'll need to enabled it in your Windows.- You should see some packages coming through on your Ubuntu
- Close the telnet window on Windows
- Close (press Ctrl+C) the tcpdump on Ubuntu
- If Ubuntu isn't listening to anything, it means your Windows and your Ubuntu are not on the same network.
- Try changing the VM network mode to something else
- Run the command again to find your internal IP address on Ubuntu
- Run the tcpdump command again on Ubuntu
- Run the telnet command again on Windows, but with the new IP on Ubuntu
- Repeat that with other network modes until your Ubuntu listens to something
- When it listens to something, you'll need to restore the snapshot to a moment before the install script was executed, then run them again so the server will be configured with the right IP
- Now you should be able to configure your IP changer with the Ubuntu IP, and port 7171.
View attachment 78653
- IPv4 Method: Manual
- Address: should be the IP address for your Ubuntu. Can't end with ".1".
- Network: 255.255.255.0
- Gateway: same as the IP address, but ending with ".1"
- DNS: Automatic, but also set it 8.8.8.8 in case you want to manually connect to Google's DNS server later
- Then click Apply
If I remember correctly, all chars are premium by default.
Taking a snapshot is something that you should be able to find by yourself easily with Google/ChatGPT/Bard/Bing - please use more these resources. Anyway, just click on these 3 buttons in this order:I did not do a snapshot yet, because I still don't know how. Getema showed a snapshop button in a picture from his VB, but that is the one button missing in my own VB, and then that topic was dropped after that discovery. But, luckily, I have yet to run the install script for the OT. I installed the Ubuntu with the intention of immediately checking the IP, and halfway through downloading the OT scrips I realized I had gotten caught up in the instructions. I paused that process, checked the IP, found that it was still not good, and I waited with continuing. So, I can still snapshot before doing that, but I'm really lost on how to take snapshots.
I never needed the port forwarding on Windows, so I think you should undo it. I'm still trying to understand your network settings, the fewer variables and interference the better.One thing that might be worth mentioning is that I did the port forwarding in Windows (should that have somehow been done in the Ubuntu if port forwarding was necessary?) so it shouldn't have affected anything with the server (I assume).
If you ranHere's where I'm currently stuck; How do I know if my Ubuntu is listening? Does receiving the packages (like in your screenshot of it) mean it's listening? If that's the case, then we can at least confirm that they are in fact on the same network, because I did telnet the port and Ubuntu did spit out packages that look rather similar to yours.
sudo tcpdump port 7171
on the Ubuntu terminal, you should see the message above the red rectangle I drew on that screenshot. Notice how the first thing it says is "listening on...". That means Ubuntu will log to the terminal all the packages being received through port 7171 (see inside the red rectangle), which is the same port that the Tibia client uses to connect to the server. However, you should only see them coming through when you execute the telnet command on Windows or when you try to login to an account via the Tibia client. Maybe your IP changer is also sending those packages, so it's better to close it before listening then open them to see the time you receive the packages coincide with the time you establish a connection. Please send a screenshot of the output so I can investigate better.The telnet command should open an empty terminal on Windows. Paste here the screenshot if you're seeing an error message.However, when I did it, on the Windows end (in cmd when I telnet'd the port) it looked like it was a fail, despite the packages seemingly coming through on the other end. It told me it can't connect to the host at port 7171, the connection failed.
Pinging the server is very different than connecting to the Tibia's login server. We're talking about different protocols, different ports, etc. Your server seems to be reachable, but that's not enough for your client to connect. I still suspect there's something weird in your network settings that is preventing Ubuntu from getting a correct internal IP. Is your public IP the same as your external IP?Sounds like it has the same problem as when my Tibia tries to connect, even though pinging it works. To a novice like me it looks like it's there and reachable but it's refusing to let stuff connect to it.
Think of this as a conversation. There's one person listening (the server), but for communication to happen the other person needs to talk (the client). Ubuntu is "listening" i.e.: it's got its ears up (the tcdump program) - but no "noise" is being picked up. It seems Windows is "talking" (the telnet program), but the noise is not reaching Ubuntu for some reason (or maybe, according to your report, it's picking up what someone else is saying). It's like there's a thick sound proof wall between them, and that's what we're trying to work around.I'm unsure how to proceed from here, with the following instructions about switching things up until it listens being a little unclear to me as I'm not sure what my result entails.
If this was not it listening, then how do I know when it is? And if it was, then what do I do now, as if I understood the end of your post correctly, when it listens I have settings that work, but things are clearly not working yet.
Taking a snapshot is something that you should be able to find by yourself easily with Google/ChatGPT/Bard/Bing - please use more these resources. Anyway, just click on these 3 buttons in this order:
View attachment 78654
I never needed the port forwarding on Windows, so I think you should undo it. I'm still trying to understand your network settings, the fewer variables and interference the better.
If you ransudo tcpdump port 7171
on the Ubuntu terminal, you should see the message above the red rectangle I drew on that screenshot. Notice how the first thing it says is "listening on...". That means Ubuntu will log to the terminal all the packages being received through port 7171 (see inside the red rectangle), which is the same port that the Tibia client uses to connect to the server. However, you should only see them coming through when you execute the telnet command on Windows or when you try to login to an account via the Tibia client. Maybe your IP changer is also sending those packages, so it's better to close it before listening then open them to see the time you receive the packages coincide with the time you establish a connection. Please send a screenshot of the output so I can investigate better.
The telnet command should open an empty terminal on Windows. Paste here the screenshot if you're seeing an error message.
Pinging the server is very different than connecting to the Tibia's login server. We're talking about different protocols, different ports, etc. Your server seems to be reachable, but that's not enough for your client to connect. I still suspect there's something weird in your network settings that is preventing Ubuntu from getting a correct internal IP. Is your public IP the same as your external IP?
Think of this as a conversation. There's one person listening (the server), but for communication to happen the other person needs to talk (the client). Ubuntu is "listening" i.e.: it's got its ears up (the tcdump program) - but no "noise" is being picked up. It seems Windows is "talking" (the telnet program), but the noise is not reaching Ubuntu for some reason (or maybe, according to your report, it's picking up what someone else is saying). It's like there's a thick sound proof wall between them, and that's what we're trying to work around.
Send me those screenshots and hopefully that will give me enough information to progress with the investigation. Also, you still need to try these different network modes on your VM settings and see if you get a different internal IP: NAT, Internal network and Host-only Adapter.
That sounds right, and very easy to test: make any small change to the server e.g.: create a file anywhere, then restore to Snapshot 1. If the file is not there, it worked.Now it says "Snapshot 1" on my Machine that holds Ubuntu. Shouldn't the snapshot be a copy to return to, rather than the file itself? Does this mean I should take a second snapshot, or what do I do next to ensure that I do in fact have a copy to return to?
Please send a screenshot of the output of that command on Windows cmd that lists your IPs (Ah, the one sentence I missed was the one with the word "listening", as it was just outside the red line.
So it is listening, that must be good. I attached a picture of the result, but I can't put one of the fail message on the cmd end, because it's not in English. My translation of it in my previous response is the entire message and there's no more to get out of it. Here's an exact repeat of everything that showed up in the Windows cmd box after I sent the telnet command: "Connecting to (my Ubuntu IP)...Could not connect to host, on port 7171: Connection failed."
I'm not sending anything to the port with the IP changer, as I have yet to run the install scripts so I can't attempt connecting my Tibia just yet. I figured it's better to hold off on running the scripts until we've had a look at this.
ipconfig | findstr /R /C:"IPv4.*[^127.0.0.1]"
). I still don't understand how you're getting packages coming through on Ubuntu if you're not the one sending the packages. There must be another program doing that in your network. sudo tcpdump -n port 7171
on Ubuntu. Notice that there's a "-n" in the command, this should force the log to show private IPs instead of resolved hostnames.I suspect your router's DHCP is not assigning IPs correctly, because you shouldn't be getting that kind of IP. Unfortunately working around that is something that requires a bit more expertise in router configuration and I really hope we don't need to go down that path."Is your public IP the same as your external IP?"
I assume you still mean in Ubuntu, and the answer is yes. The same IP I always get, with seemingly just the last few digits differing from time to time. You can see the first and last ones in my picture (and on the Windows IP too), I only censored the middle.
I also need the screenshot of Ubuntu's tcpdump while your VM is in NAT mode.In case you forgot, I did already try another network setting to get a different internal IP. I tried NAT, which did give me the desired IPs but broke the server. I believe it was the very course of action that intitiated your request for me to reinstall it all. As I'm currently not sure how to even use the snapshot, and with that previous test proving that other settings can change the IP, I figure I can skip messing with that again until after your analysis of my "listening" picture and response to the fact that I did achieve the better IPs when I changed those network settings in my past iteration of this project.
That sounds right, and very easy to test: make any small change to the server e.g.: create a file anywhere, then restore to Snapshot 1. If the file is not there, it worked.
Please send a screenshot of the output of that command on Windows cmd that lists your IPs (ipconfig | findstr /R /C:"IPv4.*[^127.0.0.1]"
). I still don't understand how you're getting packages coming through on Ubuntu if you're not the one sending the packages. There must be another program doing that in your network.
Let's test it again. Close all programs on your Windows (except VirtualBox, obviously), then runsudo tcpdump -n port 7171
on Ubuntu. Notice that there's a "-n" in the command, this should force the log to show private IPs instead of resolved hostnames.
I suspect your router's DHCP is not assigning IPs correctly, because you shouldn't be getting that kind of IP. Unfortunately working around that is something that requires a bit more expertise in router configuration and I really hope we don't need to go down that path.
I also need the screenshot of Ubuntu's tcpdump while your VM is in NAT mode.
Never seen that error before, but doing a quick search online it seems that you tried to restore the snapshot with the VM still open. You need to first close your VM (and save the state) before you can restore it. Try that and let me know how it goes.I got an error when I tried to restore to the snapshot, as per the picture I attached. I opened the machine and the random file I created was still there, so something did go wrong indeed.
The one starting with 192 could be your VirtualBox emulated connection. Run"Please send a screenshot of the output of that command on Windows cmd that lists your IPs (ipconfig | findstr /R /C:"IPv4.*[^127.0.0.1]""
That one literally just makes my 2 Windows IPs show up. One starts with 90, the other is the usual 192.168.~
ipconfig /all
on your Windows cmd, search for this IP there, then read its description. It should be "VirtualBox Host-Only Ethernet Adapter" or similar (paste here what it is). As you're running these commands before the install script, it's likely that Ubuntu's firewall is blocking traffic on port 7171."I still don't understand how you're getting packages coming through on Ubuntu if you're not the one sending the packages."
But I am the one sending them. I mean, sure, I did get the connection failed message when I did the telnet thing, but packages came through right then and not at any other time. I had the terminal open for hours and no further packages arrived. It's only happened right when I telnet'd.
sudo ufw allow 7171/tcp
sudo ufw status | grep 7171
I just tested it with the commands I provided in step 1 of the tutorial and it worked. Not sure what you're doing wrong there."Let's test it again."
I did put the command, and I'm not receiving any packages without telneting.
I also can't get the sudo to work as well in this new copy. It keeps telling me I don't have sudo access, despite putting in all the sudo permission stuff I did last time, including the fix for when this problem occurred in the past. Now I have to do "su-" every time I open the terminal to get root access and be able to put stuff in, or I get the "sret is not in the sudoers file. This incident will be reported" error.
su -
sudo adduser $(whoami) sudo
reboot
You may think you don't have a router, but behind the wall socket there's another cable is connecting you to a modem/router/switch. Given the IP you're getting, chances are that someone (your Internet provider perhaps? someone else in the house?) have configured your network in an unconventional way."requires a bit more expertise in router configuration and I really hope we don't need to go down that path."
You must've missed the part where I mentioned not having a router. It's just a cable from the wall to my pc. Hopefully that makes things simpler and removes some possibilities?
It might be something in the VB/Ubuntu or my network causing all of this, but it is not because of a router, as none exists.
Changing the network mode before the install scripts shouldn't break anything, it will just assign you a new IP address. The problem is when you do that after installing everything, because the scripts will use your current IP to configure several services."I also need the screenshot of Ubuntu's tcpdump while your VM is in NAT mode."
I guess I'll need to get the snapshot restoration working before I can do that. Or will changing to NAT mode before installing my scripts not break things and force another install?
You need to first close your VM (and save the state)
It should be "VirtualBox Host-Only Ethernet Adapter"
When I did the firewall thing, I got a "rules updated" message. When I did the status check, nothing happened at all. But I'm guessing the rules updated thing confirms that it changed.
- Try to run the telnet in Windows cmd again
I just tested it with the commands I provided in step 1 of the tutorial and it worked. Not sure what you're doing wrong there.
Given the IP you're getting, chances are that someone (your Internet provider perhaps? someone else in the house?) have configured your network in an unconventional way.
Changing the network mode before the install scripts shouldn't break anything, it will just assign you a new IP address.
I think you're right, but test it once again just to be sure. Create another file, restore to a previous snapshot and confirm that the file doesn't exist.I opened it now, and if I understood it correctly it was currently running on my second snapshot it created when I tried to restore to the first one. Or maybe it was just showing that it's there. Either way, I tried to restore to snapshot1 again, and all that happened was that it changed to snapshot1 in the name of the machine. I'm not sure if that means it succeeded, as it said that name there back when I created it (which was the reason for my original confusion), but when I checked the Ubuntu after this new restoration attempt I don't see the random file I created, which I threw in the trash after my attempts (and the trash is empty here) so I think it worked this time. In the error I sent you, I interpret it as saying that I can't restore because it's currently making a snapshot. At the time it was making snapshot2, because when I clicked to restore the first one it asked if it should create a second one for me. So it seems like the restoration failed because of its own request to make a new one at the same time. When I tried it now (and succeeded), I didn't make a third snapshot. So I think we're good on the snapshot stuff now.
That looks like the correct internal IP for your Windows PC. Now we need to make your Ubuntu get a similar IP.I did find the 192.~ IP in there, but it did not say the VirtualBox thing, instead it said this:
"IPv4 Address. . . . . . . . . . . : 192.168.~ (Preferred)"
I looked through the rest of the information that popped up, and it didn't say VirtualBox anywhere.
That's expected, it's just to ensure that your firewall is allowing traffic to that port.When I did the firewall thing, I got a "rules updated" message. When I did the status check, nothing happened at all. But I'm guessing the rules updated thing confirms that it changed.
When I ran telnet again, I had the same result as last time. The packages immediately came in, and they look the same. I even compared them a bit to the screenshot of the past ones, and only some numbers changed (the ones at the end of the time stamp thing, and the ones after my internet provider name).
The most common scenario, at least in the places I lived, is for each apartment/flat/house to have its own router. Perhaps your building provides everyone Internet via the same provider? That's more common in offices. Anyway, if that's the case, you shouldn't (and probable won't have permission) to change anything in the router settings, as that will likely affect others using it. Sending the screenshot might help yes.Are you 100% sure that there must be one? Because I've never heard of there being routers in the building, and I don't know any place they could be. Since we also often have routers in our apartments, does it work for the building to have a router and then connecting your own as a second router? Maybe that's fine, I'm just thinking that if I put 2 routers in my apartment and have them connect to each other it would mess stuff up. But anyway, if there is a router or some kind of network or whatever that someone configured, what could I possibly do about it? Aren't those settings I'd have to live with them? Would we then have to find a solution beyond changing network configuration, or can there be a worst case scenario where I could never make this work because my landlord did something weird when they set up the internet in this area?
Would sending a screenshot of the network on my Windows help at all?
The Host-only seems promising. Let's run tcpdump on your Ubuntu, then send packages from Windows:You also told me before to try both NAT, Internal Network, and Host-only Adapter to see what internal IP I get. So, I tried Internal Network and Host-only Adapter now too, so you have all the information in case that's still relevant too.
With the Internal Network setting I couldn't even get an IP, it was like the IP check commands were dead, nothing happened when I put them in.
With the Host-only Adapter, I finally got an 192.168.~ IP as my internal one, but nothing happened with the external one (I'm guessing that's how it's supposed to be, but I'm just being thorough). If the Host-only Adapter one is a functional connection that doesn't allow for public use, could it be a solution to use that one instead of Bridged Adapter, as perhaps the 192.~ IP will let me finally connect to the Tibia server, with the remaining problem being that no one else can join me? If that would work I could totally live with such an option, as I currently don't have anyone who's planning to join, and at this stage I'm just desperate to actually get to play this.
I think you're right, but test it once again just to be sure.
The most common scenario, at least in the places I lived, is for each apartment/flat/house to have its own router. Perhaps your building provides everyone Internet via the same provider? That's more common in offices. Anyway, if that's the case, you shouldn't (and probable won't have permission) to change anything in the router settings, as that will likely affect others using it. Sending the screenshot might help yes.
If the Tibia client sent new packets, you should be able to run the install scripts.
sudo permissions are also refusing to work since my reinstall
good sign to be hopefultried the IP-changer and Tibia and a lot more packets came through than with the telnet, and then I got the connection refused error in Tibia, and it said all login server are offline (which I'm not entirely sure it said before?). So I assume it stopped sending packets because of the error, and that the error appeared because the servers actually aren't there this time. I will run the scripts
did u enter each command separately?
what did u try can u be a little more specific?That time I found a fix, which I retraced and used again on this install, but it didn't fix it this time.
can't u right click realots folder on desktop,can't run the install scripts because the cd command is refusing to work
...
what causes the cd command not to work?
Good job.Done. Created a third snapshot, made a test file, restored to the snapshot, file is gone. It all worked splendidly. When I make the snapshots I just need to untick the box that asks me to make a snapshot of the current version before restoring, as that messed it up the first time, which seems like a design flaw.
I worked in several offices with a similar setup, so that could be the case for your building too. The downside is that you won't be able to change any settings on the router if it comes to that.I'm not sure, but I think it's likely it's just one provider in this building. Is a building wide router less likely if it's just one provider? I think the internet is fiber, if that's relevant at all.
When you start telnet, it will establish a connection to the IP and port specified. This alone will send a few packets, which is what you're probably seeing on the tcpdump log. Then it will only send more packets if you type in anything on the telnet terminal.Packets did come through to the Host-only 192.~ IP, but they immediately stopped like always with the usual error (makes me wonder why telnet needs to be closed when it never seems to keep sending packets).
That's the exact expected outcome, you might be on the right track.I then tried the IP-changer and Tibia and a lot more packets came through than with the telnet, and then I got the connection refused error in Tibia, and it said all login server are offline (which I'm not entirely sure it said before?). So I assume it stopped sending packets because of the error, and that the error appeared because the servers actually aren't there this time. I will run the scripts without getting too hopeful, and we'll see momentarily if this works.
Unfortunately if you can't access the Internet, the install script won't work. It downloads and installs a few programs on Ubuntu which are required to set up things like the server database, firewall and other dependencies. You should go back to Bridged Adapter for now.Alright, first problem encountered is the fact that I seem to not have internet with the Host-only option. It makes it very difficult to get things done, as I need to download scripts and navigate forum posts. I now have to go back and forth between Bridged Adapter and Host-only every time I need to do something that requires internet access. I hope this won't mess with the server files or something once it's up?
If you're getting "no such file or directory", I'm sure the "cd" command is still functional, you're just typing in the wrong file/folder path....And now I'm back in hell again. I can't run the install scripts because the cd command is refusing to work. No matter what directory I try to send it to, I get the "no such file or directory" message. I've researched it and typed it in a million different ways and just tried so hard and it's just refusing to work.
That's unlikely to be related, but would also help if you could send a screenshot of the terminal in which you're running those commands I mention in the first step, as I still believe you're misinterpreting something.Since my sudo permissions are also refusing to work since my reinstall, could the fact that I now always have to be in root mode in the terminal be what causes the cd command not to work?
You're probably missing a tiny detail that I took for granted when I wrote the tutorial. I can understand how lots of things I said could be unclear or ambiguous for people who don't have experience with Ubuntu. There's nothing hating you, it's just that this thing is not easy and you're still learning. Also, your network setup is not helping either, but we're going to keep investigating until we exhaust all our options.I don't know, only thing I could think of. But I'm now stuck on an old problem I feel like I've already solved before. This stuff just hates me so much and I don't know what to do anymore, it seems to be doing everything in its power to ensure that I never get to play![]()
This tip from @getema27 helps. I suspect you're have typos in your path, because every character matters. When it comes to file or directory paths, there are absolute paths and relative paths.![]()
what did u try can u be a little more specific?
cd /home/username/desktop/realots/
u enter directory like this?
can't u right click realots folder on desktop,
left click open in terminal to avoid cd command?
Unfortunately if you can't access the Internet, the install script won't work. It downloads and installs a few programs on Ubuntu which are required to set up things like the server database, firewall and other dependencies. You should go back to Bridged Adapter for now.
By the way, can you remind me if you're getting the same tcpdump/telnet results when you're on Bridged Adapter?
If you're getting "no such file or directory", I'm sure the "cd" command is still functional, you're just typing in the wrong file/folder path.
Let's agree something: from now on, any error message you get, even if it's in a different language, please take a screenshot and paste it here. It's incredibly hard to guess what it could be without it.
That's unlikely to be related, but would also help if you could send a screenshot of the terminal in which you're running those commands I mention in the first step, as I still believe you're misinterpreting something.
This tip from @getema27 helps. I suspect you're have typos in your path, because every character matters. When it comes to file or directory paths, there are absolute paths and relative paths.
Or even better: copy the commands we post here, and paste them in your terminal.
Not really, we have new information to work with so we're getting a bit closer to the solution now.So we're basically back to square one again?
Yes, but once we fix the sudo issue you're having, I'll need the screenshot from the telnet failure because that's not the expected outcome.I assume you're referring to the ones I had from telneting the 192.~ IP with the Host-only setting? I tried to telnet it now with Bridged Adapter and the bad 213.~ IP, and I get the usual connection failure message on the Windows end and a few early packages coming through to the Bridged Adapter IP. I'm guessing that means it's the same results, but I'm hoping I was thorough enough for you to be sure that it is.
I can tell straight away what the problem is. That's why screenshots are important.I feel like I do exactly what I did before, yet this time around it doesn't work. Same as the sudo stuff. That one is even more basic, as it's just a couple of copy paste things, so there's less room to have done something different or wrong than it is with the cd stuff where there's a lot of typing and making sure to get every detail right. I attached a picture of all of my most recent attempts to access my scripts folder, including my new ones where I put my user in there, since getema also had that in his suggested file path and I don't remember having it in there before. But they're still all failing. In logs that are now lost I also tried a bunch of ways to get it to folders inside "home", and all I achieved was it acting like I was inside home for a bit.
However, getema's tip to click on the script folder and click to open it in terminal worked to get me there, so that's a brilliant work around that I had no idea existed. But since we're back on Bridged Adapter with the weird IP I can't install them now anyway. It also feels like always having to open folders in the terminal instead of using the cd command isn't ideal, but maybe it can work if we can't resolve my cd issue.
Let's try this again:I did the sudo process again and included a picture of the results. It shows how I did the sudo commands correctly, and get shown as being added, yet get the "not in the sudoers file" error. The other command I found, which fixed it for me in my old install, was "adduser (username) sudo". I also tried that one again, and got the same result about already being in sudo. So it was a magical fix in my last install, and finally activated the sudo then so it worked properly, but this time it does nothing and the issue prevails.
Back to the Bridged Adapter it is. We just need to make sure you can access the Internet as well as listen to telnet from your Windows host PC.So, now that the Host-only thing was a bust, what's our next step? (aside from the side stuff with getting the terminal commands sorted)