• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Script and tutorial to automate install of "Leaked" 7.70 server

the master has spoken brother
don't worry it's always easier the 2nd time
 
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.
 
Last edited:
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.

I'm not interested in customisations, I just want to play...
I've had to get so much help and go through so many things to get this far, there's no way I could retrace it all.
Even if I did have experience, I remain awful at technical things. I can follow instructions, and I might remember what happens when you do a few specific things, but I don't understand any of it.

I just don't get why doing it all from the start again would make any difference. I will select the same bridged adapter and get the same stupid IP, and will have done it all for nothing and I'll still need a fix for it. There is nothing wrong with any files and I never messed with the network settings. I made a post on askubuntu about the IP and so far all I got was to change something called promiscuous mode (near the bridged adapter setting) to "allow all", to allow for incoming connections. It was set to "deny" on my VM, so I was really hyped for it to be the solution, but alas; nothing changed. I then realized that it shouldn't logically have been enough when my IP is still bad. But even though 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.
I even tried port forwarding (which, granted, I can't be sure that I did right or for the right port - it looks nothing in Windows 10 like when I did it in the past) and I still can't reach the server.
As I typed that last sentence, it hit me that pinging is a thing, so I tried to ping the server, and the result is in my attached picture. It looks like it's responding, which just makes me more confused about all of this, but perhaps it's a good sign and something that can help make it clearer what the issue is?

Edit: I just had a random worry. Since this is all vanilla, how does premium work? I won't be without access to premium areas, will I?
 

Attachments

Last edited:

I gave up and reinstalled it. Everything is gone. I followed the instructions. I'm getting the same frickin IP as before the reinstall. For some reason Ubuntu loves that IP and it cannot be vanquished.
Earlier today (before the reinstall) I tried to set a static manual IP in IPV4 in the Ubuntu network settings, and it stayed there but the main IP remained this useless one anyway. And now it's still there in my fresh install, so I lost all my work for nothing.
Can I please have some help in getting a proper IP now or am I seriously gonna have to give up after weeks of hard work and problem solving and reinstalls? :(
 
I gave up and reinstalled it.
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.

I just don't get why doing it all from the start again would make any difference
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.

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.
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:
  • 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.
      • 1695243561647.png
    • 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}'
      • 1695243635468.png
  • 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]"
      • 1695243703000.png
      • 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
      • 1695250725903.png
    • 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.
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:
1695252256392.png
  • 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

Since this is all vanilla, how does premium work? I won't be without access to premium areas, will I?
If I remember correctly, all chars are premium by default.
 
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:
  • 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.
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:
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.

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.

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).

Another thing that might be relevant is that my pc network is quite simple. I don't have a router nowadays, just a cable from the wall to my pc. I don't think there's any way any other devices could interfere, as I only use one pc lately and my only other device is my smartphone I've just bought (yeah, took me this long to upgrade to one, I'm really bad with technology despite having had a pc for decades) and I have yet to learn and begun using it enough to mess with anything like that, I've only just figured out how to answer calls.

Now, to the instructions:
My internal IPs on Ubuntu turned out to indeed just be the bad one that doesn't coincide with the two Windows ones at all.
Here'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.
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. 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.

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.
 
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.
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:
1695262037529.png

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).
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.

Here'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.
If you ran 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.

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.
The telnet command should open an empty terminal on Windows. Paste here the screenshot if you're seeing an error message.

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.
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?

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.
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.
 
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 ran 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.


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.

Being able to left click those 3 blue dots to find the snapshot function kinda blew my mind. 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?

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.

"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.

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.
 

Attachments

Last edited:
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?
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.

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.
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 run 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.

"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 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.

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.
I also need the screenshot of Ubuntu's tcpdump while your VM is in NAT mode.
 
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 run 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.


I also need the screenshot of Ubuntu's tcpdump while your VM is in NAT mode.

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.

"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.~

"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.

"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.

"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.

"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?
 

Attachments

Last edited:
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.
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.

"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.~
The one starting with 192 could be your VirtualBox emulated connection. Run 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).

"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.
As you're running these commands before the install script, it's likely that Ubuntu's firewall is blocking traffic on port 7171.
  • Run this command on the terminal to allow traffic to port 7171: sudo ufw allow 7171/tcp
  • Now run this to confirm that the status was changed to ALLOWED: sudo ufw status | grep 7171
  • Try to run the telnet in Windows cmd again

"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.
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.

Code:
su -
sudo adduser $(whoami) sudo
reboot

"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.
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.

"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?
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.
 
For some reason it suddenly gave me the proper quote bits when I copied messages from your big message today, so at least that's something.


You need to first close your VM (and save the state)

I actually did do exactly that :/
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.

It should be "VirtualBox Host-Only Ethernet Adapter"

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.

  • Try to run the telnet in Windows cmd again
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).

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.

The sudo stuff is always giving me a hard time, I don't know why. I guess I can live with the root thing for now, and I'll try to make it work better later when everything works.
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.

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?

Changing the network mode before the install scripts shouldn't break anything, it will just assign you a new IP address.

Alright. I changed to NAT. When I launched the VM after the change, it suddenly gave me some kind of restoration message, which it didn't when I did restore the snapshot before the last start before that. I'm so lost about that stuff, I can only hope it works.
Anyway, before getting the tcpdump stuff, I checked my IPs. It changed the public one to one starting with 90, and the internal one to one starting with 10. All the numbers in that one were very low.

Now, when I run the tcpdump as requested, I assume you mean to listen and telnet it. And I assume I need the by NAT newly assigned public IP of the Ubuntu. So I put in the tcpdump, then telnet'd the 10.~ one. It gave me the usual fail to connect message, and this time no packages came through. To be safe, I dug up the bad IP the bridged adapter gives me, and tried that one despite having new ones. Same result there. Then I realized that the 10.~ IP is the internal one, so I telnet'd the 90.~ one, and like with the rest I only got the failed connection message, and no packages on the Ubuntu end. So these "good" IPs actually have a worse result than the bad one. Is my Ubuntu just the worst? I hope that somehow this seemingly negative new information helps bring us closer to solving this, because to me it just looks more hopeless than ever.

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.

Edit: One final thing I did is that I telnet'd the 192.~ IP before changing back to Bridged Adapter as I finish up this session, and this time the packages came through again, but like always with a failed to connect to host message on the Windows end.
Now you have tons of information about all the different settings and IPs and telnet results. Does any of it help at all with figuring out the problem or how we can resolve it?
 
Last edited:
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.
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 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 looks like the correct internal IP for your Windows PC. Now we need to make your Ubuntu get a similar IP.

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).
That's expected, it's just to ensure that your firewall is allowing traffic to that port.

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 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.

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.
The Host-only seems promising. Let's run tcpdump on your Ubuntu, then send packages from Windows:
  • First, run the telnet pointing to the Ubuntu IP, like usual. Confirm that there are packets coming through
  • Close the telnet terminal so it will stop sending data
  • If you're trying to use an IP changer, open it now and point it to the Ubuntu IP (and port 7171)
  • Open your Tibia client on Windows, then try to login to any account (even if it doesn't exist)
  • Check the tcpdump on Ubuntu for new packets.
If the Tibia client sent new packets, you should be able to run the install scripts.
 
I think you're right, but test it once again just to be sure.

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.

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.

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.

If the Tibia client sent new packets, you should be able to run the install scripts.

It worked!
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). 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.
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?
...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. 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? 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 :(
 
did u enter each command separately?

su -
<enter>

sudo adduser $(whoami) sudo
<enter>

reboot
<enter>
sudo permissions are also refusing to work since my reinstall


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
good sign to be hopeful
 
did u enter each command separately?

I did. I tried it again now to be sure, and it said I'm already a member. But it still forces me into root every time to be allowed to do stuff, same as it did in my old install. That time I found a fix, which I retraced and used again on this install, but it didn't fix it this time.
 
pepehands.png

That time I found a fix, which I retraced and used again on this install, but it didn't fix it this time.
what did u try can u be a little more specific?

cd /home/username/desktop/realots/
u enter directory like this?
can't run the install scripts because the cd command is refusing to work
...
what causes the cd command not to work?
can't u right click realots folder on desktop,
left click open in terminal to avoid cd command?
 
Last edited:
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.
Good job.

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.
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.

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).
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.

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.
That's the exact expected outcome, you might be on the right track.

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?
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?

...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.
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.

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?
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.

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 :(
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.

pepehands.png


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?
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.

With absolute paths, you need to enter the entire path to a file or directory, starting with a forward slash. Useful when you're inside a folder, and want to go to another folder completely different.
E.g.: "cd /home/game". If you miss the first slash, or type double slashes or whatever, you'll get that error message you said.

Relative paths are relative to your current location. Useful when you're looking for a path that's inside your current folder.
So if you are inside "/home", you can just do "cd game", which is the same as "cd /home/game". Notice how you don't need the first slash in this case.

There are exceptions like "cd ~/Downloads", where the tilde literally means "/home/<your user>". But the point is, pay attention to what you're typing in. You can also enter the tab key to try to autocomplete the path. Or even better: copy the commands we post here, and paste them in your terminal.
 
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.

So we're basically back to square one again? :(
Oh well, it didn't feel like a lack of internet would work anyway. If a friend wants to join in the future I wouldn't even know what to do.

By the way, can you remind me if you're getting the same tcpdump/telnet results when you're on Bridged Adapter?

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.

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.

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 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.

Alright, I'll try to include screenshots more, even when they seem obvious, simple, or problematic.

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.

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.

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.

I didn't know about stuff like typing "game" without the slash when I'm already inside home, or using the tilde, or autocompleting paths. A lot of that seems like it's a bit above my pay grade, so to speak. But with the regular ways with /home/game and so on I feel like I did nothing wrong. Everything I read about it looks exactly the same as how I did it, and it all worked well before the reinstall, so I don't know what could be different and wrong now.
(I tried the one with "game" with no slash a little earlier, and now also the tilde one, and it still doesn't work. Not entirely sure I got those right though as they seem easier to get wrong when you're new to this)

Or even better: copy the commands we post here, and paste them in your terminal.

Whenever possible, I always copy/paste everything into the terminal, to maximize the chance that I get it right.



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)
 

Attachments

Last edited:
So we're basically back to square one again?
Not really, we have new information to work with so we're getting a bit closer to the solution now.

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.
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 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.
I can tell straight away what the problem is. That's why screenshots are important.

None of the paths exist because they're all missing something. For instance, you should've entered "/home/sret/Desktop" instead of "/home/Desktop". "/root/home" should've been "/home/root". The "game" directory (which is actually /home/root/game") doesn't exist yet because you haven't installed the server. Reading about how the directory structure works on Ubuntu will hugely benefit you.

Use getema's tip to open the terminal in the correct folder whenever possible. However, sometimes that won't work - e.g.: when you try to go to a directory that only the root user has access to -, so you can also use my tips to use the tab key to autocomplete paths (try it now), or use the tilde as a variable to the "/home/<your_current_user>". For instance, if you had entered "~/Desktop", that would've taken you to the correct folder.

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.
Let's try this again:
  • Open a new terminal. Do NOT run "su -". Make sure the active user is your standard user "sret".
  • Run the command again without the "su -"
  • If you get an error, paste the screenshot here

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)
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.
 
Back
Top Bottom