Why is /tmp mounted with permissions 0755 when fstab has 1777?
Clash Royale CLAN TAG#URR8PPP
For /tmp
in /etc/fstab
, I have mode=1777
, but after a reboot, the permissions on /tmp
are 0755
. Another directory /var/tmp
is configured in exactly the same way but does not have this problem (see below). This is a Raspberry Pi running Ubuntu 18.04 Server. The root filesystem is a microSD card mounted read-only.
What is the proper way to make the 1777
permissions permanent?
Here are some additional details (after a fresh boot):
$ touch /tmp/test
touch: cannot touch '/tmp/test': Permission denied
$ whoami
ubuntu
$ ls -ld /tmp /var/tmp
drwxr-xr-x 9 root root 180 Dec 26 13:54 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:54 /var/tmp
$ mount |grep /tmp
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=65536k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=131072k)
$ grep /tmp /etc/fstab
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0
$ sudo systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Sun 2018-01-28 15:58:18 UTC; 10 months 27 days ago
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 642 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2146)
CGroup: /system.slice/tmp.mount
Jan 28 15:58:18 testsystem systemd[1]: Mounting /tmp...
Jan 28 15:58:18 testsystem systemd[1]: Mounted /tmp.
$ grep -R '/tmp' /etc/tmpfiles.d /usr/lib/tmpfiles.d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.Test-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:r! /tmp/.X[0-9]*-lock
/usr/lib/tmpfiles.d/tmp.conf:D /tmp 1777 root root -
/usr/lib/tmpfiles.d/tmp.conf:#q /var/tmp 1777 root root 30d
/usr/lib/tmpfiles.d/tmp.conf:x /tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:x /var/tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /var/tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:R! /tmp/systemd-private-*
/usr/lib/tmpfiles.d/tmp.conf:R! /var/tmp/systemd-private-*
$ sudo chmod 1777 /tmp
$ ls -ld /tmp /var/tmp
drwxrwxrwt 9 root root 180 Dec 26 13:55 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:55 /var/tmp
$ cat /etc/rc.local
#!/bin/bash
service ntp start
exit 0
$ uname -a
Linux testsystem 4.15.0-1030-raspi2 #32-Ubuntu SMP PREEMPT Fri Dec 7 09:15:28 UTC 2018 armv7l armv7l armv7l GNU/Linux
Related, unanswered questions:
- /tmp tmpfs permissions problem
- How can I mount a tmpfs to /tmp via fstab, writable to anyone?
mount fstab chmod tmpfs
|
show 4 more comments
For /tmp
in /etc/fstab
, I have mode=1777
, but after a reboot, the permissions on /tmp
are 0755
. Another directory /var/tmp
is configured in exactly the same way but does not have this problem (see below). This is a Raspberry Pi running Ubuntu 18.04 Server. The root filesystem is a microSD card mounted read-only.
What is the proper way to make the 1777
permissions permanent?
Here are some additional details (after a fresh boot):
$ touch /tmp/test
touch: cannot touch '/tmp/test': Permission denied
$ whoami
ubuntu
$ ls -ld /tmp /var/tmp
drwxr-xr-x 9 root root 180 Dec 26 13:54 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:54 /var/tmp
$ mount |grep /tmp
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=65536k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=131072k)
$ grep /tmp /etc/fstab
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0
$ sudo systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Sun 2018-01-28 15:58:18 UTC; 10 months 27 days ago
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 642 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2146)
CGroup: /system.slice/tmp.mount
Jan 28 15:58:18 testsystem systemd[1]: Mounting /tmp...
Jan 28 15:58:18 testsystem systemd[1]: Mounted /tmp.
$ grep -R '/tmp' /etc/tmpfiles.d /usr/lib/tmpfiles.d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.Test-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:r! /tmp/.X[0-9]*-lock
/usr/lib/tmpfiles.d/tmp.conf:D /tmp 1777 root root -
/usr/lib/tmpfiles.d/tmp.conf:#q /var/tmp 1777 root root 30d
/usr/lib/tmpfiles.d/tmp.conf:x /tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:x /var/tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /var/tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:R! /tmp/systemd-private-*
/usr/lib/tmpfiles.d/tmp.conf:R! /var/tmp/systemd-private-*
$ sudo chmod 1777 /tmp
$ ls -ld /tmp /var/tmp
drwxrwxrwt 9 root root 180 Dec 26 13:55 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:55 /var/tmp
$ cat /etc/rc.local
#!/bin/bash
service ntp start
exit 0
$ uname -a
Linux testsystem 4.15.0-1030-raspi2 #32-Ubuntu SMP PREEMPT Fri Dec 7 09:15:28 UTC 2018 armv7l armv7l armv7l GNU/Linux
Related, unanswered questions:
- /tmp tmpfs permissions problem
- How can I mount a tmpfs to /tmp via fstab, writable to anyone?
mount fstab chmod tmpfs
What is the output ofumask
?
– Timothy Pulliam
Dec 26 '18 at 15:18
umask is0007
and it's not set in .bashrc or .profile
– bitinerant
Dec 26 '18 at 15:22
One standard reason for this is that you untarred or unzipped a file in/tmp
as the root user and this reset the permissions. You can fix it withchmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Can you check if you have/tmp
listed in any of the systemd-tmpfiles configs, under/usr/lib/tmpfiles.d
or/etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!
– filbranden
Dec 26 '18 at 16:13
|
show 4 more comments
For /tmp
in /etc/fstab
, I have mode=1777
, but after a reboot, the permissions on /tmp
are 0755
. Another directory /var/tmp
is configured in exactly the same way but does not have this problem (see below). This is a Raspberry Pi running Ubuntu 18.04 Server. The root filesystem is a microSD card mounted read-only.
What is the proper way to make the 1777
permissions permanent?
Here are some additional details (after a fresh boot):
$ touch /tmp/test
touch: cannot touch '/tmp/test': Permission denied
$ whoami
ubuntu
$ ls -ld /tmp /var/tmp
drwxr-xr-x 9 root root 180 Dec 26 13:54 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:54 /var/tmp
$ mount |grep /tmp
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=65536k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=131072k)
$ grep /tmp /etc/fstab
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0
$ sudo systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Sun 2018-01-28 15:58:18 UTC; 10 months 27 days ago
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 642 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2146)
CGroup: /system.slice/tmp.mount
Jan 28 15:58:18 testsystem systemd[1]: Mounting /tmp...
Jan 28 15:58:18 testsystem systemd[1]: Mounted /tmp.
$ grep -R '/tmp' /etc/tmpfiles.d /usr/lib/tmpfiles.d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.Test-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:r! /tmp/.X[0-9]*-lock
/usr/lib/tmpfiles.d/tmp.conf:D /tmp 1777 root root -
/usr/lib/tmpfiles.d/tmp.conf:#q /var/tmp 1777 root root 30d
/usr/lib/tmpfiles.d/tmp.conf:x /tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:x /var/tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /var/tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:R! /tmp/systemd-private-*
/usr/lib/tmpfiles.d/tmp.conf:R! /var/tmp/systemd-private-*
$ sudo chmod 1777 /tmp
$ ls -ld /tmp /var/tmp
drwxrwxrwt 9 root root 180 Dec 26 13:55 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:55 /var/tmp
$ cat /etc/rc.local
#!/bin/bash
service ntp start
exit 0
$ uname -a
Linux testsystem 4.15.0-1030-raspi2 #32-Ubuntu SMP PREEMPT Fri Dec 7 09:15:28 UTC 2018 armv7l armv7l armv7l GNU/Linux
Related, unanswered questions:
- /tmp tmpfs permissions problem
- How can I mount a tmpfs to /tmp via fstab, writable to anyone?
mount fstab chmod tmpfs
For /tmp
in /etc/fstab
, I have mode=1777
, but after a reboot, the permissions on /tmp
are 0755
. Another directory /var/tmp
is configured in exactly the same way but does not have this problem (see below). This is a Raspberry Pi running Ubuntu 18.04 Server. The root filesystem is a microSD card mounted read-only.
What is the proper way to make the 1777
permissions permanent?
Here are some additional details (after a fresh boot):
$ touch /tmp/test
touch: cannot touch '/tmp/test': Permission denied
$ whoami
ubuntu
$ ls -ld /tmp /var/tmp
drwxr-xr-x 9 root root 180 Dec 26 13:54 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:54 /var/tmp
$ mount |grep /tmp
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=65536k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,size=131072k)
$ grep /tmp /etc/fstab
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0
$ sudo systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Sun 2018-01-28 15:58:18 UTC; 10 months 27 days ago
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 642 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2146)
CGroup: /system.slice/tmp.mount
Jan 28 15:58:18 testsystem systemd[1]: Mounting /tmp...
Jan 28 15:58:18 testsystem systemd[1]: Mounted /tmp.
$ grep -R '/tmp' /etc/tmpfiles.d /usr/lib/tmpfiles.d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:D! /tmp/.Test-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:r! /tmp/.X[0-9]*-lock
/usr/lib/tmpfiles.d/tmp.conf:D /tmp 1777 root root -
/usr/lib/tmpfiles.d/tmp.conf:#q /var/tmp 1777 root root 30d
/usr/lib/tmpfiles.d/tmp.conf:x /tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:x /var/tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /var/tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/tmp.conf:R! /tmp/systemd-private-*
/usr/lib/tmpfiles.d/tmp.conf:R! /var/tmp/systemd-private-*
$ sudo chmod 1777 /tmp
$ ls -ld /tmp /var/tmp
drwxrwxrwt 9 root root 180 Dec 26 13:55 /tmp
drwxrwxrwt 4 root root 80 Dec 26 13:55 /var/tmp
$ cat /etc/rc.local
#!/bin/bash
service ntp start
exit 0
$ uname -a
Linux testsystem 4.15.0-1030-raspi2 #32-Ubuntu SMP PREEMPT Fri Dec 7 09:15:28 UTC 2018 armv7l armv7l armv7l GNU/Linux
Related, unanswered questions:
- /tmp tmpfs permissions problem
- How can I mount a tmpfs to /tmp via fstab, writable to anyone?
mount fstab chmod tmpfs
mount fstab chmod tmpfs
edited Dec 26 '18 at 16:19
bitinerant
asked Dec 26 '18 at 14:53
bitinerantbitinerant
817
817
What is the output ofumask
?
– Timothy Pulliam
Dec 26 '18 at 15:18
umask is0007
and it's not set in .bashrc or .profile
– bitinerant
Dec 26 '18 at 15:22
One standard reason for this is that you untarred or unzipped a file in/tmp
as the root user and this reset the permissions. You can fix it withchmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Can you check if you have/tmp
listed in any of the systemd-tmpfiles configs, under/usr/lib/tmpfiles.d
or/etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!
– filbranden
Dec 26 '18 at 16:13
|
show 4 more comments
What is the output ofumask
?
– Timothy Pulliam
Dec 26 '18 at 15:18
umask is0007
and it's not set in .bashrc or .profile
– bitinerant
Dec 26 '18 at 15:22
One standard reason for this is that you untarred or unzipped a file in/tmp
as the root user and this reset the permissions. You can fix it withchmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Can you check if you have/tmp
listed in any of the systemd-tmpfiles configs, under/usr/lib/tmpfiles.d
or/etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!
– filbranden
Dec 26 '18 at 16:13
What is the output of
umask
?– Timothy Pulliam
Dec 26 '18 at 15:18
What is the output of
umask
?– Timothy Pulliam
Dec 26 '18 at 15:18
umask is
0007
and it's not set in .bashrc or .profile– bitinerant
Dec 26 '18 at 15:22
umask is
0007
and it's not set in .bashrc or .profile– bitinerant
Dec 26 '18 at 15:22
One standard reason for this is that you untarred or unzipped a file in
/tmp
as the root user and this reset the permissions. You can fix it with chmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
One standard reason for this is that you untarred or unzipped a file in
/tmp
as the root user and this reset the permissions. You can fix it with chmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Can you check if you have
/tmp
listed in any of the systemd-tmpfiles configs, under /usr/lib/tmpfiles.d
or /etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!– filbranden
Dec 26 '18 at 16:13
Can you check if you have
/tmp
listed in any of the systemd-tmpfiles configs, under /usr/lib/tmpfiles.d
or /etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!– filbranden
Dec 26 '18 at 16:13
|
show 4 more comments
1 Answer
1
active
oldest
votes
This was part of my initial configuration (because /
is mounted read-only):
sudo rm -rf /var/spool && sudo ln -s /tmp /var/spool
Apparently at boot, the system does chmod 755 /var/spool
, which changed /tmp
in my case.
The fix was to replace the symlink with a normal directory and add a third tmpfs
mount:
sudo rm -rf /var/spool && sudo mkdir /var/spool && sudo chmod 755 /var/spool
echo 'tmpfs /var/spool tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=64M 0 0' |sudo tee -a /etc/fstab
Thanks to everyone for the comments which directed me in the correct direction, especially Filipe Brandenburger's "Do you have any other scripts or units messing with /tmp on startup?"
2
I'd advise against making/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable/var/spool/cron/crontabs
.
– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, themode=1777
that I had before my edit did not have any effect because of thechmod 755 /var/spool
that happens during boot.
– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
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%2f490995%2fwhy-is-tmp-mounted-with-permissions-0755-when-fstab-has-1777%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
This was part of my initial configuration (because /
is mounted read-only):
sudo rm -rf /var/spool && sudo ln -s /tmp /var/spool
Apparently at boot, the system does chmod 755 /var/spool
, which changed /tmp
in my case.
The fix was to replace the symlink with a normal directory and add a third tmpfs
mount:
sudo rm -rf /var/spool && sudo mkdir /var/spool && sudo chmod 755 /var/spool
echo 'tmpfs /var/spool tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=64M 0 0' |sudo tee -a /etc/fstab
Thanks to everyone for the comments which directed me in the correct direction, especially Filipe Brandenburger's "Do you have any other scripts or units messing with /tmp on startup?"
2
I'd advise against making/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable/var/spool/cron/crontabs
.
– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, themode=1777
that I had before my edit did not have any effect because of thechmod 755 /var/spool
that happens during boot.
– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
add a comment |
This was part of my initial configuration (because /
is mounted read-only):
sudo rm -rf /var/spool && sudo ln -s /tmp /var/spool
Apparently at boot, the system does chmod 755 /var/spool
, which changed /tmp
in my case.
The fix was to replace the symlink with a normal directory and add a third tmpfs
mount:
sudo rm -rf /var/spool && sudo mkdir /var/spool && sudo chmod 755 /var/spool
echo 'tmpfs /var/spool tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=64M 0 0' |sudo tee -a /etc/fstab
Thanks to everyone for the comments which directed me in the correct direction, especially Filipe Brandenburger's "Do you have any other scripts or units messing with /tmp on startup?"
2
I'd advise against making/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable/var/spool/cron/crontabs
.
– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, themode=1777
that I had before my edit did not have any effect because of thechmod 755 /var/spool
that happens during boot.
– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
add a comment |
This was part of my initial configuration (because /
is mounted read-only):
sudo rm -rf /var/spool && sudo ln -s /tmp /var/spool
Apparently at boot, the system does chmod 755 /var/spool
, which changed /tmp
in my case.
The fix was to replace the symlink with a normal directory and add a third tmpfs
mount:
sudo rm -rf /var/spool && sudo mkdir /var/spool && sudo chmod 755 /var/spool
echo 'tmpfs /var/spool tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=64M 0 0' |sudo tee -a /etc/fstab
Thanks to everyone for the comments which directed me in the correct direction, especially Filipe Brandenburger's "Do you have any other scripts or units messing with /tmp on startup?"
This was part of my initial configuration (because /
is mounted read-only):
sudo rm -rf /var/spool && sudo ln -s /tmp /var/spool
Apparently at boot, the system does chmod 755 /var/spool
, which changed /tmp
in my case.
The fix was to replace the symlink with a normal directory and add a third tmpfs
mount:
sudo rm -rf /var/spool && sudo mkdir /var/spool && sudo chmod 755 /var/spool
echo 'tmpfs /var/spool tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=64M 0 0' |sudo tee -a /etc/fstab
Thanks to everyone for the comments which directed me in the correct direction, especially Filipe Brandenburger's "Do you have any other scripts or units messing with /tmp on startup?"
edited Dec 26 '18 at 18:44
answered Dec 26 '18 at 17:01
bitinerantbitinerant
817
817
2
I'd advise against making/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable/var/spool/cron/crontabs
.
– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, themode=1777
that I had before my edit did not have any effect because of thechmod 755 /var/spool
that happens during boot.
– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
add a comment |
2
I'd advise against making/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable/var/spool/cron/crontabs
.
– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, themode=1777
that I had before my edit did not have any effect because of thechmod 755 /var/spool
that happens during boot.
– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
2
2
I'd advise against making
/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable /var/spool/cron/crontabs
.– Mark Plotnick
Dec 26 '18 at 18:20
I'd advise against making
/var/spool
publically writable if you have non-admin users on your system. There are lots of packages that use that directory tree - rsyslog, cron, anacron, dma, libreoffice-core, cups-daemon, at least. I don't know how much they check ownership of various directories. I'm particularly worried about a writable /var/spool/cron/crontabs
.– Mark Plotnick
Dec 26 '18 at 18:20
Mark, you are right. Thanks for noticing my oversight. In practice though, the
mode=1777
that I had before my edit did not have any effect because of the chmod 755 /var/spool
that happens during boot.– bitinerant
Dec 26 '18 at 18:48
Mark, you are right. Thanks for noticing my oversight. In practice though, the
mode=1777
that I had before my edit did not have any effect because of the chmod 755 /var/spool
that happens during boot.– bitinerant
Dec 26 '18 at 18:48
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
Glad to see you figured this out!
– filbranden
Dec 27 '18 at 3:06
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f490995%2fwhy-is-tmp-mounted-with-permissions-0755-when-fstab-has-1777%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
What is the output of
umask
?– Timothy Pulliam
Dec 26 '18 at 15:18
umask is
0007
and it's not set in .bashrc or .profile– bitinerant
Dec 26 '18 at 15:22
One standard reason for this is that you untarred or unzipped a file in
/tmp
as the root user and this reset the permissions. You can fix it withchmod 1777 /tmp
– Stephen Harris
Dec 26 '18 at 15:39
Yes, I know I can manually fix the permissions. My question is how to make it survive a reboot (without a bad hack).
– bitinerant
Dec 26 '18 at 15:41
Can you check if you have
/tmp
listed in any of the systemd-tmpfiles configs, under/usr/lib/tmpfiles.d
or/etc/tmpfiles.d
? The mount settings are correct, the permissions are probably being broken by something after the filesystem is mounted... Now you need to find what is breaking them, in order to fix them. Good luck!– filbranden
Dec 26 '18 at 16:13