Windows 7: "Access Denied" on the Command Line When Using FIND

I tried to run a FIND command in the CMD (sometimes called the DOS) box in Windows 7.  I got an error message:

Access Denied - D:\FOLDER\SUB FOLDER

This was bizarre.  I had been using the command line in this Win7 installation for months.  Well, something had apparently changed.  I got this message regardless of whether I used my pre-installed "Open Command Window Here" right-click option in Windows Explorer or the Administrator Command Box option I had created in the Start menu.

A search led me through various possible solutions.  I tried especially to tweak the permissions for the entire partition and for the individual folder via right-click > Properties > Security tab > Advanced > Owner tab > Edit > select Administrators and check "Replace owner on subcontainers and objects," and to play with other tabs and settings in that vicinity.

One option I hadn't seen previously was to open the Local Group Policy Editor (Start > Run > gpedit.msc) and go into Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > right-click on "User Account Control:  Behavior of the elevation prompt for administrators in Admin Approval Mode" > Properties > Elevate Without Prompting.  But I already had that selected.

That writeup raised the question, though:  had I not completely disabled User Account Control (UAC)?  As advised, I went into Start > Run > Regedit and navigated to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System.  There, I right-clicked on EnableLUA and verified that the value was zero.  Nonetheless, I exported the tweak, extracted the relevant lines from the REG file, and added them to my Win7RegEdit.reg file for future installations, just to be sure.

When I was in Permissions (via Windows Explorer folder right-click > Properties > Security tab > Edit), I noticed that the permissions checkboxes were checked but greyed out.  I couldn't change them.  Was I somehow not in the right account?  A search led to a proffered batch file (Permissions.zip) that read as follows:

@echo off
title File/Folder Permissions
echo.
echo.             BY KAOS - Windows 7 Forums
echo.
echo.
set /p a=Enter Path Of File/Folder:
echo.
set /p b=User Name:
echo Type "deny" = remove access OR type "grant" = allow full access
set /p c=Permission Type:
echo.
echo.
echo.
if %c%==deny goto lock
if %c%==grant goto unlock
if %a%==menu goto start2
if %b%==menu goto start2
if %c%==menu goto start2
:lock
cacls %a% /e /d %b%
cls
exit
:unlock
cacls %a% /e /g %b%:f
cls

The gist of this batch file seemed to be that I could try a CACLS command of this form:  cacls [folder path] /e /g [username]:f, where /e meant "edit," /g specified the user, and :f gave full control.  So, in my case, what username would I use?  Control Panel > User Accounts said that I had set up my system so that the only options were Ray (Administrator) and Guest (turned off).  Maybe this was the problem:  I had been thinking in terms of the Administrator account rather than the Ray account.  So, OK, I tried typing this on the command line, to grant full control to the whole drive:

cacls D:\ /e /g Ray:f

In response to that command, I got a short message:  "processed dir: D:\.  Did that mean champagne?  I retried the command that had given me the "Access Denied" error.  No, still denied.  Alright, how about same command, different user:  Administrator.  Same output.  Still denied.  Baffling!

I ran across a post that said something about turning off simple file sharing and permissions, and then permissions.  It raised a question:  was there a way to reset permissions to the default, and start over?  For the drive (i.e., right-clicking on D: in Windows Explorer), I went into Share with > Advanced sharing > Sharing tab > Advanced Sharing.  I unclicked Share This Folder > Apply.  I got a note indicating that I had some files currently opened, and they would be closed.  I clicked Yes > OK > Close.  This, in itself, didn't have any effect on another try of the FIND command; still denied. 

I had recently gotten an indication that the Recycle Bin on drive D was corrupted.  I had said go ahead and empty it.  That message had recurred.  I had also been getting bothersome messages when I tried to move or delete folders, telling me that these folders were shared and confirming that I really wanted to do what I had said I wanted to do.  It seemed that these problems might be related.  But how, and what could I do about it?

I found a Windows XP article from 2002 that said, "If you don't have a thorough understanding of the various permissions and their relationships, it can be nearly impossible to sort out a permission problem and find a solution."  So I could see how Windows 7 was a direct descendant from Windows XP:  both could make it impossible to get any work done.  The article said that there was a difference between sharing permissions and NTFS permissions, and that the more restrictive one wins.  So if I wanted to grant full control to everyone for everything, I had to do that in two different right-click > Properties tabs:  the Sharing tab and also the Security tab.  But it really looked like I had done that, over and over again.

Ah, but now I saw a new problem.  In the Security tab, I saw that I had a little red circle with an X in it, next to the Administrator group.  There was no right-click option to explain it.  I guessed that the problem was that I had entered the wrong CACLS command, regarding Administrator rather than Administrators (plural).  So that was interesting.  I clicked on Edit, selected Administrator, and clicked Remove.  Then I re-ran that CACLS command with a reference to Administrators, this time, instead of Administrator.  But still no joy on my FIND command:  Access denied.

So anyway, as I was saying, it did seem that I had given full control to almost everyone listed in the Security tab.  I mean, literally, Everyone:  I had an entry for them, and they had full control, and so did SYSTEM, Ray, and Administrators.  But not Authenticated Users, and not plain old Users.  Who the hell were all these people, anyway, and why did we all need to have so many kinds of access to my computer so that I could get work done?  (Sigh.)  Wiser minds knew; I did not.  Anyway, I went ahead and gave full control to my whole world to everyone and his brother, Users and all.  And still the godforsaken command did not run.

And, by the way, at this point I searched in vain for those greyed-out permissions boxes I had seen earlier.  Evidently I had altered something significant, in all this screwing around.  Not so significant as to actually let me get any work done, but significant certainly in the sense that I could no longer detect greyness when I searched therefor.  Not in the Security, nor back in the Sharing tab.  Speaking of which, I now saw that my reestablished share of drive D now had permissions only for Everyone.  Did Everyone include me and all the other Administrators and Users and Authenticated Users of my home system (I was living alone), or did I need to add the whole gang back to my computer?  Not sure.

It occurred to me that I did have a solution.  It was called System Restore.  But, alas, the mere fact of telling Windows to keep system restores, accompanied by weekly checking to make sure that the task was really running as scheduled, did not necessarily mean that I would actually have recourse to any system restore points, other than the one created that very morning.  Apparently Windows was not content with the 10GB of disk space I had set aside for this purpose.  Fortuitously, I did have an Acronis drive image from a week or so earlier, and so, without further ado, I wiped the drive and restored that.  Did there exist any further difficulty?  Yes, there did.  My Acronis backup was too recent.  Apparently this problem had lurked for days and/or was not only, or primarily, a matter of drive C (stored in Acronis) as distinct from drive D (not backed up in Acronis).

I tried a different command that, I knew, I had run within recent days:  DIR.  It ran.  Now, why would DIR run and FIND not run?  FIND took a look inside files; were my permissions of some type not reaching into the files?  I right-clicked on the files in question.  They didn't have sharing or security options collectively; I had to click them one at a time to get a Security tab.  It said everyone had full control.  The Advanced > Owner tab option said the owner of at least one file was Administrators.  Anyway, the CACLS command was supposed to take care of user accouint issues.

I tried the same FIND command on another computer of virtually identical configuration.  It, too, provided a FIND error.  A search led to a brilliant insight:  my command was wrong.  I was trying to use FIND on a directory, when it only works on files.  I had to make one change:  I had to add a star (asterisk) to the end of my search.  The FIND command worked without error when I did it this way:

find /i /c "X-Message-Delivery:" "D:\Folder\Sub Folder\*"

Solution:  operator error.  Case closed.

Windows 7: A Futile Attempt to Move the Fonts Folder

In Windows 7, I tried to move the C:\Windows\Fonts folder to another location.  I did it because I didn't want to lose fonts, if I decided to install additional ones.  At the default C:\Windows\Fonts location, they wouldn't survive reinstallation of the system.  An alternative was to save copies of additional fonts at a different location and copy them to C:\Windows\Fonts after installing a new system.

I found no guidance on this process of moving the Fonts folder.  I copied everything from the C: folder to the X: folder.  Then I searched the registry, changed the references in my .reg file to the new location (X:\Cache\Fonts) in the two locations where I found references to C:\Windows\Fonts, and ran the reg file.  The system rebooted without a problem.  I tried to delete C:\Windows\Fonts, but that gave me a message:

Folder Access Denied
You need permission to perform this action.
You require permission from TrustedInstaller to make changes to this folder.

I searched on that and found advice to go into right-click Properties > Security tab > Advanced > Owner tab.  There was no such tab for C:\Windows\Fonts, but there was for C:\Windows.  I went to Edit, changed it to Administrator, and checked "Replace owner on subcontainers and objects."  When I clicked Apply, I got another message:

Windows Security
You do not have permission to read the contents of directory C:\Windows\CSC\v2.0.6.  Do you want to replace the directory permissions with permissions granting you Full Control?
All permissions will be replaced if you press Yes.

The answer seemed obvious, and that made me suspicious.  I searched on that and saw that Microsoft advised to just go ahead with this, in a couple of contexts, so I did.  It took a while to change permissions for everything in C:\Windows.  Next, I got a message telling me to close and reopen properties to see the updated situation, so I did that.  Still looking at Properties for C:\Windows, I went into Security tab > Edit.  I highlighted Administrators and then clicked Allow for Full Control.  Now I got a message saying, "You need permission to perform this action" -- permission from Administator, which I was.  I found other advice that seemed to recommend these two commands:

takeown /f C:\Windows\Fonts
cacls C:\Windows\Fonts /G Administrator:F

But when I then tried to delete, I got another error message:

Folder In Use
The action can't be completed because the folder or a file in it is open in another program.
Close the folder or file and try again.

Not surprising, since the system itself was obviously using fonts, though it would seem like it could have been just as happy using them from X: as from C:.  I thought I had rebooted since making the registry change, so this time I booted into Safe Mode and tried the deletion there.  No joy.  I selected all fonts and tried deleting them individually, and that got me down to a selected core of 81 fonts, including essentials like Sylfaen Regular and Utsaah.  I was tempted to boot into Ubuntu and wipe out the Fonts folder that way, but instead I gave up:  I went to X:\Cache\Fonts and copied all of the fonts back to C:\Windows\Fonts.  I couldn't remember exactly how many there had been, but the count didn't seem the same, so I rebooted into Normal mode to run System Restore.  My hunch was correct:  some fonts were not displaying correctly.  After System Restore, all was lovely, so I moved on to the next part of my life.

Ubuntu 10.10: Error: Could Not Update ICEauthority File

When I was booting a new Ubuntu 10.10 installation, I got an error message, "Could not update ICEauthority file /home/ray/.ICEauthority." I clicked through that, checked Update Manager, and rebooted. The ICEauthority error message was there again.

Seeking answers to this problem, I ran a search and tried the suggestion to type Ctrl-Alt-F1 to get a text console. There, I hit Enter to get a login prompt. I logged in with my username and password, and this gave me a regular command prompt. I typed "sudo chown -R ray:ray .ICEauthority," where ray was my username. Then I typed "sudo /etc/init.d/gdm restart" to go back into the Gnome GUI. But the ICEauthority error message was still there. (From another post, it appears I could have just entered the chown command in Terminal, without Ctrl-Alt-F1.) People for whom this approach worked seemed to think that the problem was caused by opening a graphical (i.e., not purely text-based) program owned by root using sudo instead of gksudo. If that was relevant, it evidently meant I should have edited fstab by typing "gksudo gedit /etc/fstab." But was gedit a graphical program? Probably the better explanation was that my problem was caused by something else, and that this is why their solution didn't work for me.

Comments in another thread suggested that the problem might have been caused by an update, and also that the chown command (above) wouldn't work on an encrypted home partition. In a variation, I tried this:

sudo -i
chown ray:ray /home/ray/.ICEauthority
chmod 644 /home/ray/.ICEauthority\
exit

But this didn't do it either; the error was back when I rebooted. Somebody else said the problem had to do with changing passwords, and that was possibly relevant for me, so I went into System > Administration > Users and Groups and changed my user password, and also checked the box that said, "Don't ask for password on login."  But Ubuntu hung when I clicked OK; the circle icon (like the Windows hourglass, meaning "I'm working on it") stayed there for a couple of hours.  When I came back to the machine, I killed the dialog box and tried changing the password again, but it hung again.  I ran a search on that subproblem and tried the advice to kill that GUI approach and just type "sudo passwd [username]" in Terminal (my username was ray).  That worked.  So, back to the ICEauthority problem.  I rebooted, but no, the password fix was not the solution; the error message was still there.

Another suggestion was to make sure that the entire home directory belonged to the user (me).  That sounded like it might be on the money.  My impression was that moving around and copying this old /home partition could easily have screwed up the permissions.  So now, how to make sure I owned the whole /home directory?  In Nautilus (i.e., Places > Computer), I right-clicked on Home Folder > Properties > Permissions.  It said root (i.e., not ray) was the owner.  In Terminal, I typed "sudo nautilus" and, using the Tree (i.e., not Places) view (top of left panel), went to File System > home > ray > right-click Properties > Permissions and changed the permissions to me with full access.  I clicked on the "Apply Permissions to Enclosed Files" button, closed out of there, and rebooted.  Eureka!  That was the solution.  Done!

Ubuntu 10.04: "rsync: failed to set permissions on [folder]: Operation not permitted" -- and Beyond Compare

Using rsync to automate backups on Ubuntu 10.04 (Lucid Lynx), I got a million iterations of this message:  "rsync: failed to set permissions on [target drive & folder]: Operation not permitted."

I had previously had a somewhat similar problem with an external USB drive.  The solution there had been to reformat the drive.  I didn't want to have to do that again if it wasn't necessary.  I ran a search and, following what i understood from one post, I set out to change ownership on the target folder so as to match the ownership of the source folder.  To do that, I went into Ubuntu's Terminal and typed "sudo nautilus," and then navigated Nautilus to File System/media/[target drive].  (It could instead have been in File System/mnt/.)  I right-clicked on that and got Properties > Permissions.  The owner was root.  When I tried to change it, it changed back.

I exited Nautilus and followed instructions in Ubuntu Community Documentation, combined with advice from another post and the Ubuntu manual page for chown.  I typed "sudo chown -R ray /media/[target drive]."  That ran for five or ten minutes, as the chown (change ownership) command recursed (i.e., -R) all of the subdirectories on the target drive.  But that, by itself, did not fix the problem; indeed, it didn't seem to change anything.  Root was still the owner of the target drive.  Then again, the properties of the target allowed others to create and delete files as well, so why was rsync complaining?

There appeared to be another way.  In Terminal, I typed "sudo gedit /etc/fstab."  I already had a line for the target drive, which I'll call simply TARGET.  That line was as follows:

UUID=[UUID for the drive] /media/TARGET ntfs-3g defaults,umask=000 0 0

The Ubuntu documentation I was now looking at said, "Permissions are set at the time of mounting the partition with umask, dmask, and fmask and can not be changed with commands such as chown or chmod."  So possibly that's why my chown command wasn't doing anything.  Following the advice, I changed it to dmask=027,fmask=137, since this was going to be just a backup drive anyway.  I also saw that "defaults" meant these options:  rw,suid,dev,exec,auto,nouser,async.  All of those were fine, as far as I knew, except for this information from the documentation:

user - Permit any user to mount the filesystem. This automatically implies noexec, nosuid,nodev unless overridden.

nouser - Only permit root to mount the filesystem. This is also a default setting.

I wanted user, not nouser.  I decided it might be easier to spot this sort of thing, in future visits to fstab, if I just changed all occurrences of "defaults" to make these options explicit.  Besides, in light of the statements just quoted, it seemed that I would have to override several defaults anyway.  So the resulting fstab line looked like this:

UUID=[UUID for the drive] /media/TARGET ntfs-3g rw,suid,dev,exec,auto,user,async,dmask=027,fmask=137 0 0

I saved fstab and, in Terminal, typed "sudo mount -a" to mount the partitions according to these new instructions.  Then I ran the rsync command again.  Sadly, these changes made no visible difference.  I still got a million error messages.  So, OK.  I had been overlooking the first three error lines in the log output of my rsync command.  The second and third lines followed the pattern of this first line, but were for subdirectories:

rsync: failed to set times on /media/TARGET/.": Operation not permitted (1)

I hadn't previously investigated the "failed to set times" error, so now I did.  What I got out of the forums I came across was that possibly I had a syntax error in my rsync command.  Here's how it went:

rsync -qhlEtrip --progress --delete-after --ignore-errors --force --exclude=/.Trash-0 --exclude=/.Trash-1000/ --exclude=/lost+found/ /media/SOURCE /media/TARGET 2> /media/SOURCE/Backuplog.log

This was identical to the perfectly working rsync command that I was occasionally using to back up SOURCE to a different partition, with one exception:  in the one shown above, I didn't have a slash after Trash-0.  So I changed that to --exclude=/.Trash-0/ and re-ran it.  That didn't solve it.  I then noticed (I was using two desktops) that I had gotten a message telling me that the system was not able to mount the partition:  "Device or resource busy."  So possibly that fstab step still needed to be tested.  I rebooted the system.  None of the the parittions that I had adjusted in fstab were mounted.  I went back, deleted the dmask and fmask parts, and returned it to umask=000, and rebooted.  Now the partitions were all mounted.  I ran the rsync command again.  The problem had not changed.

I found an informative thread in which bscbrit suggested trying to use cp to copy a single file from the source partition to the target partition.  If it worked, s/he said, the problem was not with permissions; it was just with trying to use rsync.  So in SOURCE I copied a file, renamed it "x.txt," and typed "cp /media/SOURCE/x.txt /media/TARGET," and it worked:  there was a copy of x.txt on TARGET.  It sounded like there could be a kind of mismatch between the ext3 source drive and the ntfs target.  I also came across an informative post by djgrandmarquis that said rsync could have problems with Windows file systems.  That was in response to a question about very slow backup times, which  I had also experienced.  I needed Windows file systems because I was backing up to an offsite drive that I sometimes shared with a Windows system.

I had previously investigated Beyond Compare (BC) as another way of synchronizing drives.  BC had drawn  a lot of praise.  Since my previous writeup, I had bought a copy and had been using it for several months on Ubuntu, WinXP, and Linux.  I had subsequently found a comparison of many such programs; but since I had already bought BC and was using it with good results, I didn't explore that comparison.  I could verify that BC was fast and trouble-free when compared to rsync, especially when going between ext3 and ntfs drives.  I also liked the visible information about what was being changed and backed up.  So I decided to stop using rsync and start relying only on BC for my backups.

There were a few differences between the Windows and Linux versions of BC; but in an impressively thorough reply to my post, Craig from BC said that the portable version of BC ran well on Wine in Ubuntu.  I had already installed Wine, and I had also already been using the portable version of BC3; I preferred portable versions to save time during reinstallations, as I was able to save them elsewhere than drive C and therefore they weren't wiped out during a Windows reinstall.  So to try this out, I copied over the BC3 portable installation and tried using a funky procedure involving PortableApps to try the Windows version.  But now it seemed I had not properly understood or used that procedure:  PortableApps now appeared to be looking, not for .exe files, but for ".paf exe" files.  Meanwhile, it looked like Beyond Compare 3 would run fairly well under Wine, so I gave it a try.  Following the steps described in that previous post, in Terminal I navigated to the folder where I had the original BC installer, typed "ls" to get the exact filename, and typed "wine BCompare-3.1.10.11626.exe" to install that file.  Terminal reported some "fixme" and "err" messages; nonetheless, the Beyond Compare 3 Setup Wizard ran.  I had a licensed version, so I entered the license key, and followed the instruction to restart.  It worked, but now I came to the new realization that Windows identifies drives by letter (C: etc.), while Ubuntu identifies them by name (/media/DATA, etc.).  So of course a Windows version of Beyond Compare, looking for Windows-type folder paths, running in Ubuntu, is going to find only a limited number of Ubuntu locations.  I didn't pursue that problem.

This left at least one issue unresolved.  While I was OK with doing manual comparisons for now, I was still not at the point of being able to write scripts to automate BC backup processes.  I started another post on that.

Basic Ubuntu (Bash) Shell Scripts

In Ubuntu 9.04, I wanted to write a script that would execute an rsync command, so that I could put a brief reference to the script into my crontab file, instead of putting the whole long rsync command there.

For a brief, tiny moment, I was almost tempted to consider learning the GAMBAS (Gambas Almost Means BASIC) programming language, just because (pre-Visual) BASIC was the only programming language I ever learned.  Instead, I moved toward basic instructions on writing a shell script.  Here's what I wrote:

#!/bin/bash
# This is backup-hour.sh
# It backs up CURRENT to CURRBACKUP every few hours
rsync -qhlEtrip --progress --delete-after --ignore-errors --force --exclude=/.Trash-1000/ --exclude=/lost+found/ /media/CURRENT/ /media/CURRBACKUP

As the instructions said, the first line was essential to tell the computer to use BASH to interpret the following lines.  The next two lines were comments, and the final line (wrapping over onto multiple lines here) was exactly the rsync line I'd been using to do the backup.  In other words, learning how to write the command was almost all I needed to write the script.

The next step was to save it somewhere.  I had previously heard, and the instructions said, that the common place to put it is in your bin folder.  I went with that, but made a note that I would need to be sure to back up my bin folder, because I didn't want to go to the trouble of writing all these scripts and then see them vanish.

The usual location for the user's bin folder is at /home/[username]/bin.  In my case, that's /home/ray/bin.  Getting there in Nautilus (i.e., Ubuntu's File Browser, also started by typing "nautilus" in Terminal) can be confusing:  you can get there via the Home Folder option (assuming you're showing Tree rather than Places or something else (or nothing) at the left side of the file browser), or you can go to File System/home/[username]/bin.  Same thing, either way.  So I saved the script (above) in my bin folder as backup-hour.sh.  That turned the comment lines (beginning with #) blue in gedit.

Next, the instructions said, I needed to set permissions.  This was a confusing aspect of Ubuntu.  The documentation seemed to say that there were ten permissions that a person could set.  These were represented by ten hyphens or minus signs:  ----------.  I couldn't tell what the first one was for, but the remaining nine were divided into three sets of three.  The first three belonged to the owner, the second three to the group, and the last three to "other."  Within each set of three, the first one was for read, the second was for write, and the third was for execute (i.e., run it as a program).  So if you set the owner's permissions to read (r), write (w), and execute (x), your ten hyphens would now change to this:  -rwx------.  If you set all three parties (i.e., owner, group, and other) the same, they would look like this:  -rwxrwxrwx.

You could set the permissions using the chmod command.  I found an Ubuntu manual page on chmod.  It was not really that complicated, but it looked like it was going to require a time investment to make sure I had it right, and at this point I was getting impatient.  The basic idea seemed to be that you could use chmod to enter values of 4 (for read permission), 2 (for write permission), and/or 1 (for execute permission).  So, for example, you could type "chmod 755" and that would give a value of 7 to the first of the three users mentioned above (i.e., the owner), a value of 5 to the second of the three (i.e., the group), and a value of five to the third of the three (i.e., other).  The 7 would mean that you gave read + write + execute (4 + 2 + 1) permissions to the owner, whereas the 5 would mean that you gave only read + execute (4 + 1) permissions to the rest.  Since that's what the instructions suggested, I went with that.  To set the script with those permissions, I typed "chmod 755 backup-hour.sh."

I wasn't too sure of who the owner was (i.e., me or root), not to mention the group or other.  I mean, this was for my home computer.  Not a lot of people milling around, waiting to take my hard drive for a spin.  These kinds of options seemed to be set up for networked computers, where the "accounting" department might be a group that would own a file.  I found what looked like a good tutorial on file owners, and another interesting (yawn!) page about permissions, but fortunately I did not have time to work through them.

When I typed "chmod 755 backup-hour.sh," I got "cannot access 'backup-hour.sh': No such file or directory."  One solution was to use a change directory (cd) command to get the Terminal prompt into the bin subfolder, so it would see what I was looking for.  But since I planned to put more scripts into that folder, and anyway since I wanted cron or other programs to know right away what I was talking about when I referred to something like backup-hour.sh, I decided to figure out how to put the bin folder in my "path."  The path is the list of folders where the operating system looks for guidance on what a command means.  To change my path so that the system would always know to look in bin, they said I needed to find and edit my .bash_profile file.  Unfortunately, they didn't say where it was.  It wasn't easy to find.  I ran searches in Nautilus (both user and root), but while those were grinding away, I found that I could just type "locate .bash_profile."  That turned up nothing, but very quickly.  Then I got some advice that, if it didn't exist, I could create it by using "touch ~/.bash_profile."  So I did that, and then tried again with "chmod 755 backup-hour.sh."  Still no joy.  Ah, but maybe that was because I hadn't rebooted; backup-hour.sh would run only on startup.  OK, so I used the other approach after all:  I changed directory to the bin folder and tried again.  Now I got "Permission denied."  What if I gave everybody full permissions with chmod 777?  I tried that instead of chmod 755.  That seemed to do it.  The hard drive was doing its thing now.

I wanted to see what was going on, so I decided to create a log file.  I wanted it to store only the error messages, not to list the thousands of files that backup-hour.sh was backing up successfully, so I put this on the end of (that is, on the same command line as) my rsync command in backup-hour.sh (above):

2> /media/CURRENT/backup-hour.log

The log filename thus matched the script filename.  I put "backup" first so that I could see all of my backup scripts in the same part of the folder's directory listing, and then I set up a backup-day.sh script along the same lines.  New problem:  these backup scripts would generate empty log files if there were no errors, and I didn't want to have to delete them manually.  So I found a forum post with advice on how to delete them automatically, using the "find" command.  In my version, it looked like this:

find /media/CURRENT/ -name "*.log" -size 0c -exec rm -f {} \;

I put that at the end of the backup-day.sh script, and it seemed to work.  It said, basically, look in the CURRENT folder for files whose name ends with .log and have zero bytes; and if you find any files like that, execute the "remove" command without asking for permission.  I didn't know what that ending punctuation is about, but that's what the advisor suggested.

In my backup-day.sh (not backup-hour.sh) script, I included the instructions for updating my USB jump drive (above).  I also included a set of commands to save my e-mail (I was using Thunderbird in Ubuntu) as a .tar compressed file. Actually, as seven .tar files, one for each day of the week.  That part of backup-day.sh looked like this:

# Assign Thunderbird mail & profile to be backed up
backup_files="/home/ray/.mozilla-thunderbird"
dest="/media/BACKROOM/Backups/Tbird"
# Create archive filename
day=$(date +%A)
hostname=$(hostname -s)
archive_file="$hostname-$day.tgz"
# Back up to a tgz file
tar zcvf $dest/$archive_file $backup_files 2>> /media/CURRENT/A-INCOMING/T-bird-Backup.log

So these seemed to be the basic kinds of tools I needed to set up rsync scripts and crontab entries.