Linux: Mount remote Windows shares with smbfs

It’s actually quite easy!

In Debian you will have to install smbfs. Some distros install this package by default. First create a mount point to which we will refer to as /mountpoint from this point forward.
mkdir /mnt/mountpoint

To mount:
mount -t smbfs -o username=<username>,password=<password>,workgroup=<workgroup/domain> //servername/share /mountpoint
If you don’t want to type your password in the comman then don’t. Remove password=<password> and you will be asked to enter it once you hit enter. To use local credentials use the server name in <workgroup/domain> and to use domain credentials use the domain name. Username must match the domain or server you are authenticating against.

You can also mount admin shares. Instead of //servername/share use //servername/<driveletter>$

You can ultimately auto mount remote shares during boot by adding those lines to your fstab, but if your Linux box is not a member of the domain and can’t authenticate mount process will fail unless you have smbfs authenticate automatically. This is not the safest way of auto mounting shares in Linux as you are going to store your password in a text file. As precaution you can make the file accessible to root only.

To do so, add this line to your fstab:
//servername/sharename /mountpoint smbfs auto,credentials=/root/.passfile,uid=1000,umask=000,user 0 0
/root/.passfile is where you will store your network passwords. Create it and add the credentials:
nano /root/.passfile

Then add the following lines:

To make the file readable by root only:
chmod 600 /root/.passfile

Once you’re done with all this, go ahead and mount the shares:
mount -a

Remote share will be mounted automatically after every reboot.

Juniper: Create a policy based VPN tunnel between two sites for NetScreen devices

Juniper devices are my personal favorites. While they are as robust and complicated as Cisco they are being sold at a fraction of what Cisco sells their similar products. We are currently using Netscreen and SA boxes exclusively to provide secure VPN connection between our 20+ offices across the US.

While Netscreen built-in help is quite comprehensive and easy to follow, it does not eliminate the need for a rookie to quickly setup a tunnel between two locations. I am going to cut the extra steps out of these instructions, and assuming you already have it setup and have Internet connection I jump right to the quick and dirty tunnel setup.

Almost all Netscreen devices, even the oldest and cheapest models are VPN capable. Most older models like NS5 have one trust (WAN side) and one untrust (LAN side). From this point forward I will refer to LAN and WAN connection as trust and untrust. Devices like NS5GT have a 4 port router built-in through which you can directly connect multiple computers to trust ports. However, it is also possible to isolate those ports and set them as untrust/trust (default mode), home/work (two home and two work ports to separate work and home networks), dual untrust (redundant WAN), and combined (redundant untrust, two home and one work zones). We will be covering the default port mode which is trust/untrust port mode. I just give you a tip if you decide to setup a home/work zone: once you are done with your tunnels you will have to create policies to allow access from home to work or the other way around!

This tutorial explains a quick and dirty setup to create a VPN tunnel between two NS5GT devices. If I don’t explain an options it means it’s not absolutely necessary for a VPN tunnel, so leave it alone and play around with them once you’ve learned how it’s done. Basics are all the same and can be found in pretty much the same spot on different devices. Here are given values:

Site A:
WAN IP:″ href=”″>
LAN IP:″ href=”″>

Site B:
WAN IP:″ href=”″>
LAN IP:″ href=”″>

Steps are identical on both devices, except when you will have to enter WAN and LAN info. So basically you will have to follow the steps below on both devices. I am going to start with the device installed in Site A:

Expand Policies – Policy Elements – Addresses and click on List.
With Untrust zone selected, click New.
Give your site a name and Enter LAN information for Site B in IP box (Site A for device installed in Site B):″ href=”″> If you don’t know what /24 means simply enter your subnet mask in its entirety ( Leave zone as Untrust and click OK.
Now in Addresses screen, select Trust from pull down menu and hit New. Then enter LAN info for the site in which your device is installed (Site A, Site B for device installed in Site B). Same procedure as step 3 above.
Expand VPNs – AutoKey Advanced and click on Gateway.
Click New.
Give your Gateway a name, enter Site B WAN address (Site A for device installed in Site B):″ href=”″> Leave everything else alone, then click Advanced.
Enter a preshared key. That’s basically a password to secure communications between the VPN devices. This password should be the same for both Sites A and B.
Select your local interface on which your VPN tunnel will operate, which is your WAN port. If you’re not sure which port is your WAN, expand Network – Interfaces and click List. Interface assigned to your public IP is the one you need.
The simplest tunnel will be Predefined, Standard. For more complicated algorithm you can select User Defined, Custom. Since it’s a quick and dirty tutorial we are going to use Predefined.
Click Return to go back, then click OK.
Under the same menu (VPNs) click on AutoKey IKE.
Click New.
Give your VPN a name, like “Site A to Site B”.
You should now see “Site B” in Predefined Remote Gateway box – select it.
Leave everything else in that screen alone and click Advanced.
If you want VPN monitoring check the box VPN Monitor towards the bottom of the screen. Hit return and then OK.

At this point our VPN tunnel is complete. However, to allow access from one site to the other, we will have to create a policy.

Expand Policy and click on Policies.
At top, for “From” field select Untrust and for “To” select Trust from the pull down menus, then hit New.
Give your policy a name (optional).
In Source Address, select Site B from pull down menu (Site A for device installed in Site B).
In Destination, select Site A (Site B for device installed in Site B).
In action, select Tunnel.
In Tunnel, select the VPN name you chose in step 14 above.
If you want to allow bi-directional access, check the box next to Modify matching bidirectional VPN. Leave that box unchecked if you’d like to have a one way policy to allow access from Site A to B, but not the other way around.
If you want to enable logging, check the appropriate box.
Click OK.

w00t… you’re done. Once you complete the steps in both sites you should be able to ping Site B computers from Site A and vice versa!

Linux: Cannot turn on a virtual machine after unclean shutdown – failed to lock the file error VMware Server

I don’t recall the exact error message, but sometime after an unclean shutdown your virtual machines will not start with an error that contains “unable to unlock file”. To resolve the issue simply navigate to the directory where your virtual machine resides, and delete all files with .WRITELOCK and .lck extension.That should remove the lock and make your VM’s accessible. If that didn’t help, go ahead and delete all files EXCEPT .vmdk AND .vmx EXTENSIONS. That should definitely do the trick.

You can actually delete the .vmx files as well but in order to have VMware recreate them you will have to start the “new virtual machine wizard” and use the .vmdk as your disk file. Instead of creating a disk you use an existing.

Linux: tar tips and tricks

To untar a tar file:
tar xf filename.tar

To untar a tar.gz or tar.tgz (gzip) file:
tar -zxf filename.tar.(t)gz

To untar a (bzip) file:
tar -jxf

To untar a tar.bz2 (bzip2) file:
tar -yxf filename.tar.bz2

To view a list of files in an archive:
tar -tzf filename.tar.gz
If the archive contains numerous files and you’d like to be able to view line by line:
tar -tzf filename.tar.gz | more

To untar an archive to a different directory:
tar -zxf filename.tar.gz -C <directory>