I am trying to use a VM to allow me and some other people in the company to test-drive changes to a Magento store. The VM is out of my control (mostly) and is hosted on a Windows Server box on our intranet. I don't know the version details or the actual VM used, but I can probably get this info if needed. I created an Ubuntu VM, installed Magento (v1.8). I backed up from my web store and restored to this VM. It all works (good enough for what I'm doing) if I stay within the VM.

The problem is that I cannot access the store hosted on the VM from outside the VM.

The location /var/www contains the default apache index.html. The store is located at .../var/www/magento

If I just point a browser (from outside the VM) to the IP address of the VM I get apache's default index.html. If I look into the apache access.log I see the normal messages you would expect to see. Great! If I point the browser to "/magento" I get the VM hosts' IIS default web page! The apache access log shows that it returned some redirection (301, 302) error codes (I am not very familiar with this).

Oh, and I did try moving apache's DocumentRoot to /var/www/magento and got a host of other problems, so I put it back.

If this is a problem with the VM host, can you give me pointers so I can get the proper people involved? What am I doing wrong?

apache2ctl -S output (server names masked):

VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80                   is a NameVirtualHost
         default server example.com (/etc/apache2/sites-enabled/000-default:1)
         port 80 namevhost example.com (/etc/apache2/sites-enabled/000-default:1)

Output of cat /proc/version:

Linux version 3.2.0-77-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #112-Ubuntu SMP Tue Feb 10 15:22:48 UTC 2015
  • Does your VM have it's own dedicated IP address in the network or is it sharing the IP address of the host server?
    – Oldskool
    Mar 5, 2015 at 14:37
  • It has it's own IP address.
    – GeezerGeek
    Mar 5, 2015 at 14:43
  • You mentioned you backed it up from your system and then restored it to the VM. Is it possible that Friendly URL's and rewriting is interfering? URLs: kb.siteground.com/enable_friendly_urls_in_magento and possibly an additional rebuild requirement: magento.stackexchange.com/questions/8873/… . A weird thought...if it is rewriting...I hope it's not actually visiting IIS on another computer, such as where it was backed up from. Mar 22, 2015 at 3:34

3 Answers 3


I do this all the time for work successfully on different OS / VM / Server combinations.

There doesn't seem to be anything wrong with your Apache itself so ignore the Apache config for now. You need to test the entire network path and think about how a request will travel across the network from your coworkers' computer to your Apache process. Generally, the request will go:

Coworker -> Corporate Intranet -> Your Host OS -> VM Software -> VM Guest OS -> Apache

Subdividing the network topology is the first step in solving your problem because you have to find where a request is getting blocked. Here are some instructions for doing this:

  1. Starting w/ the corporate intranet your Host computer sits on, make sure your coworkers can physically access your machine at your intranet IP. Find your ip address using ipconfig /all (windows) or ifconfig (linux). From another computer, use the ping tool to see if your computer is reachable. Do not proceed to step 2 until you figure out how to reach your computer from another via ping.

  2. I understand you can reach http://[guest-ip-address], but can you access your VM website from If you can't, see Step 3 to configure the VM software that runs the VM. Otherwise, continue to Step 4.

  3. VM software manages a virtual network layer between Host OS and Guest OS. It will likely have a NAT port forwarding system that can translate TCP traffic between Host port 80 and Guest port 80. However, port 80 is often protected by supervisor privilege at the Host OS level. This makes it a bit tricky to tell the VM software to bind port 80, so I recommend using port 8080 instead because it is unprotected. Setup NAT Port Forwarding between Host port 8080 and Guest port 80. Verify you can reach your web site @ You maybe be tempted to set Apache to use port 8080, but that is not necessary. The VM software running your Guest OS can translate Host port 8080 to Guest port 80. Play with VM network configuration until you get

  4. Verify you can hit your web server from your Host OS @ http://[your-host-ip]:8080. If you can't, check to see if you have a firewall running on your OS. Start by disabling it completely temporarily, and test again. If you still can't hit the web site, go back to Step 3. If you can, re-enable the firewall but be sure to give your VM software an exclusion, or open port 8080.

  5. Verify you can hit your web server from your the site from another computer on your coporate network @ http://[your-host-ip]:8080. If you can't, there may be a corporate firewall between you and your coworkers. Bummer. It could also be your OS firewall, do Step 4 again.

By the end of this, your coworkers should be able to reach the site running on your VM.

  • I confirm steps 1 and 2. As for the port forwarding (step 3) I will have to contact our IT guys as the Host is not under my control. And Thanks!
    – GeezerGeek
    Mar 20, 2015 at 16:35
  • To be clear, the "Host" is your own computer. The "Guest" is the VM. In step three, you don't really shouldn't need any kind of IT permission to change the VM software's configuration. It doesn't actually change the Guest VM at all.
    – thesmart
    Mar 20, 2015 at 18:32

Well I found out part of the answer.

It's not a problem with networking. I used a packet sniffer to find out that the redirect issued from apache contains the address "localhost/magento", so my web browser dutifully queried my own Windows machine which returned the IIS error page, not the VM's Host's IIS. One mystery solved.

Following the lead of @RVT I used telnet and netcat and was able to GET individual files from the site.

I then re-installed a fresh copy of Magento and noticed that the default location that Magento installs to is the folder /var/www/magento. For other reasons I remember that I installed the original to /var/www. So there was some mis-match between what magento wanted for the root folder and what I installed it to. The re-install (to .../magento) works perfectly.

The real answer probably has to do with changes to Magento's System->General->Web->Unsecure Base URL settings, and also maybe the System->General->Web->Url Option settings. For completeness when I find out I will update this answer.


Since I can't (yet) comment to ask more illuminating questions, I'll have to post this as an answer...

First off, make sure you're VM has a bridged connection... in short, its own IP address on your local network segment. From your description, it sounds as-if it's either behind a shared or proxied connection, and your VM server may be serving up its own IIS service.

Additionally, it'd be useful to see the logfiles from the VM's apache server... the 3xx messages are important (ie. it basically means that the VM is sending your traffic elsewhere - could it be that it's redirecting back to the VM server, itself?).

Lastly, you might try coming in from both the VM and from an external host... you can telnet in to port 80... and issue commands similar to:

GET /magento HTTP/1.0
Hostname: yourhost.domain.com

Note that you should translate yourhost.domain.com in to the name of the server, and use a double linefeed/carriage return following the hostname line (ie. the \r\n). The most important part of the return message should follow that request (ie. the Apache headers). That should be pretty illuminating as to what the server is actually doing, here.

  • For a new user, you show some good attitude here! However, let me guide you to always use the example domain names specified in RFC6761. Please read more on obfuscating information in ServerFault. Mar 21, 2015 at 23:22
  • Thanks @EsaJokinen... the funny thing is, I know better than that, and must have just not been thinking too much. I'll do better next time (FWIW, I'm not "new" by any stretch of the imagination - I'm just less prolific... which excuses my flub even less). /blush
    – RVT
    Mar 23, 2015 at 20:47
  • I gave you the bounty because it was your answer that led me to solve the problem. Thanks!
    – GeezerGeek
    Mar 25, 2015 at 20:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .