Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using Ubuntu 9.10 on a stationary PC. I have a secondary 1 TB harddrive with a single big logical partition (currently formatted as ext4). It is mounted as /usr3 with options user, exec in /etc/fstab.

I am doing highspeed imaging experiments. Well, only 260fps, but that still creates many individual files since each frames is saved as one png-file. The stationary is not used by anyone other than me which is why the default security model posed by ubuntu is not necessary.

What is the best way to make the entire contents of /usr3 generally available on all systems. In case I need to move the harddrive to another Ubuntu 9.x or 10.x machine?

When grabbing image with the firewire camera I use a selfmade grabbing software-utility (console based) in sudo-mode. This creates all files with root as owner and group.

I am logged in as user otb and usually I do the following when having to make files generally available to otb:

sudo chown otb -R *
sudo chgrp otb -R *
sudo chmod a=rwx -R *

This takes some time since the disk now contains individual ~200000 files.

After this, how would linux behave if I moved the harddrive to another system where the user otb is also available? Would the files still be accessible without sudo use?

share|improve this question
up vote 3 down vote accepted

You will need to have same uid and gid for the user otb (or whatever the username is) in order to be able to access the files without sudo on a different system.

UID (user ID) and GID (group ID) are both unique number systems assigned to users and groups. For normal users they start from 1001 onwards.

Easiest way to ensure same permissions: In the file /etc/passwd, for any user entry, UID & GID is the third and fourth field respectively. On second system you can create a user with command from a terminal using useradd -u UID -g GID username where the UID and GID are the same UID and GID of the user otb in first system. Before issuing the command, ensure that the same UID is already not in use.

I tried from GUI System -> Administration -> Users and Groups and could not find a way to synchronize it.

Keeping same /etc/passwd file across systems, or using solutions like NIS, LDAP will make this much more smoother if you have more systems.

For more details refer to man useradd, man usermod and, if you need to delete any users, man userdel from a terminal.

share|improve this answer
I will check the passwd files on both stationaries tommorow. They are both running 9.10 Desktop and I have not created other users than otb on the system - perpaps one could assume that the GID and UID are the same on both systems? – Ole Thomsen Buus Feb 6 '11 at 17:17
If you have same UID & GID it should work fine if you mount the hard disk on new system. :). If you do not have, the user which has same UID & GID will get the same kind of permission. username is more for humans to remember easily and uid/gid actually controls permissions. – Jamess Feb 7 '11 at 7:34
I have now checked /etc/passwd on both systems and they have this line in common: otb:x:1000:1000:Ole Thomsen Buus,,,:/home/otb/:/bin/bash So it should work? – Ole Thomsen Buus Feb 7 '11 at 15:22

First of all, your first two commands can be combined :

sudo chown otb:otb -R *

Not sure if this will run faster however.

Second of all, since you don't care about security on this drive, you should mount the drive specifying a umask which makes all files 777 as they are written :


That might help prevent the need for running your third command at all.

Additionally, since it seems that a umask option may not be available for all filesystem types, there's another way to set the default file permissions of files created when in sudo. This is achieved by editing /etc/sudoers.

From man sudoers, the option "umask_override" appears to allow this.

umask_override : If set, sudo will set the umask as specified by sudoers without modification. This makes it possible to specify a more permissive umask in sudoers than the user’s own umask and matches historical behavior. If umask_override is not set, sudo will set the umask to be the union of the user’s umask and what is specified in sudoers. This flag is off by default.

I've never used this option though, so proceed carefully. Editing /etc/sudoers can be dangerous and require a system rebuild (or live CD intervention) if you get it wrong.

share|improve this answer
Cool, that will make things a bit easier :) But will the umask also work if files are created using sudo (root) privileges? I guess I still need to change owner and group with the combined command you mention? – Ole Thomsen Buus Feb 6 '11 at 17:14
Well, they'll still be owned by "root", since you're running your command with sudo, but since they'll have no security on them, you'll be able to access them with any user. Umask=000 is the same as chmod 777, which should result in rwxrwxrwx permissions. – Scaine Feb 6 '11 at 17:42
Yea ok - makes sense. Using chmod 777 makes the actual owner a minor detail. Ok, thanks for valuable information. I chose to accept the answer by Jamess since it was directed more toward solving the movement of the data to the other system. – Ole Thomsen Buus Feb 6 '11 at 17:52
It seems that ext4 does not support the umask mount option? Is this true? – Ole Thomsen Buus Feb 7 '11 at 15:21
I can't confirm, Ole, but you might be right - I've only used umask on external drives that are either NTFS or FAT32. However, after a bit of searching, I've found what might be a better way (since it's drive independent). I've edited my answer with the new approach. I'm no expert here though, so it might be worth starting a new question to query this aspect. – Scaine Feb 7 '11 at 23:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.