Why is /tmp mounted with permissions 0755 when fstab has 1777?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












3














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?









share|improve this question























  • 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 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










  • 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















3














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?









share|improve this question























  • 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 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










  • 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













3












3








3







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?









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 26 '18 at 16:19







bitinerant

















asked Dec 26 '18 at 14:53









bitinerantbitinerant

817




817











  • 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 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










  • 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










  • 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










  • 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










1 Answer
1






active

oldest

votes


















2














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?"






share|improve this answer


















  • 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, 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










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
);



);













draft saved

draft discarded


















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









2














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?"






share|improve this answer


















  • 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, 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















2














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?"






share|improve this answer


















  • 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, 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













2












2








2






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?"






share|improve this answer














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?"







share|improve this answer














share|improve this answer



share|improve this answer








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, 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












  • 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, 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







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

















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay