Friday, August 23, 2013

[solved] removable media - gid and uid fix

I typically maintain uniform UID's and GID's across the different distros I try. It seems to contribute to less troublesome back-ups which come with distro-hopping.

For example, I recently caused myself a problem. During the latest install, I established my standard UID of 1500. But I overlooked the usual procedure of creating a new group for myself with a 1500 GID. Instead, I placed myself into the "users" group, which had a GID of 100. The files I thereafter created possessed a 1500:100 stamp.

A couple of weeks following the install I attempted to back-up a diff. I attached a USB HDD I've had for several months, and which was formatted, including its folders, with my typical 1500:1500 ownership. Of course it has been no problem to copy from the 1500:1500 USB to my system. But when I attempted to back-up 1500:100 files from my system to the 1500:1500 USB, "permission denied" write errors were generated. Writing to the USB HDD as root would have overcome this, but wasn't the solution I wanted: "chown"-ing any and all 0:0 files to 1500:1500 seemed to be overlooking a more efficient solution.

After some thought, it seemed best to permanently change the primary group attached to my username on the desktop system. I wanted this to happen in a way that automatically assigned the new GID to all existing files in my home directory. Note that username is "patriot".


  1. exited X to command line
  2. logged off - "exit"
  3. logged in as root
  4. created group 1500 (# groupadd foo -g 1500)
  5. moved "patriot" from group 100 into group 1500 (# usermod -g 1500 patriot) Note: give this a few minutes to complete; many file GID's are being updated.
  6. # nano /etc/group - verified patriot was in desired groups
  7. rebooted and logged in as user "patriot", per usual.


All files changed to 1500:1500 and no permission problems noted when backing-up to a USB HDD.

Monday, August 19, 2013

crontab -- good times

Sometimes it's apparently the simplest, most potential helpful concepts which are the most poorly executed. Adding a printer, calling a script at a certain time each day. For those that configure these things for a living, I'm sure it's easy --- the rest of us look forward to the day basic functions won't take a week to configure.

So...crontab. A simple concept which requires threading through a weird syntax, and kludgy daemon and script file relationships until one finally gets it to work on their particular installation. Here's what worked on a recent install of Arch. First the unintuitive, unhelpful crontab syntax:
Example of job definition:
.---------------- minute (0 - 59)
| .------------- hour (0 - 23)
| | .---------- day of month (1 - 31)
| | | .------- month (1 - 12) OR jan,feb,mar,apr ...
| | | | .---- day of week (0 - 6) (Sunday=0 or 7)
| | | | |
* * * * * command to be executed

Let's say I want to delete a file every night at midnight; let's use the common example of .local/share/recently-used.xbel. I go to $ crontab -e to access my crontab file and create the job line:
0 0 * * * /usr/bin/rm -rf /home/foo/.local/share/recently-used*

So zero hour, and the asterisks mean "every". Every day of the week, every day of the month, at zero hour this command will be executed. The other asterisk, the one at the end of the file to be deleted? Another "feature" of crontab is it appears to ignore commands with file extensions, so I replace any file extensions with asterisks or leave them off entirely. I've also found that the last line has to be a newline, so that, following my command above, I need to make a hard return in the file. Note also that I used the hard path to the rm command, and to the file to be deleted. This is because of the common PATH issues with crontab. Finally, if crontab has the wrong syntax, it loads without errors but simply doesn't perform its tasks.

Even if one manages to get the insanely finnicky crontab in a proper syntax for running, it still is unlikely to run. Why? Daemon problems. Their are at least 5 different cron daemons available, instead of one. All of them behave differently. There is crond, cronie, fcron, anacron, and cronie-without-anacron, for example. More horrible design work around this critical function. At least one of them must be running for the crontab to execute.


Systemd uses timers.
$ systemctl list-timers