If rc.local is run as root why can't it touch a file
I wish to execute a script every time on boot-up using /etc/rc.local.
My script for example is called startscript.sh which is stored in /home/debian as below. It first tries to create a file called test.log and then does other things.
However, I read the error on boot-up that touch: cannot touch ‘test.log’: Permission denied
How is this even possible if, from what I understand, rc.local gets run as root, therefore anything it executes should be run as root as well, and hence test.log should be created regardless?
startscript.sh:
#!/bin/sh
touch test.log
#... other stuff
rc.local snippet:
#!/bin/sh -e
#.. other stuff
sh /home/debian/startscript.sh
debian permissions root touch rc.local
edited Feb 6 at 18:36
Kusalananda
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
|
show 4 more comments
I wish to execute a script every time on boot-up using /etc/rc.local.
My script for example is called startscript.sh which is stored in /home/debian as below. It first tries to create a file called test.log and then does other things.
However, I read the error on boot-up that touch: cannot touch ‘test.log’: Permission denied
How is this even possible if, from what I understand, rc.local gets run as root, therefore anything it executes should be run as root as well, and hence test.log should be created regardless?
startscript.sh:
#!/bin/sh
touch test.log
#... other stuff
rc.local snippet:
#!/bin/sh -e
#.. other stuff
sh /home/debian/startscript.sh
debian permissions root touch rc.local
edited Feb 6 at 18:36
Kusalananda
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
2
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,/procor/sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory ofstartscript.sh?
– derobert
Feb 6 at 18:41
1
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your/filesystem mounted as read only? Eithertouchis being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.
– kemotep
Feb 6 at 18:51
@derobert and @Engineer999: unless the#.. other stuffincludes any explicitcdcommands, then the current working directory ofstartscript.shwill be/, and so the file it's attempting to create will be/test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.
– telcoM
Feb 6 at 19:16
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49
|
show 4 more comments
I wish to execute a script every time on boot-up using /etc/rc.local.
My script for example is called startscript.sh which is stored in /home/debian as below. It first tries to create a file called test.log and then does other things.
However, I read the error on boot-up that touch: cannot touch ‘test.log’: Permission denied
How is this even possible if, from what I understand, rc.local gets run as root, therefore anything it executes should be run as root as well, and hence test.log should be created regardless?
startscript.sh:
#!/bin/sh
touch test.log
#... other stuff
rc.local snippet:
#!/bin/sh -e
#.. other stuff
sh /home/debian/startscript.sh
debian permissions root touch rc.local
edited Feb 6 at 18:36
Kusalananda
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
I wish to execute a script every time on boot-up using /etc/rc.local.
My script for example is called startscript.sh which is stored in /home/debian as below. It first tries to create a file called test.log and then does other things.
However, I read the error on boot-up that touch: cannot touch ‘test.log’: Permission denied
How is this even possible if, from what I understand, rc.local gets run as root, therefore anything it executes should be run as root as well, and hence test.log should be created regardless?
startscript.sh:
#!/bin/sh
touch test.log
#... other stuff
rc.local snippet:
#!/bin/sh -e
#.. other stuff
sh /home/debian/startscript.sh
debian permissions root touch rc.local
debian permissions root touch rc.local
edited Feb 6 at 18:36
Kusalananda
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
edited Feb 6 at 18:36
Kusalananda
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
edited Feb 6 at 18:36
Kusalananda
131k17249408
edited Feb 6 at 18:36
Kusalananda
131k17249408
edited Feb 6 at 18:36
Kusalananda
131k17249408
131k17249408
asked Feb 6 at 17:50
Engineer999Engineer999
1626
asked Feb 6 at 17:50
Engineer999Engineer999
1626
asked Feb 6 at 17:50
Engineer999Engineer999
1626
1626
2
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,/procor/sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory ofstartscript.sh?
– derobert
Feb 6 at 18:41
1
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your/filesystem mounted as read only? Eithertouchis being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.
– kemotep
Feb 6 at 18:51
@derobert and @Engineer999: unless the#.. other stuffincludes any explicitcdcommands, then the current working directory ofstartscript.shwill be/, and so the file it's attempting to create will be/test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.
– telcoM
Feb 6 at 19:16
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49
|
show 4 more comments
2
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,/procor/sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory ofstartscript.sh?
– derobert
Feb 6 at 18:41
1
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your/filesystem mounted as read only? Eithertouchis being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.
– kemotep
Feb 6 at 18:51
@derobert and @Engineer999: unless the#.. other stuffincludes any explicitcdcommands, then the current working directory ofstartscript.shwill be/, and so the file it's attempting to create will be/test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.
– telcoM
Feb 6 at 19:16
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49
2
2
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,
/proc or /sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory of startscript.sh?– derobert
Feb 6 at 18:41
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,
/proc or /sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory of startscript.sh?– derobert
Feb 6 at 18:41
1
1
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your
/ filesystem mounted as read only? Either touch is being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.– kemotep
Feb 6 at 18:51
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your
/ filesystem mounted as read only? Either touch is being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.– kemotep
Feb 6 at 18:51
@derobert and @Engineer999: unless the
#.. other stuff includes any explicit cd commands, then the current working directory of startscript.sh will be /, and so the file it's attempting to create will be /test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.– telcoM
Feb 6 at 19:16
@derobert and @Engineer999: unless the
#.. other stuff includes any explicit cd commands, then the current working directory of startscript.sh will be /, and so the file it's attempting to create will be /test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.– telcoM
Feb 6 at 19:16
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49
|
show 4 more comments
1 Answer
1
active
oldest
votes
There are two problems with that approach. One, rc.local is executed by root, so all the files it creates will be owned by root unless you run chown on them. Second, it's a security hole in that root executes code which is potentially modifiable by a user without root privilege.
A better way is to use the @reboot time specifier with cron as an unprivileged user. If you already have a crontab file, edit it to add this line and then run the crontab <yourcrontab> command. Or use the crontab -e command to enter this line directly.
@reboot /home/debian/startscript.sh
Note that you don't need sh if the script is executable because it starts with #!/bin/sh.
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499118%2fif-rc-local-is-run-as-root-why-cant-it-touch-a-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are two problems with that approach. One, rc.local is executed by root, so all the files it creates will be owned by root unless you run chown on them. Second, it's a security hole in that root executes code which is potentially modifiable by a user without root privilege.
A better way is to use the @reboot time specifier with cron as an unprivileged user. If you already have a crontab file, edit it to add this line and then run the crontab <yourcrontab> command. Or use the crontab -e command to enter this line directly.
@reboot /home/debian/startscript.sh
Note that you don't need sh if the script is executable because it starts with #!/bin/sh.
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
add a comment |
There are two problems with that approach. One, rc.local is executed by root, so all the files it creates will be owned by root unless you run chown on them. Second, it's a security hole in that root executes code which is potentially modifiable by a user without root privilege.
A better way is to use the @reboot time specifier with cron as an unprivileged user. If you already have a crontab file, edit it to add this line and then run the crontab <yourcrontab> command. Or use the crontab -e command to enter this line directly.
@reboot /home/debian/startscript.sh
Note that you don't need sh if the script is executable because it starts with #!/bin/sh.
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
add a comment |
There are two problems with that approach. One, rc.local is executed by root, so all the files it creates will be owned by root unless you run chown on them. Second, it's a security hole in that root executes code which is potentially modifiable by a user without root privilege.
A better way is to use the @reboot time specifier with cron as an unprivileged user. If you already have a crontab file, edit it to add this line and then run the crontab <yourcrontab> command. Or use the crontab -e command to enter this line directly.
@reboot /home/debian/startscript.sh
Note that you don't need sh if the script is executable because it starts with #!/bin/sh.
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
There are two problems with that approach. One, rc.local is executed by root, so all the files it creates will be owned by root unless you run chown on them. Second, it's a security hole in that root executes code which is potentially modifiable by a user without root privilege.
A better way is to use the @reboot time specifier with cron as an unprivileged user. If you already have a crontab file, edit it to add this line and then run the crontab <yourcrontab> command. Or use the crontab -e command to enter this line directly.
@reboot /home/debian/startscript.sh
Note that you don't need sh if the script is executable because it starts with #!/bin/sh.
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
answered Feb 6 at 19:09
Ken JacksonKen Jackson
1063
1063
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
add a comment |
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
2
2
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
Or one could write a native service definition for whatever one's service manager is, with appropriate user account settings. unix.stackexchange.com/a/471871/5132
– JdeBP
Feb 6 at 19:56
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
I don't want a better way. I know Cron works ok for this. I'm just trying to understand why rc.local won't work
– Engineer999
Feb 7 at 15:45
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499118%2fif-rc-local-is-run-as-root-why-cant-it-touch-a-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You can get permission denied even as root: try to write to a read-only filesystem, try to write to a special filesystem (e.g.,
/procor/sys) in a not-permitted way, try to write to a network filesystem (server does permission checks, too), etc... You haven't really given us enough information to figure out which you're seeing. What is the current working directory ofstartscript.sh?– derobert
Feb 6 at 18:41
1
To build off of user derobert, please include what permissions your script has, as well as the permissions of the working directory of the script or where the script is being run from. Is your
/filesystem mounted as read only? Eithertouchis being run in a filesystem that is mounted as read-only or the script is being run before the filesystem has assigned the relevant options in fstab during the boot up process. The first option is far more likely than the latter I feel.– kemotep
Feb 6 at 18:51
@derobert and @Engineer999: unless the
#.. other stuffincludes any explicitcdcommands, then the current working directory ofstartscript.shwill be/, and so the file it's attempting to create will be/test.log. When you log in, your working directory is set to be your home directory (on modern systems, most likely by the PAM session module), but for start-up scripts, this convenience does not exist.– telcoM
Feb 6 at 19:16
@derobert The current working directory for startscript.sh is /home/debian as shown in the rc.local file snippet
– Engineer999
Feb 7 at 15:46
@kemotep The file system is not read-only. This is why I don't understand the problem. It should create the file . I also did sudo chmod 777 /home/debian to ensure everyone has permissions and it still complains
– Engineer999
Feb 7 at 15:49