[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
| \___/ <
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
| \___/ <
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
| ~\___/~ <
participants (2)
-
Joe(theWordy)Philbrook
-
Thomas Bächler