Mounting a RAMFS disk at boot in Mac OS X

I received a question about creating a RAMFS for Mac OS X’ /tmp folder, so I’ll post my reply here as well.

It’s really simple;

  1. Open Terminal (Applications -> Utilities), type “sudo su” and enter your user’s password.
  2. Create a new file in /Library/LaunchDaemons, like this: “nano -w /Library/LaunchDaemons/com.yeri.ramfs.plist” (you can rename yeri to whatever you like)
  3. And insert following content (ctrl+x to save – y – [enter]):
  4. <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    <plist version="1.0">
  5. create a second file in /var/root/, like this: “nano -w /var/root/
  6. And insert following content:
  7. #!/bin/bash
    ramdisk_dev=`hdid -nomount ram://${ramfs_size_sectors}`
    newfs_hfs -v 'Volatile HD' ${ramdisk_dev}
    mkdir -p ${mount_point}
    mount -o noatime -t hfs ${ramdisk_dev} ${mount_point}
    chown root:wheel ${mount_point}
    chmod 1777 ${mount_point}
  8. chmod +x and reboot. Check in Terminal with “mount” or “df -h” is everything is fine. To hide the disk icon on your desktop, check my old blog post.
  9. In case Mac didn’t do so already, you might want to link /tmp to /private/tmp: “rm -r /tmp && ln -s /private/tmp /tmp“.
  10. Should be it !

Posted by


, ,


17 responses to “Mounting a RAMFS disk at boot in Mac OS X”

  1. Chris avatar

    Unfortunately, this doesn’t work on my MBP (10.6.6). First, it doesn’t create an executable shell, when using “.sh” as suffix; so I saved another file without suffix and also fixed the corresponding link in the .plist. When I execute the ramfs manually it actually works. However, it doesn’t load on startup and since I did the symlink (? – step 7) I get some errors (i.e. Sophos keeps on telling me, it was unable to start up) 🙁

    Do you have any idea how to fix this? Did I do anything wrong?

  2. Yeri Tiete avatar
    Yeri Tiete

    I noticed certain applications to sometimes cause issues when it’s mounted in RAM (Like VirtualBox).

    To make the .sh file executable, just run chmod +x /var/root/

    If you create the .plist file in LaunchDaemons (/Library/LaunchDaemons/com.yeri.ramfs.plist) it should automatically start at boot (be sure to test everything from Terminal before rebooting).

    try “./var/root/” and see what happens with “df -h”

    This is my output:

    yeri$ df -h
    Filesystem Size Used Avail Capacity Mounted on
    /dev/disk0s2 233Gi 202Gi 31Gi 87% /
    devfs 117Ki 117Ki 0Bi 100% /dev
    /dev/disk1 64Mi 2.0Mi 62Mi 4% /private/tmp
    map -hosts 0Bi 0Bi 0Bi 100% /net
    map auto_home 0Bi 0Bi 0Bi 100% /home

    Line 3 (/dev/disk1) is the RAMfs

    About your symlink, make sure it’s actually linked correctly with ls -ls /tmp:

    Like so:

    yeri$ ls -ls /tmp
    8 lrwxr-xr-x@ 1 root wheel 11 Apr 18 2010 /tmp -> private/tmp

    Hope this helps.

  3. Yeri Tiete avatar
    Yeri Tiete

    Yes that’s correct, you can’t execute it by double clicking.
    You need to execute it from within the Terminal.

    Check this page — RAM disk part). Maybe you’ll find more information there.

    Just be sure you put the .plist file in “/Library/LaunchDaemons/” (not “Library/LaunchDaemons/” — note the first slash), and reboot. Should really do it.

    nazgul:LaunchDaemons yeri$ pwd 
    nazgul:LaunchDaemons yeri$ ls -lsa
    total 56
    0 drwxr-xr-x   9 root  wheel   306 Mar 18 08:42 .
    0 drwxrwxr-t+ 62 root  admin  2108 Dec 17 23:41 ..
    8 -r--r--r--   1 root  wheel   573 Jun 30  2010 at.obdev.littlesnitchd.plist
    8 -rw-r--r--   1 root  wheel   617 Sep 24 00:12 com.adobe.SwitchBoard.plist
    8 -rw-r--r--   1 root  wheel   555 Oct 21 20:27
    8 -rw-r--r--   1 root  wheel   790 Mar 18 08:42
    8 -rw-r--r--   1 root  wheel   568 Aug 25  2010
    8 -rw-r--r--   1 root  wheel   530 Jun  8  2010 com.yeri.noatime.plist
    8 -rw-r--r--   1 root  wheel   424 Sep 26 12:23 com.yeri.ramfs.plist
  4. Chris avatar

    Thanks for your quick response :).

    I tried several times to make the Shell executable (using different combination chmod +x/u+x/a+x), but I didn’t succeed (at least it seems so, as neither the icon changes nor the code is actually executed; it just opens in TextEdit instead). Of course I was logged in as su when performing the terminal commands. The Shell itself appears to work (“Initialized /dev/rdisk2 as a 512 MB HFS Plus volume”), however, it still doesn’t launch at startup :(.

  5. Yeri Tiete avatar
    Yeri Tiete

    Wait — when and how does it open with TextEdit ?

    The .plist file cannot be executable (just delete it and start over).

    yeri$ cat com.yeri.ramfs.plist 
    < ?xml version="1.0" encoding="UTF-8"?>
    < !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    <plist version="1.0">
            <true />
  6. Chris avatar

    No, I did not attempt to make the .plist executable. 😉
    The Shell opens with TextEdit (as plain text). As said, when dragged into a Terminal window it actually works and a Ramdisk is created. I already started over for a couple of times.
    The only thing I changed is the Size (from 64 to 512 MB).

    Thanks for your patience though.

  7. Yeri Tiete avatar
    Yeri Tiete

    You need to run or execute the .sh file from Terminal (Applications > Utilities > Terminal)

    “sudo ./var/root/”. I don’t see how this could open TextEdit. Q_o

  8. Chris avatar

    I think this whole TextEdit issue is a misunderstanding, that I’d like to beg your pardon for. I (wrongly) supposed that an executable shell would also start running when I double click the specific file. I guess that’s not true, since the script works, when it is executed from Terminal. However, I’m not sure for what reason the RamFS is not launched at startup, for I strictly followed the instructions; Snow leopard is freshly installed :/.

    I guess it’s hard to make a remote diagnosis so I’d like to thank you so far for providing me with your help! 😀

    Best wishes from Germany

  9. Chris avatar

    So, I decided to give it one last try and repaired file permissions using the disk utility and performed “sudo chown root:wheel” on the .plist for another time…FINALLY it seems to work now! 😀 This is great.
    Maybe I do another one for Chromiums cache… if I get to know, how to write it back on HDD when the volume is beeing unmounted ^^

    Once more: Thank you! (and excuse me for having totally spammed your blog :blush:)

  10. Yeri Tiete avatar
    Yeri Tiete

    You could just make the tmpfs disk bigger and symlink Chrome’s Cache to /tmp I guess.

    I’ve lowered my /tmp partiton to 64Mb as it rarely has more than 5 to 10Mb of data in it.

    Be sure to post if you notice notable differences in performance.

    You’re welcome and don’t worry about it. 🙂

  11. Chris avatar

    That’s what I did and to my astonishment, it’s not as fast as I’d expected it to be :/. I’m going to test this more extensively tomorrow and report, whether I think it’s worth it…or not 😉

    The issue is, that at one of the locations I usually go online, the internet connection is quite slow (only 1 MBit/s); so, due to the fact that the contents of the RamFS (and so the cache) are erased each time OS X is shut down, it might be more advisable to have a long term cache stored on the HDD in the end.

  12. Yeri Tiete avatar
    Yeri Tiete

    I’m not really sure how much Chrome actually caches. I think Firefox tends to keep more than Chrome.

    As for the /tmp part, yes, there aren’t that many files in /tmp, so you’ll likely never notice a visible difference.

  13. Chris avatar

    Well, i decided not to symlink the Chrome Cache to the RamFS. In my opinion it has no noticeable advantage.
    Besides, to make the Ramfs invisible in Finder, it would be sufficient, to mount it with the option nobrowse :).

  14. Yeri Tiete avatar
    Yeri Tiete

    nobrowse? Ah, didn’t know that. Cool

  15. Maaatt avatar

    I was getting “command not found” errors for mount and for newfs_hfs, but it worked fine once I substituted in /sbin/mount and /sbin/newfs_hfs. I guess in newer versions of MacOS, they must have removed /sbin from root’s path for whatever reason. And now I have a sweet new ramdisk! Thanks for this!

  16. sp avatar

    This stopped working for me after upgrading to Yosemite 10.10. I thought perhaps it was because /Volumes wasn’t mounted prior to calling the script … but that doesn’t appear to be the case. When manually ‘load’ing the plist … it says ‘Operation still in progress’. When manually executing the bash script, the volume mounts fine. Has anyone encountered this yet? Has Apple changed how custom plists work during init?

  17. vlad avatar

    inserting ‘sleep 10’ at begin of script makes it work on yosemite. some yosemite service (currently unknown for me) unmounts ramdisk at startup, only if ramdisk mounted before starting this service. i’ve contacted support but they can’t help.

Leave a Reply…

%d bloggers like this: