-bash: /dev/null: Permission denied
I'm trying to create a new user on a Centos 6 system.
First, I do
useradd kevin
Then, I tried to run commands as that user
su - kevin
However, I get the following error messages
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$
And I can't do very much as that user.
The permissions on /dev/null are as follows:
-rwxr-xr-x 1 root root 9 Jul 25 17:07 null
Roughly the same as they are on my Mac,
crw-rw-rw- 1 root wheel 3, 2 Jul 25 14:08 null
It's possible, but really unlikely, that I touched dev.
As the root user, I tried adding kevin to the root group:
usermod -a -G root kevin
However I still am getting /dev/null permission denied errors.
Why can't the new user write to /dev/null? What groups should the new user be a part of? Am I not impersonating the user correctly? Is there a beginners guide to setting up users/permissions on Linux?
Thanks,
Kevin
permissions
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
add a comment |
I'm trying to create a new user on a Centos 6 system.
First, I do
useradd kevin
Then, I tried to run commands as that user
su - kevin
However, I get the following error messages
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$
And I can't do very much as that user.
The permissions on /dev/null are as follows:
-rwxr-xr-x 1 root root 9 Jul 25 17:07 null
Roughly the same as they are on my Mac,
crw-rw-rw- 1 root wheel 3, 2 Jul 25 14:08 null
It's possible, but really unlikely, that I touched dev.
As the root user, I tried adding kevin to the root group:
usermod -a -G root kevin
However I still am getting /dev/null permission denied errors.
Why can't the new user write to /dev/null? What groups should the new user be a part of? Am I not impersonating the user correctly? Is there a beginners guide to setting up users/permissions on Linux?
Thanks,
Kevin
permissions
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
1
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If youcat /dev/null, does it look like something you recently used?
– Mark Plotnick
Jul 25 '14 at 21:18
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23
add a comment |
I'm trying to create a new user on a Centos 6 system.
First, I do
useradd kevin
Then, I tried to run commands as that user
su - kevin
However, I get the following error messages
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$
And I can't do very much as that user.
The permissions on /dev/null are as follows:
-rwxr-xr-x 1 root root 9 Jul 25 17:07 null
Roughly the same as they are on my Mac,
crw-rw-rw- 1 root wheel 3, 2 Jul 25 14:08 null
It's possible, but really unlikely, that I touched dev.
As the root user, I tried adding kevin to the root group:
usermod -a -G root kevin
However I still am getting /dev/null permission denied errors.
Why can't the new user write to /dev/null? What groups should the new user be a part of? Am I not impersonating the user correctly? Is there a beginners guide to setting up users/permissions on Linux?
Thanks,
Kevin
permissions
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
I'm trying to create a new user on a Centos 6 system.
First, I do
useradd kevin
Then, I tried to run commands as that user
su - kevin
However, I get the following error messages
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$
And I can't do very much as that user.
The permissions on /dev/null are as follows:
-rwxr-xr-x 1 root root 9 Jul 25 17:07 null
Roughly the same as they are on my Mac,
crw-rw-rw- 1 root wheel 3, 2 Jul 25 14:08 null
It's possible, but really unlikely, that I touched dev.
As the root user, I tried adding kevin to the root group:
usermod -a -G root kevin
However I still am getting /dev/null permission denied errors.
Why can't the new user write to /dev/null? What groups should the new user be a part of? Am I not impersonating the user correctly? Is there a beginners guide to setting up users/permissions on Linux?
Thanks,
Kevin
permissions
permissions
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
asked Jul 25 '14 at 21:10
Kevin BurkeKevin Burke
5613723
5613723
1
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If youcat /dev/null, does it look like something you recently used?
– Mark Plotnick
Jul 25 '14 at 21:18
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23
add a comment |
1
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If youcat /dev/null, does it look like something you recently used?
– Mark Plotnick
Jul 25 '14 at 21:18
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23
1
1
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If you
cat /dev/null, does it look like something you recently used?– Mark Plotnick
Jul 25 '14 at 21:18
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If you
cat /dev/null, does it look like something you recently used?– Mark Plotnick
Jul 25 '14 at 21:18
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23
add a comment |
5 Answers
5
active
oldest
votes
Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do
rm -f /dev/null; mknod -m 666 /dev/null c 1 3
As @Flow has noted in a comment, you must be root to do this.
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
add a comment |
This should fix the issue (as root):
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
add a comment |
The solution suggested by Mark did not work on OpenBSD.
However
mknod -m 666 /dev/null -c 2 2
did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.
answered Mar 15 '15 at 16:53
meschimeschi
313
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
Unfortunately, different operating systems use different major/minor numbers for/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used1,3for /dev/null going back to at least 2001. On FreeBSD, I've seen0,6,15,0,17,0, and20,0. OpenBSD uses2,2. On OpenBSD, you actually don't need to know the numbers; you can run# cd /dev; ./MAKEDEV std.
– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in themknodcommand by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.
– Jonathan Leffler
Mar 4 '16 at 17:27
add a comment |
Posting the Mac OS X answer for posterity...
sudo su
&& rm -rf /dev/null
&& mknod /dev/null c 3 2
&& chmod 666 /dev/null
answered Aug 23 '18 at 15:23
JulianJulian
1012
add a comment |
This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.
Turned out the problem was windows newlines in the script file. Running :
dos2unix.exe c:pathtoscript.sh
Solved the issue for me.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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%2f146633%2fbash-dev-null-permission-denied%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do
rm -f /dev/null; mknod -m 666 /dev/null c 1 3
As @Flow has noted in a comment, you must be root to do this.
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
add a comment |
Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do
rm -f /dev/null; mknod -m 666 /dev/null c 1 3
As @Flow has noted in a comment, you must be root to do this.
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
add a comment |
Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do
rm -f /dev/null; mknod -m 666 /dev/null c 1 3
As @Flow has noted in a comment, you must be root to do this.
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do
rm -f /dev/null; mknod -m 666 /dev/null c 1 3
As @Flow has noted in a comment, you must be root to do this.
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
edited Jan 18 '17 at 15:25
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
answered Jul 25 '14 at 21:31
Mark PlotnickMark Plotnick
18.4k24066
18.4k24066
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
add a comment |
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
11
11
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
If by "someone" you mean "me", then yes :)
– Kevin Burke
Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions?
– Mani
Apr 5 '18 at 5:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. How to detect on Linux chmod of a file
– Mark Plotnick
Apr 5 '18 at 16:14
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
The solution fixes the problem but the issue reoccurs. Why?
– Abhishek Soni
Oct 6 '18 at 3:40
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
@AbhishekSoni You might try auditing, as described in Display a file's history (list of users that have modified a file)
– Mark Plotnick
Oct 11 '18 at 17:47
add a comment |
This should fix the issue (as root):
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
add a comment |
This should fix the issue (as root):
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
add a comment |
This should fix the issue (as root):
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
This should fix the issue (as root):
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
answered Jul 25 '14 at 21:27
jlliagrejlliagre
47.5k784136
47.5k784136
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
add a comment |
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
2
2
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
This one also works on Mac/BSD
– redolent
Feb 11 '15 at 23:06
add a comment |
The solution suggested by Mark did not work on OpenBSD.
However
mknod -m 666 /dev/null -c 2 2
did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.
answered Mar 15 '15 at 16:53
meschimeschi
313
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
Unfortunately, different operating systems use different major/minor numbers for/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used1,3for /dev/null going back to at least 2001. On FreeBSD, I've seen0,6,15,0,17,0, and20,0. OpenBSD uses2,2. On OpenBSD, you actually don't need to know the numbers; you can run# cd /dev; ./MAKEDEV std.
– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in themknodcommand by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.
– Jonathan Leffler
Mar 4 '16 at 17:27
add a comment |
The solution suggested by Mark did not work on OpenBSD.
However
mknod -m 666 /dev/null -c 2 2
did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.
answered Mar 15 '15 at 16:53
meschimeschi
313
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
Unfortunately, different operating systems use different major/minor numbers for/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used1,3for /dev/null going back to at least 2001. On FreeBSD, I've seen0,6,15,0,17,0, and20,0. OpenBSD uses2,2. On OpenBSD, you actually don't need to know the numbers; you can run# cd /dev; ./MAKEDEV std.
– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in themknodcommand by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.
– Jonathan Leffler
Mar 4 '16 at 17:27
add a comment |
The solution suggested by Mark did not work on OpenBSD.
However
mknod -m 666 /dev/null -c 2 2
did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.
answered Mar 15 '15 at 16:53
meschimeschi
313
The solution suggested by Mark did not work on OpenBSD.
However
mknod -m 666 /dev/null -c 2 2
did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.
answered Mar 15 '15 at 16:53
meschimeschi
313
edited Jan 4 '17 at 18:18
answered Mar 15 '15 at 16:53
meschimeschi
313
answered Mar 15 '15 at 16:53
meschimeschi
313
answered Mar 15 '15 at 16:53
meschimeschi
313
313
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
Unfortunately, different operating systems use different major/minor numbers for/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used1,3for /dev/null going back to at least 2001. On FreeBSD, I've seen0,6,15,0,17,0, and20,0. OpenBSD uses2,2. On OpenBSD, you actually don't need to know the numbers; you can run# cd /dev; ./MAKEDEV std.
– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in themknodcommand by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.
– Jonathan Leffler
Mar 4 '16 at 17:27
add a comment |
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
Unfortunately, different operating systems use different major/minor numbers for/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used1,3for /dev/null going back to at least 2001. On FreeBSD, I've seen0,6,15,0,17,0, and20,0. OpenBSD uses2,2. On OpenBSD, you actually don't need to know the numbers; you can run# cd /dev; ./MAKEDEV std.
– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in themknodcommand by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.
– Jonathan Leffler
Mar 4 '16 at 17:27
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
Didn't the OP use CentOS rather than OpenBSD?
– ott--
Mar 15 '15 at 18:23
3
3
Unfortunately, different operating systems use different major/minor numbers for
/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used 1,3 for /dev/null going back to at least 2001. On FreeBSD, I've seen 0,6, 15,0, 17,0, and 20,0. OpenBSD uses 2,2. On OpenBSD, you actually don't need to know the numbers; you can run # cd /dev; ./MAKEDEV std .– Mark Plotnick
Mar 16 '15 at 21:54
Unfortunately, different operating systems use different major/minor numbers for
/dev/null, and there's no standard. OP asked about CentOS 6. Linux has used 1,3 for /dev/null going back to at least 2001. On FreeBSD, I've seen 0,6, 15,0, 17,0, and 20,0. OpenBSD uses 2,2. On OpenBSD, you actually don't need to know the numbers; you can run # cd /dev; ./MAKEDEV std .– Mark Plotnick
Mar 16 '15 at 21:54
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in the
mknod command by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.– Jonathan Leffler
Mar 4 '16 at 17:27
Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in the
mknod command by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers.– Jonathan Leffler
Mar 4 '16 at 17:27
add a comment |
Posting the Mac OS X answer for posterity...
sudo su
&& rm -rf /dev/null
&& mknod /dev/null c 3 2
&& chmod 666 /dev/null
answered Aug 23 '18 at 15:23
JulianJulian
1012
add a comment |
Posting the Mac OS X answer for posterity...
sudo su
&& rm -rf /dev/null
&& mknod /dev/null c 3 2
&& chmod 666 /dev/null
answered Aug 23 '18 at 15:23
JulianJulian
1012
add a comment |
Posting the Mac OS X answer for posterity...
sudo su
&& rm -rf /dev/null
&& mknod /dev/null c 3 2
&& chmod 666 /dev/null
answered Aug 23 '18 at 15:23
JulianJulian
1012
Posting the Mac OS X answer for posterity...
sudo su
&& rm -rf /dev/null
&& mknod /dev/null c 3 2
&& chmod 666 /dev/null
answered Aug 23 '18 at 15:23
JulianJulian
1012
answered Aug 23 '18 at 15:23
JulianJulian
1012
answered Aug 23 '18 at 15:23
JulianJulian
1012
answered Aug 23 '18 at 15:23
JulianJulian
1012
1012
add a comment |
add a comment |
This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.
Turned out the problem was windows newlines in the script file. Running :
dos2unix.exe c:pathtoscript.sh
Solved the issue for me.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.
Turned out the problem was windows newlines in the script file. Running :
dos2unix.exe c:pathtoscript.sh
Solved the issue for me.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.
Turned out the problem was windows newlines in the script file. Running :
dos2unix.exe c:pathtoscript.sh
Solved the issue for me.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.
Turned out the problem was windows newlines in the script file. Running :
dos2unix.exe c:pathtoscript.sh
Solved the issue for me.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 26 mins ago
Arthur.VArthur.V
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 26 mins ago
Arthur.VArthur.V
1011
answered 26 mins ago
Arthur.VArthur.V
1011
1011
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Arthur.V is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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%2f146633%2fbash-dev-null-permission-denied%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
1
Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If you
cat /dev/null, does it look like something you recently used?– Mark Plotnick
Jul 25 '14 at 21:18
ah. yes it did. "* master". do you want to add that as the answer & I'll mark it?
– Kevin Burke
Jul 25 '14 at 21:19
You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again.
– Mark Plotnick
Jul 25 '14 at 21:22
My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something
– Kevin Burke
Jul 25 '14 at 21:23