[SOLVED] permission errors starting momgodb

camorri · 05-05-2024, 01:55 PM

I installed Alienbobs momgodb following these instructions:

https://alien.slackbook.org/blog/how...-on-slackware/

All went well until I tried to start mongodb. Here are the errors reported.

Code:

/etc/rc.d/rc.mongodb start
/etc/bash_completion.d/libreoffice.sh: line 5: /dev/null: Permission denied
/etc/bash_completion.d/libreoffice.sh: line 12: /dev/null: Permission denied
/etc/bash_completion.d/libreoffice.sh: line 17: /dev/null: Permission denied
/etc/profile.d/libglib2.sh: line 18: /dev/null: Permission denied
{"t":{"$date":"2024-05-05T17:28:53.301Z"},"s":"E",  "c":"-",        "id":23825,   "ctx":"main","msg":"SecureRandom: open `{kFn}`: {strerror_errSave}","attr":{"kFn":"/dev/urandom","strerror_errSave":"Permission denied"}}
{"t":{"$date":"2024-05-05T17:28:53.301Z"},"s":"F",  "c":"-",        "id":23089,   "ctx":"main","msg":"Fatal assertion","attr":{"msgid":28839,"file":"src/mongo/platform/random.cpp","line":174}}
{"t":{"$date":"2024-05-05T17:28:53.301Z"},"s":"F",  "c":"-",        "id":23090,   "ctx":"main","msg":"\n\n***aborting after fassert() failure\n\n"}
MongoDB server failed to start, exiting now...

Each error for libreoffice.sh script fails on a line pointing at /dev/null.

I'm not well versed in this area. I suspect this is a clean up script. I am not sure how to proceed here, I don't want to start changing ownership and causing security holes.

Here is /dev/null.

Code:

ls -l /dev/null
crw-rw---- 1 root plugdev 1, 3 May  5 11:37 /dev/null

and here is libreoffice.sh;

Code:

ls -al /etc/bash_completion.d/libreoffice.sh
-rwxr-xr-x 1 root root 5290 Apr  1 16:26 /etc/bash_completion.d/libreoffice.sh

Your help is always appreciated.

volkerdi · 05-05-2024, 02:10 PM

Well, it looks like the permissions in /dev aren't correct. Those devices are created and managed by udev. Have you tried restarting the machine to see if it cleans up the permissions?

camorri · 05-05-2024, 03:25 PM

I boot the system at least once a day, sometimes more. I have 15.0 on an nvme drive, and current on an sdd.

I booted the system ( 15.0 ) and I don't see a change, other than the time stamp.

Code:

ls -l /dev/null
crw-rw---- 1 root plugdev 1, 3 May  5 16:06 /dev/null

On my raspberry pi-3 I see ' crw-rw-rw- 1 root root 1, 3 Apr 19:21 /dev/null.

On another 15.0 system I see:

Code:

root@alienware:~# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 May  5 16:20 /dev/null

Petri Kaukasoina · 05-05-2024, 03:50 PM

Have you edited any udev rules lately?

Code:

ls -lrt /etc/udev/rules.d /lib/udev/rules.d

camorri · 05-05-2024, 04:04 PM

Quote:

Have you edited any udev rules lately?

No I have not. The only time I remember editing a rule was to get a USB device ( a mail light ) working. That would be over a year ago.

camorri · 05-05-2024, 04:23 PM

I did add a Logitech keyboard and mouse. I also built and installed solaar from SBo. There appear to be rules added.

Here is the rule file that was added.

Code:

1 # This rule was added by Solaar.
  2 #
  3 # Allows non-root users to have raw access to Logitech devices.
  4 # Allowing users to write to the device is potentially dangerous
  5 # because they could perform firmware updates.
  6 
  7 ACTION != "add", GOTO="solaar_end"
  8 SUBSYSTEM != "hidraw", GOTO="solaar_end"
  9 
 10 # USB-connected Logitech receivers and devices
 11 ATTRS{idVendor}=="046d", GOTO="solaar_apply"
 12 
 13 # Lenovo nano receiver
 14 ATTRS{idVendor}=="17ef", ATTRS{idProduct}=="6042", GOTO="solaar_apply"
 15 
 16 # Bluetooth-connected Logitech devices
 17 KERNELS == "0005:046D:*", GOTO="solaar_apply"
 18 
 19 GOTO="solaar_end"
 20 
 21 LABEL="solaar_apply"
 22 
 23 # Allow any seated user to access the receiver.
 24 # uaccess: modern ACL-enabled udev
 25 TAG+="uaccess"
 26 
 27 # Grant members of the "plugdev" group access to receiver (useful for SSH users)
 28 MODE="0660", GROUP="plugdev"
 29 
 30 LABEL="solaar_end"
 31 # vim: ft=udevrules

Not sure if this is part of the problem; or not.

Petri Kaukasoina · 05-05-2024, 04:50 PM

Removed my original answer...

Try to move that rule file from that directory and reboot. If it doesn't help, move it back.

Is there any other candidate? This is in -current here:

Code:

$ ls -l $(grep -l 660 $(grep -l plugdev /etc/udev/rules.d/* /lib/udev/rules.d/*))
-rw-r--r-- 1 root root 8214 2023-09-03 06:53 /lib/udev/rules.d/40-libgphoto2.rules
-rw-r--r-- 1 root root  201 2021-02-13 14:19 /lib/udev/rules.d/60-openobex.rules
-rw-r--r-- 1 root root 1380 2010-04-20 18:25 /lib/udev/rules.d/65-permissions.rules

And this is in 15.0:

Code:

$ ls -l $(grep -l 660 $(grep -l plugdev /etc/udev/rules.d/* /lib/udev/rules.d/*))
-rw-r--r-- 1 root root 8044 2022-01-03 19:49 /lib/udev/rules.d/40-libgphoto2.rules
-rw-r--r-- 1 root root  201 2021-02-13 14:19 /lib/udev/rules.d/60-openobex.rules
-rw-r--r-- 1 root root 1380 2010-04-20 18:25 /lib/udev/rules.d/65-permissions.rules

Do you have the same file sizes? Did you get other files found?

camorri · 05-05-2024, 06:46 PM

OK, some progress. I had copies of 42-logitech-unify-permissions.rules in /lib/udev/rules.d and /etc/udev/rules.d. I moved both out to my home directory. Now the permissions for /dev/null look like my other systems.

Now I see:

Code:

ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 May  5 19:31 /dev/null

However, mongodb still won't start. Now I see:

Code:

/etc/rc.d/rc.mongodb start
about to fork child process, waiting until server is ready for connections.
forked process: 2812
ERROR: child process failed, exited with 48
To see additional information in this output, start without the "--fork" option.
MongoDB server failed to start, exiting now...

I also see a copy of rule 42 in the initrd-tree. Is that something I should be concerned with?

Code:

locate 42-logitech-unify-permissions.rules
/boot/initrd-tree/lib/udev/rules.d/42-logitech-unify-permissions.rules
/home/cliff/42-logitech-unify-permissions.rules
/home/cliff/bin/42-logitech-unify-permissions.rules

Petri Kaukasoina · 05-06-2024, 12:48 AM

Quote:

Originally Posted by camorri

I had copies of 42-logitech-unify-permissions.rules in /lib/udev/rules.d and /etc/udev/rules.d.

I built the Solaar-1.1.11-x86_64-2_SBo.tgz package and it installed 42-logitech-unify-permissions.rules only in /lib/udev/rules.d, nothing in /etc/udev/rules.d. If you have both, the one in /etc is used instead. Try diff those two files to see if there is something different in the file that was in /etc.

Here the udev rule (from /lib/udev/rules.d) only changed the group and mode of /dev/hidraw0 and /dev/hidraw1, no change for /dev/null.

Quote:

Originally Posted by camorri

However, mongodb still won't start.

That's probably not connected to the Solaar problem.

Quote:

Originally Posted by camorri

I also see a copy of rule 42 in the initrd-tree. Is that something I should be concerned with?

It could be a good idea to rebuild initrd and prepare the boot loader to get rid of the broken rule there, but I don't think it matters, because everything runs still as root there and device nodes having wrong mode there shouldn't matter.

camorri · 05-06-2024, 05:50 AM

Well, the diff shows the copy in /etc/udev/rules.d/ missing the following:

Code:

diff -s 42-logitech-unify-permissions.rules ~/bin/42-logitech-unify-permissions.rules
0a1,27
> # This rule was added by Solaar.
> #
> # Allows non-root users to have raw access to Logitech devices.
> # Allowing users to write to the device is potentially dangerous
> # because they could perform firmware updates.
> 
> ACTION != "add", GOTO="solaar_end"
> SUBSYSTEM != "hidraw", GOTO="solaar_end"
> 
> # USB-connected Logitech receivers and devices
> ATTRS{idVendor}=="046d", GOTO="solaar_apply"
> 
> # Lenovo nano receiver
> ATTRS{idVendor}=="17ef", ATTRS{idProduct}=="6042", GOTO="solaar_apply"
> 
> # Bluetooth-connected Logitech devices
> KERNELS == "0005:046D:*", GOTO="solaar_apply"
> 
> GOTO="solaar_end"
> 
> LABEL="solaar_apply"
> 
> # Allow any seated user to access the receiver.
> # uaccess: modern ACL-enabled udev
> TAG+="uaccess"
> 
> # Grant members of the "plugdev" group access to receiver (useful for SSH users)
1a29,31
> 
> LABEL="solaar_end"
> # vim: ft=udevrules

I have no idea how it happened. I did rebuild the initrd, so I will see if I can get Mongodb going now.

I'll update the thread with what ever progress I can make.

pan64 · 05-06-2024, 05:56 AM

sorry, probably not important at all, it is mongodb, not momgodb

camorri · 05-06-2024, 06:00 AM

Thank-you Pan64, I fixed the typo.

Petri Kaukasoina · 05-06-2024, 06:28 AM

Quote:

Originally Posted by camorri

Well, the diff shows the copy in /etc/udev/rules.d/ missing the following:

It seems the one in /etc only had

Code:

MODE="0660", GROUP="plugdev"

which means it changed the group and mode of all the device nodes to the same as what you saw with /dev/null.

camorri · 05-06-2024, 10:39 AM

The permission issues are fixed. I'm closing this thread, thank-you all who responded.