[arch-general] /etc/rc.local: "chown user: /dev/sda10" /etc/fstab: "defaults, owner, noauto"
/etc/rc.local: "chown user: /dev/sda10" /etc/fstab: "defaults,owner,noauto" Or more accurately: /etc/rc.local: "chown jtwdyp: /dev/disk/by-label/j10_lap-10" I've been allowing only my normal user account to mount 3 such user "owned" partitions in various distros this way {without needing to use sudo} for years. I know that ever since USB devices made static /dev/* lists unusual, the ownership of any partition gets set to root during root. But I've always been able to count on my root script to chown them back, returning ownership to the data owner, if {depending on the distro} I either sourced it in some rc.local file, OR if some debian based distro didn't like rc.local script's I'd just symlink it with something like: ln -s /root/bin/fix_dev /etc/rcS.d/S38fix_dev I only needed to take care that my root script 'chown'ed the partitions AFTER the device names in /dev had been dynamically created. And it worked. I was pleased to note that Arch evidently does think a rc.local is an appropriate place for local initialization stuff to happen. However it's come to my attention that about 5 out of the last 25 times I've booted Arch only 2 of the 3 partitions 'chown'ed in my /root/bin/fix_dev script can be mounted by my user account. (unless I use root account to manualy rerun the /root/bin script...) On the occasions when a user script's attempt to mount the 3rd such partition fails {with an error message telling me that only root can do that} the other two such partitions mount just fine. Is there something special I need to do to get Arch to *_consistently_* respect all three chown commands??? I really dislike the idea of changing the fstab entry from "owner" to "user" even if since the mountpoint is in a subdir of /home/jtwdyp, I could just rely on: cmod 700 {the mount points parent dir} along with the file permisions within the partition itself, to keep the data private. Somehow it just wouldn't feel right to extend the mount permisions to just any user even though this multi-boot linux box is my personal computer that nobody else uses... Recommendations anyone? -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>
Am 29.03.2010 15:01, schrieb Joe(theWordy)Philbrook:
I was pleased to note that Arch evidently does think a rc.local is an appropriate place for local initialization stuff to happen. However it's come to my attention that about 5 out of the last 25 times I've booted Arch only 2 of the 3 partitions 'chown'ed in my /root/bin/fix_dev script can be mounted by my user account. (unless I use root account to manualy rerun the /root/bin script...)
On the occasions when a user script's attempt to mount the 3rd such partition fails {with an error message telling me that only root can do that} the other two such partitions mount just fine.
USB devices are detected asynchronously (other too, possibly). The device node may be (re)created after rc.local has finished.
Is there something special I need to do to get Arch to *_consistently_* respect all three chown commands???
man udev I am thinking about something like: SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your_uuid", OWNER="your_user" in a late udev rule file (say, /etc/udev/rules.d/99-local-disk.rules).
It would appear that on Mar 29, Thomas Bächler did say:
Am 29.03.2010 15:01, schrieb Joe(theWordy)Philbrook:
I was pleased to note that Arch evidently does think a rc.local is an appropriate place for local initialization stuff to happen. However it's come to my attention that about 5 out of the last 25 times I've booted Arch only 2 of the 3 partitions 'chown'ed in my /root/bin/fix_dev script can be mounted by my user account. (unless I use root account to manualy rerun the /root/bin script...)
On the occasions when a user script's attempt to mount the 3rd such partition fails {with an error message telling me that only root can do that} the other two such partitions mount just fine.
USB devices are detected asynchronously (other too, possibly). The device node may be (re)created after rc.local has finished.
Yeah USB devices should be... All three of the partitions in question are on the one and only internal hard drive of my laptop... the fix_dev script consists of: chown jtwdyp: /dev/disk/by-label/jSTUFF_lap-8 chown jtwdyp: /dev/disk/by-label/Jimages_lap-9 chown jtwdyp: /dev/disk/by-label/j10_lap-10 which normaly represent /dev/sda8 /dev/sda9 /dev/sda10 It would make sense to me that the whole device node might get recreated if I attached or removed a device. But why would it recreate the device node for /dev/sda10 without also recreating the nodes for /dev/sda8 & /dev/sda9???? It wouldn't bother me so much if it wasn't for the fact that of all my user scripts that expect to mount or umount any of these partitions the one that's been getting these errors is actually my ~/.bash_profile which mounts all three on user login. Which 99.9% of the time is the first thing I do after boot up is complete.
Is there something special I need to do to get Arch to *_consistently_* respect all three chown commands???
man udev
I am thinking about something like: SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your_uuid", OWNER="your_user" in a late udev rule file (say, /etc/udev/rules.d/99-local-disk.rules).
Thank you! I do wish that the authors of various man and info documentation believed even half as much as Arch's wiki files in explaining "how to" to someone who doesn't already know, rather than just reminding some professor which options are currently compiled in... I know for certain that "man udev" wouldn't have given me a clue how to write that example rule template, even if I'd studied it for a year and a day. Thanks again! But: <sigh> I hates UUID (or any other human NON-readable device id, config files, etc...) considerably more than Yosemite Sam ever hated rabbits. ;-7 Actually I only converted to using /dev/disk/by-label/ when I recently decided to try Arch and the {much better written than most} Arch wiki convinced me that I should convert to "Persistent block device naming". {And which even gave step by step instructions for naming various FS types} I do hope this is a valid adaption of the above template: SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="j10_lap-10", OWNER="jtwdyp", GROUP="jtwdyp" But I wonder if this would be applicable to my other linux as well? That is maybe I won't need to bother running my fix_dev script anymore... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>
Am 29.03.2010 23:58, schrieb Joe(theWordy)Philbrook:
I do hope this is a valid adaption of the above template:
SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="j10_lap-10", OWNER="jtwdyp", GROUP="jtwdyp"
Looks fine to me.
But I wonder if this would be applicable to my other linux as well?
If it uses udev, it should work.
It would appear that on Mar 30, Thomas Bächler did say:
Am 29.03.2010 23:58, schrieb Joe(theWordy)Philbrook:
I do hope this is a valid adaption of the above template:
SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="j10_lap-10", OWNER="jtwdyp", GROUP="jtwdyp"
Looks fine to me.
But I wonder if this would be applicable to my other linux as well?
If it uses udev, it should work.
Thank you for the confirmation Thomas, empirical testing will soon confirm if it works in my arch installation as I've already included 3 such "rules" in my new /etc/udev/rules.d/99-local-disk.rules file, and commented out the line in my rc.local that sourced my old kludge. As of this boot cycle I can at least confirm that the addition of the udev rule file caused no errors. Next boot should confirm that I don't need the kludge anymore... If it fails, I'll follow up here... But since I expect that this is my last posting on this thread, I'd like to thank you again for so kindly including such a well formed example when you suggested I man udev. Incidentally your example included the scroogle search term "ENV{ID_FS_UUID}" which wasn't in the man udev output except in very general terms that assumed the reader knew what "key" values were possible. That soon led to a confirmation that "ID_FS_LABEL" was also a valid key. the "GROUP" variable name was mostly a guess that was initially confirmed only by vim's syntax highlighting that color matched it to "OWNER". But if I'd had to depend on man udev, I'd still be as stuck as I was the last time I tried to understand what udev was all about. back when the attempt turned my brains to mush until I figured out how to implement my kludge (I think that was on Kubuntu breezy, but it might have been fedora core 2... I lose lots of memories to CRS ya know) But like I said Thomas: TTTTTTTTTTTT HH HH AA NN NN KK SSSS TT HH HH A A NNNN NN KK KK SS SS TT HH HH AA AA NN NN NN KK KK SS TT HHHHHHHHHH AAAAAAAA NN NN NN KK KK SSSSS TT HH HH AA AA NN NN NN KKKK KK SS TT HH HH AA AA NN NNNN KK KK SS SS TT HH HH AA AA NN NN KK KK SSSS -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
participants (2)
-
Joe(theWordy)Philbrook
-
Thomas Bächler