{"id":13327,"date":"2026-01-20T01:01:00","date_gmt":"2026-01-20T06:01:00","guid":{"rendered":"https:\/\/www.both.org\/?p=13327"},"modified":"2026-01-14T17:35:04","modified_gmt":"2026-01-14T22:35:04","slug":"create-a-linux-kiosk-at-your-library","status":"publish","type":"post","link":"http:\/\/www.both.org\/?p=13327","title":{"rendered":"Create a Linux kiosk at your library"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n 2 <\/span>\r\n<\/div><\/div>\n

As a frequent client of my local library, I’m very invested in the health, sustainability, and privacy of library systems all over the world. When my friend and fellow Both.org author, Don Watkins, mentioned a project he was working on to deliver his library with computers so people could do research on them, he also mentioned that he needed the computers to erase all user data after the user has logged out of their session. I’m interested in “kiosk mode” for Linux computers, and I’ve used distributions like Porteus<\/a> as a Kiosk at computer conferences, but recently I’ve just been using GNOME Display Manager (GDM) on any distribution that makes GDM available. Here’s how to use Linux and GDM to create a Guest mode for your Linux computer.<\/p>\n\n\n\n

Start without a guest account<\/h2>\n\n\n\n

The first few steps of this process don’t actually require a guest user directory to exist, so do NOT create your guest user account yet<\/em>. However, you do need to choose what your guest user account is going to be called. A reasonable account name for Don’s purposes is libraryguest<\/code>. On my personal computer I call my guest account guestaccount<\/code>, and I’ve used kioskguest<\/code> on some installations. I avoid just the name “guest” because in modern computing the term “guest” gets used in a few other ways (such as a “guest operating system” in a virtual environment), and it’s just easier to find something unique in logs.<\/p>\n\n\n\n

Choose a unique name for you guest account, but don’t create it yet. For this article, I’m using libraryguest<\/code>.<\/p>\n\n\n\n

Create the PostSession script<\/h2>\n\n\n\n

By default, GDM recognises several states: Init, PostLogin, PreSession, and PostSession. Each state has a directory located in \/etc\/gdm<\/code>. When you place a shell script called Default<\/code> in one of those directories, GDM runs the script when it reaches that state.<\/p>\n\n\n\n

To trigger actions to clean up a user’s environment upon logout, create the file \/etc\/gdm\/PostSession\/Default<\/code>. You can add whatever actions you want to run upon logout to the Default<\/code> script. In the case of Don’s library, we wanted to clear everything from the guest’s home directory, including browser history, any LibreOffice files or GIMP files they may have created, and so on. It was important that we limited the very drastic action of removing all user data to just<\/em> the guest user. We didn’t want the admin’s data to be erased upon logout, so whatever rule we added to \/etc\/gdm\/PostSession\/Default<\/code> had to be limited to the guest user.<\/p>\n\n\n\n

Here’s what we came up with:<\/p>\n\n\n\n

#!\/usr\/bin\/sh\n\necho \"$USER logged out at `date`\" >> \/tmp\/PostSession.log\n\nif [ \"X$USER\" = \"Xlibraryguest\" ]; then\n    rm -rf \"$HOME\"\nfi\nexit 0<\/code><\/pre>\n\n\n\n
The first line is for logging purposes. The \/tmp<\/code> directory gets cleared out on most distributions automatically, so we weren’t worried about creating a file that’ll grow forever and eventually crash the computer. If your distribution of choice doesn’t clean out \/tmp<\/code> automatically, create a cron job<\/a> to do that for you.<\/p>\n\n\n\n
GDM knows what user triggered the logout process, so the if<\/code> statement verifies that the user logging out is definitely the libraryguest<\/code> user (that’s the literal name of the user we created for library patrons).
Note that the whitespace around the square brackets is important, so be precise when typing!<\/p>\n\n\n\n
As long as it is libraryguest<\/code>, then the script removes the entire user directory<\/em> ($HOME<\/code>). That can be extremely dangerous if you make a mistake, so do thorough testing on a dummy system before implementing a script like this! If you get a condition wrong, you could erase your entire home directory<\/em> upon logout.<\/p>\n\n\n\n
In this example, I’ve successfully limited the rm<\/code> command to a logout action performed by user libraryguest<\/code>. The entire \/home\/libraryguest<\/code> directory is erased, and the computer returns to the GDM login screen. When a new user logs in, a fresh directory is created for the user.<\/p>\n\n\n\n
You can put any number of commands in your script, of course. You don’t have to erase an entire directory. If all you really want to do is clear browser history and any stray data, then you can do that instead. If you need to copy specific configuration files into the environment, you can do that during the PreSession state.<\/p>\n\n\n\n
Just be sure to test thoroughly before committing your creation to your users!<\/p>\n\n\n\n
What happens when the guest doesn’t log out<\/h2>\n\n\n\n
At this point, the computer erases all of the user’s data when the user logs out, but a reboot or a shutdown is different to a logout. GDM doesn’t enter a PostSession state after a reboot signal has been received, even if the reboot occurs during an active GDM session.<\/p>\n\n\n\n
The easiest and safest way to erase an entire home directory when there’s a cut to system power is to use a temporary RAM filesystem (tmpfs<\/code>) to house the data in the first place. If the systems you’re configuring have 8 GB or more, and the system is exclusively used as a guest computer, you can probably afford to use RAM as the guest’s home directory. If your system doesn’t have a lot of RAM, then you can use the systemd work-around in the next section.<\/p>\n\n\n\n
Assuming you have the RAM to spare, and that your systems are supported by a backup power supply, you can add a tmpfs<\/code> entry in \/etc\/fstab<\/code>. In this example, my tmpfs<\/code> is mounted to \/home\/libraryguest<\/code> and is just 2 GB:<\/p>\n\n\n\n
tmpfs     \/home\/libraryguest    tmpfs    rw,nosuid,nodev,size=2G   0 0<\/code><\/pre>\n\n\n\n
That’s plenty of space for some Internet browsing and even a few LibreOffice documents to be saved while a user works.<\/p>\n\n\n\n
Mount the new volume:<\/p>\n\n\n\n
$ sudo mount \/home\/libraryguest<\/code><\/pre>\n\n\n\n
Next, you must create the libraryguest<\/code> user manually in a terminal.
The useradd<\/code> command creates user profiles:<\/p>\n\n\n\n
$ sudo useradd --home-dir \/home\/libraryguest libraryguest\nuseradd: warning: the home directory \/home\/libraryguest\/ already exists.\nuseradd: Not copying any file from skel directory into it.<\/code><\/pre>\n\n\n\n
Because you’ve already created a location for the home directory, you do get a warning after creating the user. It’s only a warning, not a fatal error, and the guest account is automatically populated later.<\/p>\n\n\n\n
Create a password for the new user:<\/p>\n\n\n\n
$ sudo passwd libraryguest<\/code><\/pre>\n\n\n\n
That’s it! You’ve created a guest account that refreshes with every logout and every reboot. You can skip over the next section of this article.<\/p>\n\n\n\n
Using systemd targets instead of a ramdisk<\/h2>\n\n\n\n
Assuming you can’t create a ramdisk for temporary user data, you can instead create a systemd service that runs a script when the reboot, poweroff, and multi-user targets are triggered:<\/p>\n\n\n\n
[Unit]\nDescription=Kiosk cleanup\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/bin\/kiosk-cleanup.sh\n\n[Install]\nWantedBy=poweroff.target reboot.target multi-user.target<\/code><\/pre>\n\n\n\n
Save the file to \/etc\/systemd\/system\/kioskmode.service<\/code> and then enable it:<\/p>\n\n\n\n
$ sudo systemctl enable --now kioskmode<\/code><\/pre>\n\n\n\n
The script, like the GDM script, removes the libraryguest<\/code> directory. Unlike GDM script, this one must also recreate an empty home directory and grant it user permissions:<\/p>\n\n\n\n
#!\/usr\/bin\/bash\n\nrm -rf \/home\/libraryguest\nmkdir \/home\/libraryguest\nchown -R libraryguest:libraryguest \/home\/libraryguest<\/code><\/pre>\n\n\n\n
Grant the script itself permission to run:<\/p>\n\n\n\n
$ sudo chmod +x \/usr\/local\/bin\/kiosk-cleanup.sh<\/code><\/pre>\n\n\n\n
Now the libraryguest<\/code> user data is erased after:<\/p>\n\n\n\n
    \n
  • Logout<\/li>\n\n\n\n
  • Reboot<\/li>\n\n\n\n
  • Shutdown<\/li>\n\n\n\n
  • Startup<\/li>\n<\/ul>\n\n\n\n
    Essentially, no matter how the computer loses its session or its power, the libraryguest<\/code> account starts fresh when a new session is started.<\/p>\n\n\n\n
    Security and privacy<\/h3>\n\n\n\n
    Using systemd to erase data at shutdown and startup isn’t strictly as secure as using a temporary ramdisk for all user data. Should the computer lose power suddenly, all saved user data in the libraryguest<\/code> account is present during the next boot. Of course, it’s erased as soon as multi-user.target<\/code> is called by systemd, but it is technically possible to interrupt the boot process and mine for data. You must use full drive encryption to protect data from being discovered by an interrupted boot sequence.<\/p>\n\n\n\n
    Why not just use xguest<\/h2>\n\n\n\n
    On many Linux distributions, the xguest<\/code> package is designed to provide the Guest<\/strong> account, which resets after each logout. It was an extremely useful package that I installed on every machine I owned, because it’s handy to be able to let friends use my computer without risking them making a mess of my home directory. Lately, it seems that xguest<\/code> is failing to launch a desktop, however, presumably because it relies on X11.<\/p>\n\n\n\n
    If xguest<\/code> works for you in your tests, then you may want to use it instead of the solution I’ve presented here. My solution offers a lot of flexibility, thanks to GDM’s autodetection of session states.<\/p>\n\n\n\n
    Kiosks in libraries<\/h2>\n\n\n\n
    Privacy and personal information is more important than ever. Regardless of how you setup a kiosk for your library, you have an obligation to your users to keep them informed of how their data is being stored. This goes both ways. Users need to know that their data is destined to be erased as soon as they log out, and also they deserve to be assured that their data is not retained.<\/p>\n\n\n\n
    However, it’s also your responsibility to admit that glitches and exceptions could occur. Users need to understand that the computer they’re using are public computers on a public network. Encryption is being used for traffic and for data storage, but you cannot guarantee absolute privacy.<\/p>\n\n\n\n
    As long as everyone understands the arrangement, everyone can compute with confidence. Linux, GDM, and systemd are great tools to help libraries create a sustainable, robust, honest, and communal computing platform.<\/p>\n","protected":false},"excerpt":{"rendered":"
    2 As a frequent client of my local library, I’m very invested in the health, sustainability, and privacy<\/p>\n","protected":false},"author":31,"featured_media":13343,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[482],"tags":[],"class_list":["post-13327","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-advanced"],"modified_by":"Seth Kenlon","_links":{"self":[{"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"http:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=13327"}],"version-history":[{"count":4,"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13327\/revisions"}],"predecessor-version":[{"id":13342,"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13327\/revisions\/13342"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/13343"}],"wp:attachment":[{"href":"http:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=13327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=13327"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=13327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}