starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-26 06:35:54 +03:00

[GH-ISSUE #1254] RUST & some other games - wrong permissions on /sys = crash on boot #970

New issue

Closed

opened 2026-02-27 02:54:36 +03:00 by kerem · 26 comments

kerem commented

2026-02-27 02:54:36 +03:00

Owner

Originally created by @UltimateByte on GitHub (Jan 15, 2017).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1254

Originally assigned to: @UltimateByte on GitHub.

Symptom: the game server just stops while loading after Initializing 74 stability supports

Update3: It's actually not a kernel itself issue, but rather an issue because of permissions on /sys

Fix thanks @cedarlug :
(with elevated privileges)

chmod a+rx /sys /sys/class /sys/class/net

Originally created by @UltimateByte on GitHub (Jan 15, 2017). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1254 Originally assigned to: @UltimateByte on GitHub. Symptom: the game server just stops while loading after `Initializing 74 stability supports` Update3: It's actually not a kernel itself issue, but rather an issue because of permissions on `/sys` Fix thanks @cedarlug : (with elevated privileges) ````bash chmod a+rx /sys /sys/class /sys/class/net ````

kerem

2026-02-27 02:54:36 +03:00

closed this issue
added the
type: bug
label

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@cedarlug commented on GitHub (Jan 15, 2017):

Details? Link?

@cedarlug commented on GitHub (Jan 15, 2017): Details? Link?

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 15, 2017):

You're right, main post edited.
Was just a reminder in the first place.

@UltimateByte commented on GitHub (Jan 15, 2017): You're right, main post edited. Was just a reminder in the first place.

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Jan 16, 2017):

Ohhhh Garry not again...

@dgibbs64 commented on GitHub (Jan 16, 2017): Ohhhh Garry not again... ![Image of Yaktocat](https://pbs.twimg.com/media/CPVmLNjUEAEBBkQ.png)

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 17, 2017):

@Edou68FR Kernel info ? Distro ? Logs outputs ? ./rustserver postdetails output ?
Without this, we can't really go further into it.

@UltimateByte commented on GitHub (Jan 17, 2017): @Edou68FR Kernel info ? Distro ? Logs outputs ? ./rustserver postdetails output ? Without this, we can't really go further into it.

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 17, 2017):

Thanks. Script logs are not useful there though, since this is not an LGSM issue but rather Rust itself.
So game logs output would be more useful. Watch out for your rcon password that may be displayed several times in it.

@UltimateByte commented on GitHub (Jan 17, 2017): Thanks. Script logs are not useful there though, since this is not an LGSM issue but rather Rust itself. So game logs output would be more useful. Watch out for your rcon password that may be displayed several times in it.

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 17, 2017):

Thanks.
Well, it crashes right at the same place than MattiEXC from discord.

Initializing 74 stability supports
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

For now the only clue I got is the kernel that differs. Since I couldn't find a good working tutorial on how to revert to the default kernel, I can't even point you out to this for testing.

Maybe @cedarlug , our Sherlock Holmes got an idea ?

@UltimateByte commented on GitHub (Jan 17, 2017): Thanks. Well, it crashes right at the same place than MattiEXC from discord. ```` Initializing 74 stability supports (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) ```` For now the only clue I got is the kernel that differs. Since I couldn't find a good working tutorial on how to revert to the default kernel, I can't even point you out to this for testing. Maybe @cedarlug , our Sherlock Holmes got an idea ?

kerem commented

2026-02-27 02:54:36 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 17, 2017):

Just called OVH talking about the issue.

I'm quoting, but this is me summing up what they said:

"Some machines had issues with the default kernel, that's why it's been removed. We cannot add all functionalities to OVH kernels. Also, we don't support software. So if you point out an issue with an existing functionality, then we can fix it. But otherwise, it's up to the user to add what they need to their kernel and recompile it."

So any kernel expert is welcome to help... Unless we figure out the issue comes from somewhere else.

@UltimateByte commented on GitHub (Jan 17, 2017): Just called OVH talking about the issue. I'm quoting, but this is me summing up what they said: "Some machines had issues with the default kernel, that's why it's been removed. We cannot add all functionalities to OVH kernels. Also, we don't support software. So if you point out an issue with an existing functionality, then we can fix it. But otherwise, it's up to the user to add what they need to their kernel and recompile it." So any kernel expert is welcome to help... Unless we figure out the issue comes from somewhere else.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@Xseba360 commented on GitHub (Jan 18, 2017):

I recommend updating to latest ovh kernel from their FTP as it seems to work for me 👍

@Xseba360 commented on GitHub (Jan 18, 2017): I recommend updating to latest ovh kernel from their FTP as it seems to work for me 👍

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@jok-dev commented on GitHub (Jan 18, 2017):

What kernel are you running as lastest? I'm running latest production 3.14.32

@jok-dev commented on GitHub (Jan 18, 2017): What kernel are you running as lastest? I'm running latest production 3.14.32

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 18, 2017):

From discord:

Xseba360 - Yesterday at 2:37 PM
interesting, on ovh kernel 4.8.15-xxxx-grs-ipv6-64 the rust server doesnt seem to be starting

@UltimateByte commented on GitHub (Jan 18, 2017): From discord: > Xseba360 - Yesterday at 2:37 PM > interesting, on ovh kernel 4.8.15-xxxx-grs-ipv6-64 the rust server doesnt seem to be starting

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@Xseba360 commented on GitHub (Jan 19, 2017):

@UltimateByte, disregard that, it just took longer than I'm used to with source servers, however console i/o isn't working? (Is it supposed to?).

So in conclusion, latest experimental should work. But as the name suggest it's up to you ;)

@Xseba360 commented on GitHub (Jan 19, 2017): @UltimateByte, disregard that, it just took longer than I'm used to with source servers, however console i/o isn't working? (Is it supposed to?). So in conclusion, latest experimental should work. But as the name suggest it's up to you ;)

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@cedarlug commented on GitHub (Jan 19, 2017):

@Xseba360 The Rust console isn't functional in Linux, other than this: "If the console hasn't closed, then the Rust server hasn't died."

Glad that the new kernel worked for you.

@cedarlug commented on GitHub (Jan 19, 2017): @Xseba360 The Rust console isn't functional in Linux, other than this: "If the console hasn't closed, then the Rust server hasn't died." Glad that the new kernel worked for you.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 19, 2017):

We could add a warning upon server start if faulty kernel is detected. There is already a function for machine requirements.

@UltimateByte commented on GitHub (Jan 19, 2017): We could add a warning upon server start if faulty kernel is detected. There is already a function for machine requirements.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@Xseba360 commented on GitHub (Jan 23, 2017):

http://help.ovh.com/KernelInstall

@Xseba360 commented on GitHub (Jan 23, 2017): http://help.ovh.com/KernelInstall

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@TNTUP commented on GitHub (Jan 23, 2017):

Same here, https://hastebin.com/obajiboqok

EDIT: Multiple attemps, I give up. Thinking of updating the kernel, but im lazy as f* to do it and rebooting :/

@TNTUP commented on GitHub (Jan 23, 2017): Same here, https://hastebin.com/obajiboqok EDIT: Multiple attemps, I give up. Thinking of updating the kernel, but im lazy as f* to do it and rebooting :/

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 25, 2017):

Update:
Cedar's fix is enough to fix the issue !

chmod a+x /sys 
chmod a+rx /sys/class 
chmod a+r /sys/class/net

I'd even add that chmod a+rx /sys/class/net would even be better if we want to match a sane default Debian install.

@UltimateByte commented on GitHub (Jan 25, 2017): Update: Cedar's fix is enough to fix the issue ! ```` chmod a+x /sys chmod a+rx /sys/class chmod a+r /sys/class/net ```` I'd even add that `chmod a+rx /sys/class/net` would even be better if we want to match a sane default Debian install.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@braunsonm commented on GitHub (Jan 26, 2017):

Not much that can be done about this on LGSM's end. The most that can maybe be done is for LGSM to run a check and prompt the user about the permission issue.
If necessary I will do that. @UltimateByte

@braunsonm commented on GitHub (Jan 26, 2017): Not much that can be done about this on LGSM's end. The most that can maybe be done is for LGSM to run a check and prompt the user about the permission issue. If necessary I will do that. @UltimateByte

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 26, 2017):

I'll do it, tonight, thanks @ChaosMTA , I'm kinda committed to fix Rust for the end of my life, lol.
I'll ask @dgibbs64 , but I think i'll add it to fix_rust.sh
https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/fix_rust.sh

Algorithm idea is:
Check 3 dirs for right permissions
if any permission is wrong, check if sudo is available and attempt to fix
if not fixed, display error with commands to run as root
core_exit.sh

@UltimateByte commented on GitHub (Jan 26, 2017): I'll do it, tonight, thanks @ChaosMTA , I'm kinda committed to fix Rust for the end of my life, lol. I'll ask @dgibbs64 , but I think i'll add it to fix_rust.sh https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/fix_rust.sh Algorithm idea is: Check 3 dirs for right permissions if any permission is wrong, check if sudo is available and attempt to fix if not fixed, display error with commands to run as root core_exit.sh

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 27, 2017):

Since I forgot to ask where to put this check (either in check_permissions.sh since it's been reported to affect other games as well, or fix_rust.sh), i'll add my code here. This is 100% untested, yet, so this might not be perfect.

# Check if user is sudoer; if he is, value should be greater than 0
issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)"

# Checks for permission errors in /sys directory
fn_sys_perm_errors(){
	# Reset test variables
	sysdirpermerror="0"
	classdirpermerror="0"
	netdirpermerror="0"
	# Check permissions
	if [ ! -r "/sys" ]||[ ! -x "/sys" ]; then
		sysdirpermerror="1"
	fi
	if [ ! -r "/sys/class" ]||[ ! -x "/sys/class" ]; then
		classdirpermerror="1"
	if [ ! -r "/sys/class/net" ]||[ ! -x "sys/class/net" ]; then
		netdirpermerror="1"
	fi
}

# Displays /sys related permission errors to the user
fn_sys_perm_error_display(){
	# /sys, /sys/class and /sys/class/net should be readable & executable
	# If any error was found
	if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then
		fn_print_error_nl "Permission error(s) found:"
		fn_script_log_error "Permission error(s) found:"
		if [ "${sysdirpermerror}" == "1" ]; then
			echo " * /sys permissions are $(stat -c %a /sys) instead of expected 555"
			fn_script_log "/sys permissions are $(stat -c %a /sys) instead of expected 555"
		fi
		if [ "${classdirpermerror}" == "1" ]; then
			echo " * /sys/class permissions are $(stat -c %a /sys/class) instead of expected 755"
			fn_script_log "/sys/class permissions are $(stat -c %a /sys/class) instead of expected 755"
		fi
		if [ "${netdirpermerror}" == "1" ]; then
			echo " * /sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755"
			fn_script_log "/sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755"
		fi
		echo ""
		fn_print_information_nl "This error causes servers to fail starting properly"
		fn_script_log_info "This error causes servers to fail starting properly."
}

# Attempt to fix /sys related permission errors if sudo is available, exits otherwise
fn_fix_sys_perm_errors(){
	if [ "${sudoer}" -lt "0" ]; then
		fn_print_information_nl "Automatically fixing permissions"
		fn_script_log_info "Automatically fixing permissions."
		if [ "${sysdirpermerror}" == "1" ]; then
			sudo chmod a+rx "/sys"
		fi
		if [ "${classdirpermerror}" == "1" ]; then
			sudo chmod a+rx "/sys/class"
		fi
		if [ "${netdirpermerror}" == "1" ]; then
			sudo a+rx "/sys/class/net"
		fi
	else
	fn_fix_sys_perm_manually_msg
	fi
	# Run check again to see if it's fixed
	fn_sys_perm_errors
	if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then
		fn_print_error "Could not fix permissions"
		fn_script_log_error "Could not fix permissions."
		fn_fix_sys_perm_manually_msg
	else
		fn_print_ok "Automatically fixing permissions"
	fi
}

fn_fix_sys_perm_manually_msg(){
	echo ""
	fn_print_information_nl "To fix this issue, run this command as root:"
	fn_script_log_info "To fix this issue, run this command as root:"
	echo " * chmod a+rx /sys /sys/class /sys/class/net"
	fn_script_log "chmod a+rx /sys /sys/class /sys/class/net"
	core_exit.sh
}

# Permission errors on /sys directories
fn_sys_perm_errors
fn_sys_perm_error_display
fn_fix_sys_perm_errors

@UltimateByte commented on GitHub (Jan 27, 2017): Since I forgot to ask where to put this check (either in check_permissions.sh since it's been reported to affect other games as well, or fix_rust.sh), i'll add my code here. This is 100% untested, yet, so this might not be perfect. ````bash # Check if user is sudoer; if he is, value should be greater than 0 issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)" # Checks for permission errors in /sys directory fn_sys_perm_errors(){ # Reset test variables sysdirpermerror="0" classdirpermerror="0" netdirpermerror="0" # Check permissions if [ ! -r "/sys" ]||[ ! -x "/sys" ]; then sysdirpermerror="1" fi if [ ! -r "/sys/class" ]||[ ! -x "/sys/class" ]; then classdirpermerror="1" if [ ! -r "/sys/class/net" ]||[ ! -x "sys/class/net" ]; then netdirpermerror="1" fi } # Displays /sys related permission errors to the user fn_sys_perm_error_display(){ # /sys, /sys/class and /sys/class/net should be readable & executable # If any error was found if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then fn_print_error_nl "Permission error(s) found:" fn_script_log_error "Permission error(s) found:" if [ "${sysdirpermerror}" == "1" ]; then echo " * /sys permissions are $(stat -c %a /sys) instead of expected 555" fn_script_log "/sys permissions are $(stat -c %a /sys) instead of expected 555" fi if [ "${classdirpermerror}" == "1" ]; then echo " * /sys/class permissions are $(stat -c %a /sys/class) instead of expected 755" fn_script_log "/sys/class permissions are $(stat -c %a /sys/class) instead of expected 755" fi if [ "${netdirpermerror}" == "1" ]; then echo " * /sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755" fn_script_log "/sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755" fi echo "" fn_print_information_nl "This error causes servers to fail starting properly" fn_script_log_info "This error causes servers to fail starting properly." } # Attempt to fix /sys related permission errors if sudo is available, exits otherwise fn_fix_sys_perm_errors(){ if [ "${sudoer}" -lt "0" ]; then fn_print_information_nl "Automatically fixing permissions" fn_script_log_info "Automatically fixing permissions." if [ "${sysdirpermerror}" == "1" ]; then sudo chmod a+rx "/sys" fi if [ "${classdirpermerror}" == "1" ]; then sudo chmod a+rx "/sys/class" fi if [ "${netdirpermerror}" == "1" ]; then sudo a+rx "/sys/class/net" fi else fn_fix_sys_perm_manually_msg fi # Run check again to see if it's fixed fn_sys_perm_errors if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then fn_print_error "Could not fix permissions" fn_script_log_error "Could not fix permissions." fn_fix_sys_perm_manually_msg else fn_print_ok "Automatically fixing permissions" fi } fn_fix_sys_perm_manually_msg(){ echo "" fn_print_information_nl "To fix this issue, run this command as root:" fn_script_log_info "To fix this issue, run this command as root:" echo " * chmod a+rx /sys /sys/class /sys/class/net" fn_script_log "chmod a+rx /sys /sys/class /sys/class/net" core_exit.sh } # Permission errors on /sys directories fn_sys_perm_errors fn_sys_perm_error_display fn_fix_sys_perm_errors ````

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@cedarlug commented on GitHub (Jan 27, 2017):

I'm skeptical regarding the sudo check for a couple of reasons:
issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)"
First, this is asking for a no-password sudo, which is rare for a sudoer. And would incorrectly fail if she has sudo privileges but requires a password.

Second, if the user doesn't have any sudo privileges, this drops an alert in the system logs as a failed user privilege escalation attempt.

As far as I know, the only "safe" way to check to see if a user has sudo permissions is sudo --list. Without a password, it would be sudo -n --list. In either case, if a user does not have sudo privileges this does not drop an alert in the system logs.

Consider using the check sudo --list and requiring the user to enter her password.

@cedarlug commented on GitHub (Jan 27, 2017): I'm skeptical regarding the sudo check for a couple of reasons: `issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)"` First, this is asking for a no-password sudo, which is rare for a sudoer. And would incorrectly fail if she has sudo privileges but requires a password. Second, if the user doesn't have any sudo privileges, this drops an alert in the system logs as a failed user privilege escalation attempt. As far as I know, the only "safe" way to check to see if a user has sudo permissions is `sudo --list`. Without a password, it would be `sudo -n --list`. In either case, if a user does not have sudo privileges this does not drop an alert in the system logs. Consider using the check `sudo --list` and requiring the user to enter her password.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 27, 2017):

Interesting thoughts.
I checked there in the meantime.
https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/check_deps.sh#L83

sudo -v > /dev/null 2>&1
if [ $? -eq 0 ]; then
...

In the end, it just checks if sudo is installed. Maybe it's the way to go?

@UltimateByte commented on GitHub (Jan 27, 2017): Interesting thoughts. I checked there in the meantime. https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/check_deps.sh#L83 ````bash sudo -v > /dev/null 2>&1 if [ $? -eq 0 ]; then ... ```` In the end, it just checks if sudo is installed. Maybe it's the way to go?

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@braunsonm commented on GitHub (Jan 27, 2017):

Should note that I've heard from people in discord that this issue also affects CS:GO servers. Might be something we should just do as an LGSM pre_req test for all servers.

@braunsonm commented on GitHub (Jan 27, 2017): Should note that I've heard from people in discord that this issue also affects CS:GO servers. Might be something we should just do as an LGSM pre_req test for all servers.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 27, 2017):

Yep.
One question though, would make this code a bit more simple:
Does any distro have /sys/class/net dirs?
I know debian/ubuntu/centos do have it, don't know for others.

Current work here
https://github.com/GameServerManagers/LinuxGSM/blob/feature/ultimatebyte-271/lgsm/functions/check_permissions.sh

@UltimateByte commented on GitHub (Jan 27, 2017): Yep. One question though, would make this code a bit more simple: Does any distro have /sys/class/net dirs? I know debian/ubuntu/centos do have it, don't know for others. Current work here https://github.com/GameServerManagers/LinuxGSM/blob/feature/ultimatebyte-271/lgsm/functions/check_permissions.sh

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 27, 2017):

Sample output with & without sudo access:

@UltimateByte commented on GitHub (Jan 27, 2017): Sample output with & without sudo access: ![sample](http://i.imgur.com/0Cg0Txv.jpg)

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 29, 2017):

Warning and autofix if sudo is available: merged to master.

@UltimateByte commented on GitHub (Jan 29, 2017): Warning and autofix if sudo is available: merged to master.

kerem commented

2026-02-27 02:54:37 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 19, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 19, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.