Ok so I'm new here, and relatively new to Linux - I don't know most of the commands or what they do.

However, I have a scenario, running Ubuntu 12.04, where I'm running it as a VM under Xen (EXT3) for a specific server purpose.

It was no easy task to get this to go, even with the Xen templates - before I recreated the Ubuntu VM using EXT2 it would not survive a reboot - Grub issues that I could never get resolved. That's water under the bridge; as now I have it working properly in that respect.

Anyhow, I swiped a backup script that does work well running it from the bash shell.

I created a file in /etc/samba called user, in which I created two variables called username and password, which match (obviously) those on the Windows box.

I modified /etc/fstab to reflect the Windows SMB share with the line

# MY SAMBA SHARE MOUNT TO DESKTOP nnn.nnn.nnn.nnn
//nnn.nnn.nnn.nnn/XS_Backups /mnt/backup cifs credentials=/etc/samba/user,noexec 0 0

*-as I understand it, the /etc/fstab is scripted to run on restart/boot of this VM. It should, in theory, mount the Windows SMB share to the mount point /mnt/backup... Please correct me if I'm wrong.

---

I placed the backup script into the folder /root/nightlybackup. It's a bash script.

I modified the /etc/crontab to reflect when I wanted this bash script to run:

00 3 * * * bash /root/nightlybackup/UBUNTUBACKUP.sh
MAILTO=xxxx@xxx.xxx
#

Now the problem is I don't see the backup running. I can run it when I do so with the command

sudo bash /root/nightlybackup/UBUNTUBACKUP.sh

But there are times when I attempt to run this and the job hangs for quite some time, and comes back (I forget the syntax) telling me that the mount point /mnt/backup is not accessable) and it fails.

I thought that somehow there was a disconnect (Windows box goes to sleep, etc - I'm sure that the Windows box has a static IP so that should not be the problem) and so I modified the backup script to mount the backup share before it runs.

...
# Where to backup to.
sudo mount /mnt/backup
dest="/mnt/backup"
...

When I get a fail on the backup script when I run it manually, I then manually enter the following commands:

sudo umount /mnt/backup
sudo mount /mnt/backup

Then I run the script. It success then is 100%.

So the question is - why is the mount failing to persist, and why is the cron job not running?

I really appreciate any help here.

Tyvm.

Normally, sudo will require a password before it executes anything with privileges.

You should be getting mail with whatever errors are being reported. There should also be some syslog error messages about mount failures, though I suspect the ones from the cron job are password failures.

If you are using a recent version of Ubuntu you are likely using systemd for the init.

This may be having a problem in that by its nature, systemd doesn't wait for things to be ready - it assumes they are. If you are also using NetworkManager, then make sure you ALSO have NetworkManager-wait-online enabled. Without it, network manager doesn't tell systemd the network is ready, and systemd won't wait for the message - thus allowing other processes to be started (such as chron) before the network is available. This also affects any network mount failures.

Thank you for your response.

I did get it working, but I don't know what the difference is between editing the /etc/crontab file manually versus editing (another copy?) crontab via: sudo crontab -e

When I edit the crontab file via sudo crontab -e, and I write out the changes, it apparently is writing to a temporary file/folder.

What is the difference between the two methods? Obviously, one works and one does not. But what is the purpose of the /etc/crontab file if not used to actually schedule tasks? Why does it exist?

I also modified the bash script to first unmounts and then mount the mount point;

sudo umount /mnt/backup
sudo mount /mnt/backup

What I don't understand in your post are:

SystemD - what is it?
NetworkManager - what is it? Where would I be editing it?

Thanks again!

sudo changes user first. Then it will edit whichever login is associated with the command.

Using crontab -e will edit the logged in users crontab entry, and update the chron service with the update.

Personally, I prefer to keep a copy of the crontab externally to chron, and make updates there, and resubmit. That way I still have a copy if the system changes/updates and no longer has the entry.

The sudo on the mount/umount is not necessary if the filesystem is identified to be mounted by the user.

Systemd is an init system. Whether you use it or not depends on the distribution, and how recent it is. Ubuntu 12 is using systemd. Systemd makes many assumptions about how the system should work... (too many IMO)

NetworkManager is a service used to control network configurations, user network activations, and other such. Due to its complexity, there is a tendency to unreliability. When combined with systemd it tends to be unreliable due to the nature of systemd. Part of the problem is that systemd assumes a service is immediately available the moment it starts a service. A number of services (like NetworkManager) take several seconds (to minutes) before they are ready for dependent services to be started. NetworkManager is one of the slow ones. It is supposed to initialize networks - but unless the special target "NetworkManager-wait-online" is enabled, systemd will not wait until the network is usable before starting services that depend on the network - and they fail, usually. I say usually because systemd uses a thundering herd scheduling approach that starts any service that doesn't have a specific order. Since the specific order for network services is when systemd has started NetworkManager (whether the network is actually usable or not). If there is enough of a scheduling delay caused by other service startups and the time the network is actually available, then it can look like it worked.

I no longer have an Ubuntu installation (other testing on going), so I will refer you to the Ubuntu documentation:

https://help.ubuntu.com/