Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Beware of wrong mount options when mounting /var at a separate partition
Quote:
http://askubuntu.com/questions/24649...mission-denied
So, it suddenly dawned on me that the permission denied thing may be related to the noexec option in /etc/fstab (I'm mounting /var on a different disk than /). Turns out I'd used the following mount option: UUID=b5ae50cf-58e6-46f8-8313-6c1492dcc8ad /var ext4 defaults,users 0 0 and, while defaults implies exec, users instead implies noexec - as the latter is last, it will override the previous one. Changed it to defaults only and all is now ponies and sunshine with apt-get. Posting my own answer in case it helps anyone else out there. – Marco Jan 23 '13 at 8:15
So, it suddenly dawned on me that the permission denied thing may be related to the noexec option in /etc/fstab (I'm mounting /var on a different disk than /). Turns out I'd used the following mount option: UUID=b5ae50cf-58e6-46f8-8313-6c1492dcc8ad /var ext4 defaults,users 0 0 and, while defaults implies exec, users instead implies noexec - as the latter is last, it will override the previous one. Changed it to defaults only and all is now ponies and sunshine with apt-get. Posting my own answer in case it helps anyone else out there. – Marco Jan 23 '13 at 8:15
"defaults,noatime" seems to work for me.
And still related with the subject, not so much with mounting, though:
Quote:
https://bugs.launchpad.net/nexenta/+bug/335056
I have made progress figuring out the root cause (literally).
/var/cache/man needs to be recursively owned by user "man". Many of the locale subdirs were owned by user "root". If you down a "chown -R man /var/cache/man" this problem goes away.
Each of the successive fopen errors seems to be related to updating manpages for each of the locales (thanks to mib_chrol in ##nexenta for finding the open64 call that triggers this)
This is why running /usr/bin/mandb as root does not trigger errors, but dpkg related tools will (as these seem to update /var/cache/man in the context of the "man" user).
I have made progress figuring out the root cause (literally).
/var/cache/man needs to be recursively owned by user "man". Many of the locale subdirs were owned by user "root". If you down a "chown -R man /var/cache/man" this problem goes away.
Each of the successive fopen errors seems to be related to updating manpages for each of the locales (thanks to mib_chrol in ##nexenta for finding the open64 call that triggers this)
This is why running /usr/bin/mandb as root does not trigger errors, but dpkg related tools will (as these seem to update /var/cache/man in the context of the "man" user).
Total Comments 0
