Dear all,
I have an external hard disk that is mounted/unmounted through a backup script.
The mounting part of the script looks like
# 1.Check that the device is not mounted already
MOUNT=`mount | grep $MOUNTPOINT` && (doEmail 2; exit 1;) # That means that mount is there already and it should not. Report the error and exit
# 2. Proceed mounting for the first time.
mount $MOUNTPOINT 2> /dev/null
MOUNT=`mount | grep $MOUNTPOINT` || (doEmail 1; exit 1;) # Mount is not there so something wrong happened. Report the error and exit
and the unmounting part
# 4. Unmount the Device
umount $MOUNTPOINT
MOUNT=`mount | grep $MOUNTPOINT` && (doEmail 3; exit 1;) # That means that the mount is there already and it should not. Report the error and exit
In the first case you look on permissions of mount point, and in the second case you look on the permissions of root directory of mounted device. These are two different files (directories) so why are you surprised they have different permissions and/or owners?
True… the first one is a local directory and the second one refers to the external disk… but stilll why it has
1.such a user id that does not existi in /etc/passwd
2. and not root’s (that mounted it)
About 2. Of course root mounted it. Only root can mount. But that has nothing to do with file permissions.
The fact that you have files owned by user 2005, which is not a user that exists on your system is something different. The 2005 is a userid. Remember that it is the userid that counts and that is stored with the file as owner. The username is only a name defined for that user on a system as an easy reference. But on a different system, the same userid can have a different username. That can create problems when you move a disk between systems with different user polulations. And also when you NFS mount from another file sysstem with a different user population.
Somewhere in the existance of the file system, somebody has created a file with that user. Either directly or by (e.g. as root) doing a chown command. That did not nescesaraly happen on the system you are talking about. We do not know the history of that disk. But it could have been used originaly on a complete different system where user 2005 did exist.
In other words, you should try to find out where that disk came from and what is on it and who should own that.
And you should try to understand what mount does with respect to the mount point. It will hide the mount point and everything that is allready below it in the directory tree, You will see thare after the mount, what is on the mounted disk and not any more what is on the original place.
I see. thanks that makes it clear.
These user ids come from the remote servers where the files were copied (to be backed up). Either I leave the files as are or assing to those files a new user id that corresponds to my local host. I do not think it so much meaning now as these files are to be used with root permissions (when the backup would be restored).
Do you see anything else wrong, like my fstab entry I posted in the first post?
Yes, when you manage several systems that “belong together”, then seeing that the same users get the same userid (and preferable of course also the same username and group) on all of those systems is important.
When these files belong to other users on that other system and those users are not on the system you use the disk now on, isn’t a big problem as long as the owner does not need access to the files on that system. When you say they are backed up files and only there to be restored, when need arises, using root, then that is fine.
Your fstab entry looks fine to me. I probably would use the /dev/disk/by-label instead of the LABEL=, but that is realy personal and it works the same. Usinf the label is a good way to be sure you have the correct disk on the correct place.
As a side remark, your CODE taged parts there look a bit strange like extra new lines, etc… Are you sure you copied/pasted directly from the terminal emulator in between the CODE tags? It looks if there were other actions involved. Also we like very much the complete thing: the prompt, the command, the output, the next prompt (excepot when it becomes very large of course). For you the best way to show what you did to get what you post and for us the best way to be rather sure you did not tinker with what you post. Not that you (or others) want to play games with us tinkering with the text, But people often tinker because they think that they are omiting something that is not important. And that often results in omitting the most important things
