auto-mounting external IDE / usb drive with sticky permissions

I have an old laptop IDE hard drive that I hook up via USB to use for music file storage. I want to hotplug this between different computers as and when required, but on the machine it’s on most of the time I’d prefer that it be mounted automatically on boot (or even better when plugged in) and available for all users (though with the sticky bit set so other users can’t delete the files).

I did a fresh install of openSUSE 12.2 on this machine with the drive attached, so I set its mount point to /home/shared during install. However, after logging in the drive can’t be seen by default and I have to mount it manually as root with

mount /dev/sdb3 /home/shared

whereupon I can access the files with no problem, but it’s not useful for guest users of the machine who wouldn’t be able to do that. I thought the issue might be due to the owner being shown as root so changed owner to myself with ‘users’ as group, but after a restart it reverts to root:root. In fstab I see the relevant drive partition listed as follows:

/dev/disk/by-id/usb-TOSHIBA_MK6025GAS_†††††㈠㔵㑌㌶匰-0:0-part3 /home/shared         ext4       user,noauto,acl,user_xattr,nofail 0 0

Is it possible that the non-standard characters in the disk ID may be to blame? All drives/partitions are set as mount ‘by-id’ by default. But I’m not too knowledgeable on these things so maybe there’s a glaring error or what I’m trying to do is simply not possible with an external drive?

Hang on, how did that ‘noauto’ get in there? I didn’t set that during install!

Looks like you found the culprit yourself with noauto. How about another no? I add noatime to all my entries to help save time in the fstab file:

Linux has a special mount option for file systems called **noatime **that can be added to each line that addresses one file system in the /etc/fstab file. If a file system has been mounted with this option, reading accesses to the file system will no longer result in an update to the atime information associated with the file like we have explained above. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to. In our example below, we will set the noatime option to our /chroot file system.

Sounds like its not a bad thing to use.

Thank You,

I see this is about an ext4 file system. Thus ownership/permissions are ruled as for every other file/directory.
E.g. the ownership and permission of /home/share is important. As are all ownership/permission settings inside /home/shar (in other words, inside the said filesystem).

And do not forget that ownership by user and group is about ownership by userid and groupid, not by username and groupname. Thus if you have several systems with the “same” users, they are realy only the same when they have the same userid, not when they have the same username. Best practice is to manage user/groups on systems that “belong together” centraly to avoid problems in NFS and (un)plugging file systems. When there are many systems, you should use something like NIS for that.

I didn’t quite understand this option so did some more reading on Wikipedia which lead me to this page: valhenson: Relatime Recap
This seems to suggest that relatime is now default on most distros since kernel 2.6.30. Is this the case with openSUSE, and so would adding noatime achieve any extra gain?

The article you cite is from 2009 while the noatime fstab option is being recommended for all SSD drives due to the fact that frequent writes can reduce their lifespan. In the limited testing I have done, it provides a speedup for all partitions, though using an SSD is faster than anything else you could possible do. If you use mutt, which I do not, I found this suggestion from six months ago.

Why are “new” flags of mbox folders wrong in folder-list view?

As written in manual.txt, the flags are determined by comparing the timestamps of last access and modification. This can get messed up if the folders are “touched” by other programs than mutt, like “biff” or backup software.
There is also some issue with the “noatime” flag for mounting filesystems (most often used on laptops). If “noatime” is activated, no timestamp is updated for the last folder access, i.e. Mutt cannot determine if the folder has received new mail since last visited. For mutt before version 1.5.15, you can recompile it with the --enable-buffy-size option to “configure”; for mutt 1.5.15 or later see the $check_mbox_size option. Mutt will then use the folder size instead of the access times. (This is only a workaround and might give suboptimal results; another option is to use the MaildirFormat.)

Thank You,