10 Creative Ideas For Stronger Passwords

Passwords are the bane of the average technology user. As applications begin requiring stronger passwords they become harder to remember. Hard to remember passwords generally get scribbled down somewhere, stuffed under the keyboard, or stored in a plain text file on the desktop. What good is a strong password if someone finds your hidden scrawlings?

The key is creating a strong password which is easily remembered! But what makes a strong password?

A strong password is measured in entropy. This is a measurement of how hard it would be to crack a password with brute forcing software or to outright guess it. There are a number of elements to measure entropy but the most important element is length. You see, the longer a password is the harder it is to guess or brute force. A longer easy to remember password can be harder to crack than a shorter complex password chocked full of symbols, upper/lower case letters, and numbers. Ideally, a strong password will be a good mixture of both length, numbers/symbols, and upper/lower case letters.

Let’s take a look at 10 creative examples of strong (and long) easy to remember passwords. Use these passwords to generate your own unique password ideas.

1.) Tongue twister password

This is a new take on classic tongue twisters. Take a tongue twister you can remember and tweak the details. It’s important to tweak the details because common place sayings or rhymes are often guessed by dictionary attacks. These are massive files fed in to a cracking program which contain a list of commonly used passwords and sayings.

For example…

“Susy sold seashells by the seashore” becomes “Adam sold apples by the airport”

adamsoldapplesbytheairport

Just like magic you created a 26 character password that’s easy to remember and hard to guess by a computer. You could get more creative by adding a memorable year to the end.

2.) I will never password

Think of something you know you will never do again and make it your password. For example “I will never bite in to frozen blueberries again!”

iwillneverbiteintofrozenblueberriesagain!

3.) First love password

Everyone remembers their first love. It is small sayings like these that are easy to remember and hard to guess! Don’t let your S.O. see this one!

“My first love will always be Grace”

myfirstlovewillalwaysbeGrace

4.) Favorite movie quote password

“Gandalf said you shall not pass!”

Gandalfsaidyoushallnotpass!

5.) The directions password

Think of how you would give someone directions from your house to the main street (or another place close by.)

“Take a left then a right then go straight”

takealeftthengorightthengostraight

6.) The dog password

“I always call my dog by his name fido”

ialwayscallmydogbyhisnamefido

7.) Pet peeve password

Always easy to remember a pet peeve!

“Why do boneheads never use their blinker?”

whydobonheadsneverusetheirblink?

8.) Ingredients password

Think of the ingredients to your favorite dish or cocktail.

“1 box of noodles and 1 package of powdered cheese”

1boxofnoodlesand1packageofpowderedcheese

9.) Spoiler password

Spoil the end of your favorite movie.

“Bruce Willis was dead the entire time!”

brucewilliswasdeadtheentiretime

10.) I hate passwords password

Pronounce your timeless hatred for passwords!

“Why must passwords be so long and hard to remember?”

whymustpasswordsbesolongandhardtoremember?

Conclusion

This should get those creative juices flowing. Next time you need ideas for passwords remember this list!

 

 

How To Setup Email With Google G Suite

Google offers a premium service for their suite of applications called G Suite. Through G Suite you can setup users, domains, and configure email. This is useful when you want a real email address instead of a standard gmail address. G Suite allows administrators to connect their domains to the Google email servers for sending and receiving email.

In this tutorial we will setup and configure Google G Suite to route email for your domain.

To complete this tutorial you need login credentials for your Google G Suite account along with login info for your domain name service provider. This is necessary to setup the appropriate MX records.

If you haven’t already, setup a G Suite account and then login to the admin panel. 

The first step is setting up the domain and verifying ownership. Chances are you have already done this at account creation but if you need to add another domain, follow these steps:

  1. From the main menu select Account and then Domains
  2. Select add/remove domain
  3. Select Add a Domain Name or Alias
  4. Select Add another Domain and enter the name into the field

g suite add domain 3

Google will then ask you to verify ownership of the Domain. You can use any number of the options. Once verified proceed to setting up the user account.

Set up the User Account

  1. From the main control panel select Users
  2. Select Add New User
  3. Fill out the profile information. When prompted for the email address be sure to select the domain you just setup

google admin users

Once the user has been created they have full access to all the Google apps including Gmail. The user can choose to read their email in the Gmail application or opt for a third party program like Outlook or Thunderbird. The email client will need to be setup with the correct server settings to connect to Googles email exchange network. Often times these can be auto detected but sometimes need to be manually entered.

Below are the Google SMTP settings:

  • Incoming mail server: imap.gmail.com (Port 993 / SSL)
  • Outgoing mail server (SMTP): smtp.gmail.com (Port 465 / SSL)

Configure MX records for your domain

At this point your new G Suite user can send mail but cannot receive mail. This is because the domain has no MX records associated with it. MX records tell other servers where to send the mail. To setup MX records you’ll need to login to your hosting/domain providers account and configure the MX records in the DNS Settings.

The process to do this differs depending on your hosting platform. Generally, you will find these settings in the DNS/Advanced DNS section of the control panel.

Here is a snapshot of what this looks like using Namecheap:

g suite mx records name cheap

There are 5 records to create. Set the type to MX, the host to @, and the value to the values you see above and below. The numbers 1 – 10 are the priority numbers and must also be specified.

Google MX records settings

Blank or @ 3600 MX 1 ASPMX.L.GOOGLE.COM.
Blank or @ 3600 MX 5 ALT1.ASPMX.L.GOOGLE.COM.
Blank or @ 3600 MX 5 ALT2.ASPMX.L.GOOGLE.COM.
Blank or @ 3600 MX 10 ALT3.ASPMX.L.GOOGLE.COM.
Blank or @ 3600 MX 10 ALT4.ASPMX.L.GOOGLE.COM.

Troubleshooting

The most common hang up is forgetting to setup the MX records in your DNS settings. Once updated, it can take up to 48 hours to register. The most basic troubleshooting step is attempting to login to the users gmail account. If you can successfully send mail then the account is properly setup but it may take some time for the MX records to update. Your DNS settings will need to fully update before other people can send email to you.

10 Practical Rsync Commands and Examples

The man page calls Rsync a fast and versatile remote and local file copying tool. Rsync is a powerful utility baked into many Linux systems and widely used by administrators for backups. Rsync is famous for its ability to send over only the changed portions of the files resulting in extremely fast copy times. You can make a complete backup just once and future backups will only copy the changed bits. Rsync can copy files to and from a local/remote host as well as between 2 locations on a local host. (Rsync does not support copying between 2 remote hosts.)

To use Rsync, you must have shell access to the remote machine (typically SSH) and Rsync installed on both client and server. When connecting to a machine with Rsync you will be prompted for login credentials unless you have SSH keys setup. Alternatively, the Rsync client can connect to any machine running the Rsync daemon. The Rsync daemon is useful when you don’t want to allow user level SSH access to the server.

There are a lot of options for Rsync but most administrators only use a handful of them. Below are the most popular options.

Options

OptionsDescription
-aArchive mode. Back up recursively and preserve permissions etc.
-vverbose. Increase output to terminal.
-zCompress data before transferring
-rBackup recursively
--progressShow progress bar
--excludeExclude specific files from transfer
--remove-source-filesRemove files from source once data is transferred
--dry-runOutput files to be copied/skipped. Does not actually run.

Examples

1.) Sync contents of 2 folders

At the most basic level Rsync can sync the contents of 2 directories. This isn’t exactly a backup but allows you to explore the basics of what Rsync has to offer.

Here we use Rsync with no options to sync the contents of 2 folders:

rsync /path/to/folder1/ /path/to/folder2/

Pay careful attention to the leading slashes at the end of your file paths. A slash at the end means you want to sync only the contents of the directory. Leaving off the slash means you want to sync the directory as well.

2.) Sync entire contents of 2 directories including sub directories

With no options specified Rsync will only copy files in a directory. By default it does not copy sub directories. The -r switch tells Rsync to copy everything including all directories and sub directories.

rsync -r /path/to/folder1/ /path/to/folder2/

 

3.) Copy everything in archive mode

The -a option is the most popular option to use with Rsync. This option is actually many options strung together. -a is a full archive backup and backs up everything including time stamps, permissions, and modifications. -a is the same as using the options -rlptgoD.

rsync -a /path/to/folder1/ /path/to/folder2/

 

4.) Sync a remote folder to a local folder

Rsyncs true power comes from its ability to securely sync a remote folder to a local folder. Useful for backing up a web server. Here we sync a remote folder called folder1 to a local directory folder2:

rsync -a user@192.168.0.1:/var/www/folder1 /var/www/folder2

 

5.) Sync a local folder with a remote folder and compress before sending

Rsync can compress data before it transfers over the network. This is useful for slow networks but should be avoided if CPU power is limited. Compression is executed with the -z option.

rsync -az /var/www/folder1 user@192.168.0.1:/var/www

 

6.) Do a dry run first

Rsync can tell you what will be copied without actually copying any data. This can provide a visual overview of what is missing in the destination as well as how much data will be transferred. It can also save your bacon especially when using the –delete option! Here we also include the -v (verbose) so we can see the output in the terminal.

rsync -av --dry-run /var/www/folder1 user@192.168.0.1:/var/www

 

7.) Delete files in destination that are not in the source

Sometimes you want to completely mirror a directory and remove extra files. The –delete option tells Rsync to delete everything in the destination that is not in the source. Be careful with this one! If you are accidentally in an empty directory you can completely wipe out your destination files.

rsync -av --delete /var/www/folder1 user@192.168.0.1:/var/www

 

8.) Delete files from source once synchronized

When you no longer need the source files.

rsync --remove-source-files -avz /var/www/folder1 user@192.168.0.1:/var/www

 

9.) Exclude specific files

In this example we exclude every document with a .docx file extension

rsync -avz --exclude '*.docx' user@192.168.0.2:/var/www/folder1/ /var/www/folder1/

 

10.) Show a progress bar

For those who gain deep satisfaction from watching progress bars tick by the screen. Here we use the –progress option to create a nice little progress report of each transfer in the terminal.

rsync -avz --progress /var/www/folder1 user@192.168.0.1:/var/www

8 Practical SCP Commands and Examples

SCP stands for secure copy and makes safe file transfers easy on both Windows and Linux. Linux users can take advantage of the built in utility while Windows users can use free software like WinSCP. SCP uses the SSH protocol to encrypt its data transmissions and requires SSH access. Data transfers can take the form of local to remote, remote to local, or remote to remote machines. Simply provide the SSH credentials and you’re good to go. Similar to SSH, if you don’t have the appropriate SSH keys you will be prompted for a password to login to the remote machine(s).

Options

OptionsDescription
-PSpecify SSH port
-pPreserve time stamps
-qQuiet mode. Do not show progress bar.
-rRecursively copy entire directory
-SSpecify program to be used for encrypted connection.
-TDisable file name checking.
-vVerbose mode. Print debugging information.

scp man page

Here are a few practical SCP examples to start transferring files immediately.

1.) Copy file from a local machine to a remote machine

Here we supply SCP with the local file we want copied and then specify the remote machine and directory. The following SCP command transfers the local file backup.tar.gz to a remote directory on remotemachine.com. Replace remotemachine.com with the domain or IP address of your remote host:

scp /home/user/backup.tar.gz user@remotemachine.com:/var/www/backups

2.) Copy file from a remote machine to a local machine

This is basically the same command as example 1 except reversed:

scp user@remotemachine.com:/var/www/backups/backup.tar.gz /home/user

3.) Copy file between 2 remote machines

Here we copy a file from a remote machine to another remote machine. We supply SCP with the addresses of both machines and where we want to put the file:

scp user@192.168.0.1:/var/www/backup.tar.gz user@192.168.0.2:/var/www/

4.) Copy directory from remote machine to local machine

The -r option must be specified when copying directories. Here we copy the contents of the entire /var/www/ directory to our local machine:

scp -r remotemachine.com:/var/www/ /var/www/backup/

5.) Compress files before transferring

SCP can compress files with Gzip before transferring. This can speed up transfers on networks with very slow connections but can slow things down on faster connections. Extra CPU power must be used for the compression.

Here we use the -C option to transfer a file with compression enabled:

scp -C /var/www/novel.txt user@192.168.0.2:/var/www/

6.) Copy multiple local files to remote machine

You can specify multiple files to be copied:

scp /path/to/file1 /path/to/file2 user@192.168.0.2:/var/www/

Alternatively use the following format to copy multiple files with the same extension:

scp {file1,file2,file3}.txt user@192.168.0.2:/var/www/

7.) Copy multiple directories

The following command copies multiple directories in a folder. Sometimes you don’t want the entire directory, just a few folders in that directory. Here we use the -r option once again:

scp -r user@192.168.0.1:/var/www/\{dir1,dir2,dir3\} /local/folder/

8.) Specify SSH port

Specify the port of the remote machine if SSH is not running on the standard port 22:

scp -P 2244 user@192.168.0.2:/var/www/ /path/to/local/folder/

Installing Lets Encrypt SSL On Ubuntu and Apache (Easy)

Lets encrypt is hands down the easiest way to secure your web server communications with SSL. On Ubuntu the process is simple and the configuration automagically takes care of all the http to https redirects. I’ve used Letsencrypt to secure many WordPress installations running on various Apache based VPS.

1.) add the Certbot repository to the Ubuntu package system:

sudo add-apt-repository ppa:certbot/certbot

2.) Install the package:

sudo apt install python-certbot-apache

3.) Configure an SSL cert and associate it with your domain:

sudo certbot --apache -d yourdomain.com

When asked if you want Certbot to handle the redirects press 2:

lets encrypt https redirect

Success:

lets encrypt success

Troubleshooting

Certbot verifies your domain through the existence of an Apache virtual host. If you do not have a virtual host configuration file you will need to set one up.

Manually Backup and Restore WordPress To New VPS

In this tutorial I’m going to show you how to manually download your WordPress Database and content and put everything on a new server. This is the perfect tutorial if you’re changing hosting providers and want a manual approach to the process. Using Plugins can cause their own set of headaches and knowing this process will enhance your web admin skills. The process is easy and a skilled admin will have this done in 20 minutes depending on the amount of data which needs transferring.

Although this tutorial is geared towards VPS users, users with hosting providers have similar tools available to complete the job. Anyone with access to FTP credentials and a CPanel can follow this tutorial. Hosting companies worth their salt will provide a Cpanel or something comparable.

**Note After this process is complete be sure to update your DNS A records to point to the new server.**

Exporting MySQL Database

The first order of business is backing up your MySQL database. The Database holds most of the crucial information and content related to the site. On a VPS this is easily done via PhpMyAdmin. PhpMyAdmin is available through your hosting providers Cpanel. If you are running a VPS such as an Ubuntu server, PhpMyAdmin is easily installed with the following command:

apt-get install phpmyadmin

Login to the PhpMyAdmin interface:

phpmyadmin login interface
Logging in to PhpMyAdmin

From here select the database you want to export. If you’re unsure of what database to select, check the wp-config.php file at the root of your WordPress installation on the server. This file will provide you with the username, password, and database name of the site. Once exported you have an SQL file containing the entire database. This same file will be used later in the import process.

Selecting the database we want to export
Selecting the database we want to export

Select Export:

phpmyadmin export database
Exporting the database

Now you want to download the WordPress files. The WordPress files contain certain content like images and configuration files necessary for the overall functioning of WordPress. This is easily done through software such as FileZilla or WinSCP. For this example I will use WinSCP since I have SSH access to the server but this can also be done with FileZilla in the case of FTP. SSH is a much more secure method of transferring files to and from the server and recommended over FTP.

Use your remote login credentials and navigate to the root folder of the website and download all the WordPress files:

win scp download
Downloading the WordPress files off the original server with WinSCP

With the SQL database and WordPress files you can now configure the new server.

Setup New Server

First ensure the appropriate software is installed on the VPS. At the bare minimum you need the latest version of Apache, PHP, MySql, and PhpMyAdmin. Many VPS companies offer one click installations of these services but they can also be manually installed.

The LAMP Stack is easily installed on Ubuntu systems with the following commands:

apt-get install apache2

apt-get intsall mysql-server

apt-get install php7.2 libapache2-mod-php7.2 php-mysql

apt-get install phpmyadmin 

Creating The New WordPress Database

Now you must create the new database and import the the SQL file you downloaded from the old server. Keep all the credentials the same if you don’t want to edit your wp-config.php file.

Login to PhpMyAdmin with the credentials you specified during the MySQL server installation and create the database:

Create the database:

phpmyadmin create database

Import the SQL file you downloaded from the original server:

phpmyadmin import database

That’s all you need to do as far as the database is concerned.

Uploading WordPress Files To Server

Using your preferred file transfer method upload all the original files from the old server to the root www directory.

You should now be able to successfully login to WordPress on the new server.

Troubleshooting

Most common issues are troubles connecting to the database. Ensure the database credentials match those found in your wp-config.php file. Also be sure to redirect your DNS records to the new server.

6 Reasons Your cron Job is Not Running

cron-not-running

cron can be a real S.O.B. to setup if you’ve never scheduled a job before. The utility is downright nitpicky at times. Not to fear. If your cron job is not running, here are the top 6 most common hang ups you might be snagging on.

1.) Wrong environment

Your user account operates under a specific environment where you have a direct path to the programs and utilities you need. cron operates under a limited path and does not always have access to the same programs. Your PATH is one such environment variable that tells the shell where to look for executable programs. If you’re trying to use a program that isn’t in your path, the shell will return error. In the case of cron, your job will simply not run.

You can see if this is the case by comparing the cron environment to your user environment. Plug this small line of text into your crontab and take note of cron’s output in /tmp/path.txt

* * * * * env > /tmp/path.txt

Compare the contents of path.txt with your current environment and you will see a big difference in where cron searches for executables. Run the following command to see your current path.

echo $PATH

Solution – There are two things you can do in this case. The first involves using absolute paths in your script. This ensures cron has a complete path to the program you’re running:

/usr/app/command -x take-over-the-world-pinky

Alternatively, you can set your path at the top of your script like so:

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

This will give cron direct access to your program. Either way, you should be good to go.

2.) Your scripts aren’t owned by root

From the man page:

cron-man-page

If you’re placing scripts inside one of the /etc/cron.* directories, the scripts must be owned by root. If root does not own the script then cron will simply skip over it entirely. Many users choose to place scripts inside of these folders to bypass the finicky requirements of their own crontab. Rightly so, but even here you will find cron to be relentless with it’s requirements. Make sure your scripts are owned by root so things go smoothly.

3.) Your script names aren’t formatted properly

From the man page:

Once again, we see cron putting his foot down until the people around him fall in line with his unique perspective on reality. Your script cannot contain any special characters when placed into one of the /etc/cron.* directories. A common practice is appending your script with the .sh file extension. This is a no-no for cron. As you know, Linux does not require a file extension and your script will run just fine without one. Do what cron says and you will be a happy admin.

4.) Your cron script is not executable

An obvious one to some. Not so obvious to others. Your cron script must have executable permissions in order for cron to run it. Use the following command to make your script executable if it isn’t.

chmod +x /path/to/script

Executable scripts make cron very happy.

5.) Incorrect permissions

Permissions are a very common problem especially for commands placed in crontab. crontab runs under the permissions of the crontab user. If you don’t have proper permissions under your user, cron is not going to have the proper permissions either. Always run your script or command prior to scheduling them with cron. If your commands don’t run or error out with access denied errors, you know you need to make adjustments. If your script or command absolutely requires root permissions, then create a crontab as the root user of your system.

6.) cron daemon not running

The last and most insidious reason why cron is not working. I’ve racked my brain for hours trying to figure out why a cron script wasn’t working only to find out the daemon itself wasn’t even running. You can verify whether or not cron is running in a number of ways.

pgrep cron

cron is running if you see a number. cron is not running if you don’t.

cron-pgrep

service cron status

Easy way on Debian systems to check the status of cron.

check-cron-status

Conclusion

These are 6 of the most common reasons why your cron jobs are not running. Run through this list next time cron refuses to do what you tell him to. Eventually, cron will start to see things your way and will do as he’s told.

 

 

Linux cron job Tutorial

linux-cron-job

Cron is a Linux utility that lets you automate tasks on a schedule of your choosing. A Linux cron job is the perfect way to automate backups or other repetitive tasks. Cron comes with all versions of Linux and functions mostly the same across different distributions.

How cron works

Cron works by reading through a number of configurable text files and then reading commands into memory. Every minute the cron daemon crawls a special spool folder on the file system that contains a crontab for each user on the system. When cron runs across a crontab with a scheduled job it loads the job into memory.

Types of Linux cron jobs

There are 2 types of cron jobs. System wide jobs are cron jobs configured through /etc/cron and the directories /etc/cron.hourly /etc/cron.daily /etc/cron.weekly and /etc/cron.monthly These jobs are ran under the root account and have full access to the system. User jobs are cron jobs scheduled by standard user accounts and configured through crontabs. For security reasons it is recommended to schedule your jobs through your own crontab unless the task must be executed as root.

How to schedule a cron job

There are 2 ways to schedule a Linux cron job. The first is to simply drop a shell script into any of the directories mentioned below:

/etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Shell scripts in these directories must be executable, owned by root, and adhere to a specific set of filename restrictions. From the man page:

As described above, the files under these directories have to be pass
some sanity checks including the following: be executable, be owned by
root, not be writable by group or other and, if symlinks, point to
files owned by root. Additionally, the file names must conform to the
filename requirements of run-parts: they must be entirely made up of
letters, digits and can only contain the special signs underscores
(‘_’) and hyphens (‘-‘).

The second way to schedule a cron job (and the preferred way) is to edit your users crontab:

crontab -e

This opens up the crontab for the currently logged in user. Here, all cron jobs scheduled will be executed under the user who created it. You will see a number of lines with the proper crontab format at the bottom. This is where you schedule your job. You can drop in a direct command to run or give the path of an executable shell script. Here are a few examples:

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/script

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*

Make the appropriate edits and then save the file. Don’t worry about reloading or restarting cron. The daemon automatically checks for changes every minute.

Troubleshooting

Cron is drop dead simple once you understand the format. However, there are a few things that can hang up a cron job if you aren’t careful. Here are a few:

1.) Your scripts aren’t executable

All of your scripts must be executable in order for cron to run them. Go back and make sure all of your cron scripts have the +x permission configured.

2.) Your scripts aren’t owned by root

If you’re dropping your scripts into /etc/cron.hourly or any other cron folder, they must be owned by root or cron won’t run them. Make sure your scripts are owned by root and the proper permissions are set.

3.) Your scripts contain characters that aren’t allowed by cron

Similar to point number 2, your cron scripts won’t run in the /etc/cron.* folders unless they conform to a specific format. It’s usually a period that trips people up. Remove the period and your scripts will magically start running. Refer to the quoted man page above for more information.

4.) Wrong format

It’s easy to make a mistake in your crontab. You might think you’re running a script at one time but the format you gave cron doesn’t match up. Go back and make sure you have a clear grasp of the cron format and understand how to implement it into your crontab.

Conclusion

cron is a picky S.O.B but performs well once you can get him running. The nice thing is, once you have cron configured it will run like a well oiled machine for the rest of your days. Let me know what you think about cron in the comments below.

 

 

 

Crontab Format Explained

crontab-format

Cron is a built in Linux utility that allows you to schedule jobs called cron jobs. You can schedule cron jobs to run hourly, daily, weekly, monthly, yearly or any sort of variation in between. Cron is configured through a specialized text interface called the crontab. The problem is that the Crontab format is a little confusing until you become acclimated to scheduling out jobs. Let’s take a look:

* * * * * /path/to command

Each * represents a time slot. Using the table below you can see that each * represents varying measurements of time:

*****
MinuteHourDay of the month (1-31)Month (1-12)Day of the week (0 - 6 where 0 = Sunday)

crontab format examples

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/command

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*

Conclusion

Is it all coming together now? Practice some examples of your own to really get the hang of it. Pretty soon you will be using anything as an excuse to bust out your crontab for a quick scheduling. Let me know in the comments if you need help.

 

Samba File Sharing Configuration and Tutorial

samba-file-sharing

Samba file sharing allows a competent system administrator to configure a Windows-like network share on a Linux system. These shares are accessible by Windows computers and other SMB clients. Samba is software that makes it easy to exchange data with Windows operating systems.

What is Samba?

Samba is free software for Linux that implements SMB like functionality into the system. SMB is the dominant file sharing protocol used on Windows systems. By recreating this functionality, Linux systems can integrate into a Windows environment and function as both a client and/or a server. The software includes a dozen core services to make this possible.

Samba file sharing HOWTO

In this samba file sharing tutorial I will show you how to setup a Samba share with basic user access controls. You will learn to share a folder with read/write access and grant permissions to select users on the network. A mapped network drive on the Windows machine will serve as easy access to the Samba share.

This is a basic process that involves installing the Samba file sharing software and making a few configuration changes to the configuration file.

Installing Samba

Samba may or may not be installed on your system. Here are a few ways to install the software on various Linux distributions.

Debian/Ubuntu

apt-get install samba

CentOS

yum install samba samba-client samba-common

Arch

pacman -S samba

By default, the Samba configuration file is located at /etc/samba/smb.conf and comes extremely bloated. I always delete the contents and start fresh with only the configuration directives I require. If this scares you, make a backup of smb.conf first:

cp /etc/samba/smb.conf /etc/samba/smb.bak

The following configuration file will grant your username full access to your home directory on your Linux box. Copy and paste the contents below straight into the smb.conf configuration file. Be sure to substitute your own parameters on each line.

[global]

# Copy this into your /etc/samba/smb.conf configuration file

workgroup = WORKGROUP
netbios name = SAMBA
security = User

[data]
path = /home/user/
valid users = username
read only = no
create mask = 0777

There are a few parameters here worth mentioning.

workgroup should be the same name as the workgroup your Windows machine is on. The default Windows workgroup is called WORKGROUP, conveniently enough. You can verify this by going into your system properties.

netbios name is the name your Linux box will present to the network. Essentially, this is the name that will show up when you browse the network for connected hosts.

security is a setting used to determine how a particular share is accessed. In this case, we only want to grant permission to users that exist on the Linux system.

[data] is the name we are specifying for the share.

path is the absolute path of the folder we want to share to the network

valid users specifies what users should have access to this share. All other users not on this list will be denied access.

read only = no makes this share writeable by the users.

create mask sets the default permissions for this share. In this case, we grant full permissions to the owner of the files while completely denying permission to everyone else.

That’s all there is to it. Save the configuration file and then reload the Samba configuration:

service samba reload

The last thing we need to do is create a special Samba password for your user:

smbpasswd -a user

Your share should now be accessible from any Windows machine on the network. You can access the share by specifying the UNC or by browsing the network via Windows Explorer. Double clicking the share will prompt for a username and password. Plug in the credentials of your Linux user and click OK.

samba-file-sharing

Once logged in you will see the share you set up in the Samba configuration:

samba-configuration

Nice!

Troubleshooting

Problems with Samba are usually caused by incorrect configuration settings, permissions, or service related issues. A good starting point if you’re having problems connecting to your server is to check the Samba service status:

service samba status

Is the service running? If not, you’ll have to find out why.

Next, make sure there are no typos in your Samba configuration file. A single typo can throw off the whole server. Comb through your /etc/samba/smb.conf and make sure all your directives are correct.

Access denied problems can crop up if your permissions aren’t set correctly or you failed to set an smbpasswd for your Linux user account. Make sure the account you specify in the Samba configuration is active on the system and that you created an SMB password for the user. Re read the sections above for instructions.

Conclusion

Samba file sharing makes it easy to exchange data in a Windows dominant environment. You can see how easy this was to quickly get a file server up and running. Once again, Linux proves itself to be a very capable server operating system. Best of all, the software is free! This tutorial covered a very small aspect of Samba. If you’d like to learn more about Samba and its full capabilities, check out the official documentation or run through the man page.