SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just tested the jasper build script - it's not the culprit.
Check the perms on each of your other packages created by checkinstall.
Did that, and they are all good. I've never had a problem using checkinstall before. This is probably something on my end. Some kind of obscure configuration must be causing this.
As mentioned before my umask is 0002 for both my user and root.
ok, so I noticed that my /tmp folder had SBo folder 700.
I rm -R the SBo folder, and built Jasper again using the slackbuild. All the perms were just fine, and the SBo folder was recreated with 755 perms.
Could the /tmp/SBo folder being 700 have been responsible? I wonder how it could have gotten those perms.
No, that directory's permissions would not have influenced the permissions of any newly created directories inside it. However, I am curious as to how that directory came to have those permissions, as it would have been created originally with 0755 perms (unless your umask for root is set differently, but you've stated that such is not the case). I know of at least one way this could have happened, but it doesn't seem relevant to what you're experiencing...
If you have some spare time, do a fresh installation inside a virtual environment (qemu, vmware, virtualbox, whatever) and repeat all the customization you've done on this system. Check the perms on the relevant directories after *each* change you make, and perhaps you can find the culprit.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.