https://wiki.archlinux.org/api.php?action=feedcontributions&user=NorthAntrim&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:35:42ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Display_manager&diff=331377Display manager2014-08-20T12:51:36Z<p>NorthAntrim: linked Entrance to the Enlightenment page</p>
<hr />
<div>[[Category:Display managers]]<br />
[[ar:Display Manager]]<br />
[[cs:Display Manager]]<br />
[[de:Login-Manager]]<br />
[[es:Display Manager]]<br />
[[fr:Gestionnaire de connexions]]<br />
[[he:Display Manager]]<br />
[[it:Display Manager]]<br />
[[ja:Display Manager]]<br />
[[pt:Display Manager]]<br />
[[ru:Display Manager]]<br />
[[tr:Görüntü_yöneticisi]]<br />
[[uk:Display Manager]]<br />
[[zh-CN:Display Manager]]<br />
[[zh-TW:Display Manager]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Window manager}}<br />
{{Related|Start X at Login}}<br />
{{Related articles end}}<br />
<br />
A [[Wikipedia:X display manager (program type)|display manager]], or login manager, is typically a graphical user interface that is displayed at the end of the boot process in place of the default shell. There are various implementations of display managers, just as there are various types of [[window managers]] and [[Desktop environment|desktop environments]]. There is usually a certain amount of customization and themeability available with each one.<br />
<br />
== List of display managers ==<br />
<br />
=== Console ===<br />
<br />
* {{App|[[CDM]]|Ultra-minimalistic, yet full-featured login manager written in Bash.|https://github.com/ghost1227/cdm|{{AUR|cdm-git}}}}<br />
* {{App|[[Console TDM]]|Extension for ''xinit'' written in pure Bash.|http://code.google.com/p/t-display-manager/|{{AUR|console-tdm}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|[[Enlightenment|Entrance]]|An EFL based display manager, highly experimental.|http://enlightenment.org/|{{AUR|entrance-git}}}}<br />
* {{App|[[GDM]]|[[GNOME]] display manager.|http://projects.gnome.org/gdm/|{{Pkg|gdm}}}}<br />
* {{App|[[KDM]]|[[KDE]] display manager.|http://www.kde.org/|{{Pkg|kdebase-workspace}}}}<br />
* {{App|[[LightDM]]|Cross-desktop display manager, can use various front-ends written in any toolkit.|http://www.freedesktop.org/wiki/Software/LightDM|{{Pkg|lightdm}}}}<br />
* {{App|[[LXDM]]|[[LXDE]] display manager. Can be used independent of the LXDE desktop environment.|http://sourceforge.net/projects/lxdm/|{{Pkg|lxdm}}}}<br />
* {{App|MDM|MDM display manager, used in Linux Mint, a fork of GDM 2.|https://github.com/linuxmint/mdm|{{AUR|mdm-display-manager}}}}<br />
* {{App|[[Qingy]]|Ultralight and very configurable graphical login independent on X Windows (uses DirectFB).|http://qingy.sourceforge.net/|{{AUR|qingy}}}}<br />
* {{App|SDDM|QML-based display manager.|https://github.com/sddm/sddm|{{AUR|sddm}}, {{AUR|sddm-qt5}}}}<br />
* {{App|[[SLiM]]|Lightweight and elegant graphical login solution.|http://slim.berlios.de/{{Dead link|2014|06|19}}|{{Pkg|slim}}}}<br />
* {{App|[[XDM]]|X display manager with support for XDMCP, host chooser.|http://www.x.org/archive/X11R7.5/doc/man/man1/xdm.1.html|{{Pkg|xorg-xdm}}}}<br />
<br />
== Loading the display manager ==<br />
<br />
To enable graphical login, run your preferred display manager daemon (e.g. KDM).<br />
<br />
# systemctl enable kdm<br />
<br />
This should work out of the box. If not, you might have a ''default.target'' set manually or from an older install:<br />
<br />
{{hc|$ ls -l /etc/systemd/system/default.target|<br />
[...] /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and ''systemd'' will use its stock ''default.target'' (i.e. ''graphical.target'').<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
After enabling KDM a symlink ''display-manager.service'' should be set in {{ic|/etc/systemd/system/}}<br />
<br />
{{hc|$ ls -l /etc/systemd/system/display-manager.service|<br />
[...] /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/kdm.service}}<br />
<br />
=== Using systemd-logind ===<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. All [[polkit]] actions like suspending the system or mounting external drives will work out of the box.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Tips and tricks ==<br />
<br />
=== Session list ===<br />
<br />
Many display managers read available sessions from {{ic|/usr/share/xsessions/}} directory. It contains standard [http://standards.freedesktop.org/desktop-entry-spec/latest/ desktop entry files] for each DM/WM.<br />
<br />
To add/remove entries to your display manager's session list; create/remove the ''.desktop'' files in {{ic|/usr/share/xsessions/}} as desired. A typical ''.desktop'' file will look something like:<br />
<br />
[Desktop Entry]<br />
Encoding=UTF-8<br />
Name=Openbox<br />
Comment=Log in using the Openbox window manager (without a session manager)<br />
Exec=/usr/bin/openbox-session<br />
TryExec=/usr/bin/openbox-session<br />
Icon=openbox.png<br />
Type=XSession<br />
<br />
=== Autostarting ===<br />
<br />
Most of display managers sources {{ic|/etc/xprofile}}, {{ic|~/.xprofile}} and {{ic|/etc/X11/xinit/xinitrc.d/}}. For more details, see [[xprofile]].<br />
<br />
== Known issues ==<br />
<br />
=== Incompatibility with systemd ===<br />
<br />
''Affected DMs: Entrance, MDM<br />
<br />
Some display managers are not fully compatible with systemd, because they reuse the PAM session process. It causes various problems on second login, e.g.:<br />
* NetworkManager applet does not work,<br />
* PulseAudio volume cannot be adjusted,<br />
* login failed into GNOME with another user.<br />
<br />
See the following bugtracker reports for more details:<br />
* MDM: [https://github.com/linuxmint/mdm/issues/32]</div>NorthAntrimhttps://wiki.archlinux.org/index.php?title=NFS&diff=319019NFS2014-06-10T16:24:33Z<p>NorthAntrim: /* Starting the server */ clarification</p>
<hr />
<div>[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ar:NFS]]<br />
[[de:Network File System]]<br />
[[es:NFS]]<br />
[[fr:NFS]]<br />
[[it:NFSv4]]<br />
[[zh-CN:NFS]]<br />
{{Related articles start}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related articles end}}<br />
From [[Wikipedia: Network File System|Wikipedia]]: <br />
: ''Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed.''<br />
<br />
== Installation ==<br />
<br />
Both client and server only require the [[pacman|installation]] of the {{Pkg|nfs-utils}} package.<br />
<br />
{{Note|It is HIGHLY recommended to use a time sync daemon on ALL nodes to keep client/server clocks in sync. Without accurate clocks on all nodes, NFS can introduce unwanted delays! The [[NTP]] system is recommended to sync both the server and the clients to the highly accurate NTP servers available on the Internet.}}<br />
<br />
==Configuration==<br />
<br />
===Server===<br />
<br />
==== ID mapping ====<br />
<br />
Edit {{ic|/etc/idmapd.conf}} and set the {{ic|Domain}}.<br />
<br />
{{hc|/etc/idmapd.conf|<nowiki><br />
[General]<br />
<br />
Verbosity = 1<br />
Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br />
Domain = atomic<br />
<br />
[Mapping]<br />
<br />
Nobody-User = nobody<br />
Nobody-Group = nobody<br />
</nowiki>}}<br />
<br />
==== File system ====<br />
<br />
{{Note|For security reasons, it is recommended to use an NFS export root which will keep users limited to that mount point only. The following example illustrates this concept.}}<br />
<br />
Define any NFS shares in {{ic|/etc/exports}} which are relative to the NFS root. In this example, the NFS root will be {{ic|/srv/nfs4}} and we will be sharing {{ic|/mnt/music}}.<br />
<br />
# mkdir -p /srv/nfs4/music<br />
<br />
Read/Write permissions must be set on the music directory so clients may write to it. <br />
<br />
Now mount the actual target share, {{ic|/mnt/music}} to the NFS share via the mount command:<br />
<br />
# mount --bind /mnt/music /srv/nfs4/music<br />
<br />
To make it stick across server reboots, add the bind mount to {{ic|fstab}}:<br />
{{hc|/etc/fstab|<br />
/mnt/music /srv/nfs4/music none bind 0 0<br />
}}<br />
<br />
==== Exports ====<br />
<br />
Add directories to be shared and an ip address or hostname(s) of client machines that will be allowed to mount them in {{ic|exports}}:<br />
{{hc|/etc/exports|<nowiki><br />
/srv/nfs4/ 192.168.1.0/24(rw,fsid=root,no_subtree_check)<br />
/srv/nfs4/music 192.168.1.0/24(rw,no_subtree_check,nohide) # note the nohide option which is applied to mounted directories on the file system.<br />
</nowiki>}}<br />
<br />
Users need-not open the share to the entire subnet; one can specify a single IP address or hostname as well.<br />
<br />
For more information about all available options see {{ic|man 5 exports}}.<br />
<br />
{{Note|Modifying {{ic|/etc/exports}} while the server is running will require a re-export for changes to take effect.}}<br />
# exportfs -rav<br />
<br />
==== NFSv2 compatibility ====<br />
<br />
If you need to support clients using NFSv2 (for example U-Boot), set NFSD_OPTS="-V 2" in /etc/conf.d/nfs-server.conf.<br />
<br />
==== Starting the server ====<br />
<br />
Start {{ic|nfs-server.target}} [[systemd#Using units|using systemd]] (you may need to update {{Pkg|nfs-utils}} for {{ic|nfs-server.target}} to work). It is recommended to also enable the target to allow systemd to start it at boot time. Note that this unit requires other services, which are launched automatically by [[systemd]].<br />
<br />
==== Firewall configuration ====<br />
<br />
To enable access through a firewall, tcp and udp ports 111, 2049, and 20048 need to be opened. To configure this for [[iptables]], edit {{ic|/etc/iptables/iptables.rules}} to include the following lines:<br />
<br />
{{hc|/etc/iptables/iptables.rules|<nowiki><br />
-A INPUT -p tcp -m tcp --dport 111 -j ACCEPT<br />
-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT<br />
-A INPUT -p tcp -m tcp --dport 20048 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 111 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 2049 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 20048 -j ACCEPT<br />
</nowiki>}}<br />
<br />
To apply changes, restart {{ic|iptables}} service.<br />
<br />
=== Client ===<br />
<br />
Start {{ic|nfs-client.target}} [[systemd#Using units|using systemd]]. It is recommended to also enable the target to allow systemd to start it at boot time. Note that this unit requires other services, which are launched automatically by [[systemd]].<br />
<br />
Clients with a kernel version prior to 3.12.7-2 (the current {{pkg|linux-lts}} for example) MUST start {{ic|rpc-gssd.service}} to avoid an approx 15 seconds delay with an accompanying error in dmesg that reads, "RPC: AUTH_GSS upcall timed out" due to a kernel bug.<br />
<br />
{{Note|The server does not need to run this service.}}<br />
<br />
{{Warning|Starting this service without having it configured properly will result in error messages like:<br />
rpc.gssd[30473]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'<br />
rpc.gssd[30473]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host server.domain<br />
rpc.gssd[30473]: ERROR: No credentials found for connection to server server.domain<br />
and might lock up any NFS mount on the system when mounting and unmounting some mounts very often.<br />
}}<br />
<br />
An alternative is to blacklist {{ic|rpcsec_gss_krb5}} as described [https://bugzilla.redhat.com/show_bug.cgi?id=1001934 on Red Hat's Bugzilla].<br />
<br />
# echo "blacklist rpcsec_gss_krb5" > /etc/modprobe.d/rpcsec_gss_krb5-blacklist.conf<br />
# reboot<br />
<br />
==== Mounting from Linux ====<br />
<br />
Show the server's exported file systems:<br />
$ showmount -e servername<br />
<br />
Then mount omitting the server's NFS export root: <br />
# mount -t nfs servername:/music /mountpoint/on/client<br />
<br />
If mount fails try including the server's export root (required for Debian/RHEL/SLES):<br />
# mount -t nfs servername:/full/path/to/music /mountpoint/on/client<br />
<br />
{{Note|Server name needs to be a valid hostname (not just IP address). Otherwise mounting of remote share will hang.}}<br />
<br />
===== Using /etc/fstab =====<br />
<br />
Using [[fstab]] is useful for a server which is always on, and the NFS shares are available whenever the client boots up. Edit {{ic|/etc/fstab}} file, and add an appropriate line reflecting the setup. Again, the server's NFS export root is omitted.<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
servername:/music /mountpoint/on/client nfs4 rsize=8192,wsize=8192,timeo=14,_netdev 0 0<br />
</nowiki>}}<br />
<br />
{{Note|Consult the ''NFS'' and ''mount'' man pages for more mount options.}}<br />
<br />
Some additional mount options to consider are include:<br />
<br />
; rsize and wsize: The {{ic|rsize}} value is the number of bytes used when reading from the server. The {{ic|wsize}} value is the number of bytes used when writing to the server. The default for both is 1024, but using higher values such as 8192 can improve throughput. This is not universal. It is recommended to test after making this change, see [[#Performance tuning]].<br />
<br />
; timeo: The {{ic|timeo}} value is the amount of time, in tenths of a second, to wait before resending a transmission after an RPC timeout. After the first timeout, the timeout value is doubled for each retry for a maximum of 60 seconds or until a major timeout occurs. If connecting to a slow server or over a busy network, better performance can be achieved by increasing this timeout value. <br />
<br />
; _netdev: The {{ic|_netdev}} option tells the system to wait until the network is up before trying to mount the share. systemd assumes this for NFS, but anyway it is good practice to use it for all types of networked file systems<br />
<br />
; minorversion: Use {{ic| <nowiki>minorversion=1</nowiki>}} for mounting a Windows Server 2012 (Essentials) share with NFS version 4.1<br />
<br />
{{Note|Setting the sixth field (fs_passno) to a nonzero value may lead to unexpected behaviour, e.g. hangs when the systemd automount waits for a check which will never happen.}}<br />
<br />
===== Using /etc/fstab with systemd =====<br />
<br />
Another method is using the systemd {{ic|automount}} service. This is a better option than {{ic|_netdev}}, because it remounts the network device quickly when the connection is broken and restored. As well, it solves the problem from autofs, see the example below:<br />
<br />
{{hc|1=/etc/fstab|2=<br />
servername :/home /mountpoint/on/client nfs users,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,hard,intr,noatime 0 0 <br />
}}<br />
<br />
{{Tip|{{ic|noauto}} above will not mount the NFS share until it is accessed: use {{ic|auto}} for it to be available immediately. <br> If you have any issues with the mount failing due to the network not being up/available, [[systemd#Using units|enable]] {{ic|NetworkManager-wait-online.service}}: this will ensure that {{ic|network.target}} has all the links available prior to being active.}}<br />
<br />
===== Using autofs =====<br />
<br />
Using [[autofs]] is useful when multiple machines want to connect via NFS; they could both be clients as well as servers. The reason this method is preferable over the earlier one is that if the server is switched off, the client will not throw errors about being unable to find NFS shares. See [[autofs#NFS network mounts]] for details.<br />
<br />
==== Mounting from Windows ====<br />
<br />
{{Note|Only the Ultimate and Enterprise editions of Windows 7 and the Enterprise edition of Windows 8 include "Client for NFS".}}<br />
NFS shares can be mounted from Windows if the "Client for NFS" service is activated (which it is not by default).<br />
To install the service go to "Programs and features" in the Control Panel and click on "Turn Windows features on or off". Locate "Services for NFS" and activate it as well as both subservices ("Administrative tools" and "Client for NFS").<br />
<br />
Some global options can be set by opening the "Services for Network File System" (locate it with the search box) and right click on ''client > properties''.<br />
<br />
{{Warning|Serious performance issues may occur (it randomly takes 30-60 seconds to display a folder, 2 MB/s file copy speed on gigabit LAN, ...) to which Microsoft does not have a solution yet.[https://social.technet.microsoft.com/Forums/en-CA/w7itpronetworking/thread/40cc01e3-65e4-4bb6-855e-cef1364a60ac]}}<br />
<br />
To mount a share using Explorer:<br />
<br />
{{ic|Computer}} > {{ic|Map network drive}} > {{ic|servername:/srv/nfs4/music}}<br />
<br />
==== Mounting from OS X ====<br />
<br />
{{Note|OS X by default uses an insecure (>1024) port to mount a share.}}<br />
Either export the share with the {{ic|insecure}} flag, and mount using Finder:<br />
<br />
{{ic|Go}} > {{ic|Connect to Server}} > {{ic|nfs://servername/}}<br />
<br />
Or, mount the share using a secure port using the terminal:<br />
# mount -t nfs -o resvport,nolocks,locallocks servername:/srv/nfs4 /Volumes/servername<br />
<br />
See https://blogs.oracle.com/jag/entry/nfs_on_snow_leopard for an explanation on why to use the {{ic|nolocks}} and {{ic|locallocks}} options.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Performance tuning ===<br />
<br />
In order to get the most out of NFS, it is necessary to tune the {{ic|rsize}} and {{ic|wsize}} mount options to meet the requirements of the network configuration.<br />
<br />
=== Automatic mount handling ===<br />
<br />
This trick is useful for laptops that require nfs shares from a local wireless network. If the nfs host becomes unreachable, the nfs share will be unmounted to hopefully prevent system hangs when using the hard mount option. See https://bbs.archlinux.org/viewtopic.php?pid=1260240#p1260240<br />
<br />
Make sure that the NFS mount points are correctly indicated in {{ic|/etc/fstab}}:<br />
<br />
{{hc|$ cat /etc/fstab|<nowiki><br />
lithium:/mnt/data /mnt/data nfs noauto,noatime,rsize=32768,wsize=32768,intr,hard 0 0<br />
lithium:/var/cache/pacman /var/cache/pacman nfs noauto,noatime,rsize=32768,wsize=32768,intr,hard 0 0</nowiki><br />
}}<br />
<br />
The {{ic|noauto}} mount option tells systemd not to automatically mount the shares at boot. systemd would otherwise attempt to mount the nfs shares that may or may not exist on the network causing the boot process to appear to stall on a blank screen.<br />
<br />
In order to mount NFS share by non-root user {{ic|user}} may be required to be added to fstab entry. Also enable rpc-statd.service.<br />
<br />
Create the {{ic|auto_share}} script that will be used by ''cron'' to check if the NFS host is reachable,<br />
<br />
{{hc|/root/bin/auto_share|<nowiki><br />
#!/bin/bash<br />
<br />
SERVER="YOUR_NFS_HOST"<br />
<br />
MOUNT_POINTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " " | cut -f2 -d" ")<br />
<br />
ping -c 1 "${SERVER}" &>/dev/null<br />
<br />
if [ $? -ne 0 ]; then<br />
# The server could not be reached, unmount the shares<br />
for umntpnt in ${MOUNT_POINTS}; do<br />
umount -l -f $umntpnt &>/dev/null<br />
done<br />
else<br />
# The server is up, make sure the shares are mounted<br />
for mntpnt in ${MOUNT_POINTS}; do<br />
mountpoint -q $mntpnt || mount $mntpnt<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
# chmod +x /root/bin/auto_share<br />
<br />
Create the root cron entry to run {{ic|auto_share}} every minute:<br />
<br />
{{hc|# crontab -e|<nowiki><br />
* * * * * /root/bin/auto_share<br />
</nowiki>}}<br />
<br />
A systemd unit file can also be used to mount the NFS shares at startup. The unit file is not necessary if NetworkManager is installed and configured on the client system. See [[#NetworkManager dispatcher]].<br />
<br />
{{hc|/etc/systemd/system/auto_share.service|<nowiki><br />
[Unit]<br />
Description=NFS automount<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/root/bin/auto_share<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Now enable {{ic|auto_share}}.<br />
<br />
==== NetworkManager dispatcher ====<br />
<br />
In addition to the method described previously, NetworkManager can also be configured to run a script on network status change.<br />
<br />
Enable and start the {{ic|NetworkManager-dispatcher}} service.<br />
<br />
The easiest method for mount shares on network status change is to just symlink to the {{ic|auto_share}} script:<br />
<br />
# ln -s /root/bin/auto_share /etc/NetworkManager/dispatcher.d/30_nfs.sh<br />
<br />
Or use the following mounting script that checks for network availability:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30_nfs.sh|<nowiki><br />
#!/bin/bash<br />
<br />
SSID="CHANGE_ME"<br />
<br />
MOUNT_POINTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " " | cut -f2 -d" ")<br />
<br />
ISNETUP=$(nmcli dev wifi | \grep $SSID | tr -s ' ' | cut -f 10 -d ' ') 2>/dev/null<br />
<br />
# echo "$ISNETUP" >> /tmp/nm_dispatch_log<br />
<br />
if [[ "$ISNETUP" == "yes" ]]; then<br />
for mntpnt in ${MOUNT_POINTS}; do<br />
mountpoint -q $mntpnt || mount $mntpnt<br />
done<br />
else<br />
for srvexp in ${MOUNT_POINTS}; do<br />
umount -l -f $srvexp &>/dev/null<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
Now when the wireless SSID "CHANGE_ME" goes up or down, the {{ic|nfs.sh}} script will be called to mount or unmount the shares as soon as possible.<br />
<br />
== Troubleshooting ==<br />
<br />
There is a dedicated article [[NFS Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* See also [[Avahi]], a Zeroconf implementation which allows automatic discovery of NFS shares.<br />
* HOWTO: [[Diskless network boot NFS root]]<br />
* [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm NFS Performance Management]<br />
* If you are setting up the Arch Linux NFS server for use by Windows clients through Microsoft's SFU, you will save a lot of time and hair-scratching by looking at [https://bbs.archlinux.org/viewtopic.php?pid=523934#p523934 this forum post] first !<br />
* [http://blogs.msdn.com/sfu/archive/2008/04/14/all-well-almost-about-client-for-nfs-configuration-and-performance.aspx Microsoft Services for Unix NFS Client info]<br />
* [http://blogs.msdn.com/sfu/archive/2007/05/01/unix-interoperability-and-windows-vista.aspx Unix interoperability and Windows Vista] Prerequisites to connect to NFS with Vista</div>NorthAntrimhttps://wiki.archlinux.org/index.php?title=NFS&diff=319012NFS2014-06-10T16:21:46Z<p>NorthAntrim: /* Starting the server */ nfs-server.target requires nfs-utils to be updated. previously rpc-idmapd.service and rpc-mountd.service were used.</p>
<hr />
<div>[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ar:NFS]]<br />
[[de:Network File System]]<br />
[[es:NFS]]<br />
[[fr:NFS]]<br />
[[it:NFSv4]]<br />
[[zh-CN:NFS]]<br />
{{Related articles start}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related articles end}}<br />
From [[Wikipedia: Network File System|Wikipedia]]: <br />
: ''Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed.''<br />
<br />
== Installation ==<br />
<br />
Both client and server only require the [[pacman|installation]] of the {{Pkg|nfs-utils}} package.<br />
<br />
{{Note|It is HIGHLY recommended to use a time sync daemon on ALL nodes to keep client/server clocks in sync. Without accurate clocks on all nodes, NFS can introduce unwanted delays! The [[NTP]] system is recommended to sync both the server and the clients to the highly accurate NTP servers available on the Internet.}}<br />
<br />
==Configuration==<br />
<br />
===Server===<br />
<br />
==== ID mapping ====<br />
<br />
Edit {{ic|/etc/idmapd.conf}} and set the {{ic|Domain}}.<br />
<br />
{{hc|/etc/idmapd.conf|<nowiki><br />
[General]<br />
<br />
Verbosity = 1<br />
Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br />
Domain = atomic<br />
<br />
[Mapping]<br />
<br />
Nobody-User = nobody<br />
Nobody-Group = nobody<br />
</nowiki>}}<br />
<br />
==== File system ====<br />
<br />
{{Note|For security reasons, it is recommended to use an NFS export root which will keep users limited to that mount point only. The following example illustrates this concept.}}<br />
<br />
Define any NFS shares in {{ic|/etc/exports}} which are relative to the NFS root. In this example, the NFS root will be {{ic|/srv/nfs4}} and we will be sharing {{ic|/mnt/music}}.<br />
<br />
# mkdir -p /srv/nfs4/music<br />
<br />
Read/Write permissions must be set on the music directory so clients may write to it. <br />
<br />
Now mount the actual target share, {{ic|/mnt/music}} to the NFS share via the mount command:<br />
<br />
# mount --bind /mnt/music /srv/nfs4/music<br />
<br />
To make it stick across server reboots, add the bind mount to {{ic|fstab}}:<br />
{{hc|/etc/fstab|<br />
/mnt/music /srv/nfs4/music none bind 0 0<br />
}}<br />
<br />
==== Exports ====<br />
<br />
Add directories to be shared and an ip address or hostname(s) of client machines that will be allowed to mount them in {{ic|exports}}:<br />
{{hc|/etc/exports|<nowiki><br />
/srv/nfs4/ 192.168.1.0/24(rw,fsid=root,no_subtree_check)<br />
/srv/nfs4/music 192.168.1.0/24(rw,no_subtree_check,nohide) # note the nohide option which is applied to mounted directories on the file system.<br />
</nowiki>}}<br />
<br />
Users need-not open the share to the entire subnet; one can specify a single IP address or hostname as well.<br />
<br />
For more information about all available options see {{ic|man 5 exports}}.<br />
<br />
{{Note|Modifying {{ic|/etc/exports}} while the server is running will require a re-export for changes to take effect.}}<br />
# exportfs -rav<br />
<br />
==== NFSv2 compatibility ====<br />
<br />
If you need to support clients using NFSv2 (for example U-Boot), set NFSD_OPTS="-V 2" in /etc/conf.d/nfs-server.conf.<br />
<br />
==== Starting the server ====<br />
<br />
Start {{ic|nfs-server.target}} [[systemd#Using units|using systemd]] (you may need to update {{Pkg|nfs-utils}} for this command to work). It is recommended to also enable the target to allow systemd to start it at boot time. Note that this unit requires other services, which are launched automatically by [[systemd]].<br />
<br />
==== Firewall configuration ====<br />
<br />
To enable access through a firewall, tcp and udp ports 111, 2049, and 20048 need to be opened. To configure this for [[iptables]], edit {{ic|/etc/iptables/iptables.rules}} to include the following lines:<br />
<br />
{{hc|/etc/iptables/iptables.rules|<nowiki><br />
-A INPUT -p tcp -m tcp --dport 111 -j ACCEPT<br />
-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT<br />
-A INPUT -p tcp -m tcp --dport 20048 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 111 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 2049 -j ACCEPT<br />
-A INPUT -p udp -m udp --dport 20048 -j ACCEPT<br />
</nowiki>}}<br />
<br />
To apply changes, restart {{ic|iptables}} service.<br />
<br />
=== Client ===<br />
<br />
Start {{ic|nfs-client.target}} [[systemd#Using units|using systemd]]. It is recommended to also enable the target to allow systemd to start it at boot time. Note that this unit requires other services, which are launched automatically by [[systemd]].<br />
<br />
Clients with a kernel version prior to 3.12.7-2 (the current {{pkg|linux-lts}} for example) MUST start {{ic|rpc-gssd.service}} to avoid an approx 15 seconds delay with an accompanying error in dmesg that reads, "RPC: AUTH_GSS upcall timed out" due to a kernel bug.<br />
<br />
{{Note|The server does not need to run this service.}}<br />
<br />
{{Warning|Starting this service without having it configured properly will result in error messages like:<br />
rpc.gssd[30473]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'<br />
rpc.gssd[30473]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host server.domain<br />
rpc.gssd[30473]: ERROR: No credentials found for connection to server server.domain<br />
and might lock up any NFS mount on the system when mounting and unmounting some mounts very often.<br />
}}<br />
<br />
An alternative is to blacklist {{ic|rpcsec_gss_krb5}} as described [https://bugzilla.redhat.com/show_bug.cgi?id=1001934 on Red Hat's Bugzilla].<br />
<br />
# echo "blacklist rpcsec_gss_krb5" > /etc/modprobe.d/rpcsec_gss_krb5-blacklist.conf<br />
# reboot<br />
<br />
==== Mounting from Linux ====<br />
<br />
Show the server's exported file systems:<br />
$ showmount -e servername<br />
<br />
Then mount omitting the server's NFS export root: <br />
# mount -t nfs servername:/music /mountpoint/on/client<br />
<br />
If mount fails try including the server's export root (required for Debian/RHEL/SLES):<br />
# mount -t nfs servername:/full/path/to/music /mountpoint/on/client<br />
<br />
{{Note|Server name needs to be a valid hostname (not just IP address). Otherwise mounting of remote share will hang.}}<br />
<br />
===== Using /etc/fstab =====<br />
<br />
Using [[fstab]] is useful for a server which is always on, and the NFS shares are available whenever the client boots up. Edit {{ic|/etc/fstab}} file, and add an appropriate line reflecting the setup. Again, the server's NFS export root is omitted.<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
servername:/music /mountpoint/on/client nfs4 rsize=8192,wsize=8192,timeo=14,_netdev 0 0<br />
</nowiki>}}<br />
<br />
{{Note|Consult the ''NFS'' and ''mount'' man pages for more mount options.}}<br />
<br />
Some additional mount options to consider are include:<br />
<br />
; rsize and wsize: The {{ic|rsize}} value is the number of bytes used when reading from the server. The {{ic|wsize}} value is the number of bytes used when writing to the server. The default for both is 1024, but using higher values such as 8192 can improve throughput. This is not universal. It is recommended to test after making this change, see [[#Performance tuning]].<br />
<br />
; timeo: The {{ic|timeo}} value is the amount of time, in tenths of a second, to wait before resending a transmission after an RPC timeout. After the first timeout, the timeout value is doubled for each retry for a maximum of 60 seconds or until a major timeout occurs. If connecting to a slow server or over a busy network, better performance can be achieved by increasing this timeout value. <br />
<br />
; _netdev: The {{ic|_netdev}} option tells the system to wait until the network is up before trying to mount the share. systemd assumes this for NFS, but anyway it is good practice to use it for all types of networked file systems<br />
<br />
; minorversion: Use {{ic| <nowiki>minorversion=1</nowiki>}} for mounting a Windows Server 2012 (Essentials) share with NFS version 4.1<br />
<br />
{{Note|Setting the sixth field (fs_passno) to a nonzero value may lead to unexpected behaviour, e.g. hangs when the systemd automount waits for a check which will never happen.}}<br />
<br />
===== Using /etc/fstab with systemd =====<br />
<br />
Another method is using the systemd {{ic|automount}} service. This is a better option than {{ic|_netdev}}, because it remounts the network device quickly when the connection is broken and restored. As well, it solves the problem from autofs, see the example below:<br />
<br />
{{hc|1=/etc/fstab|2=<br />
servername :/home /mountpoint/on/client nfs users,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,hard,intr,noatime 0 0 <br />
}}<br />
<br />
{{Tip|{{ic|noauto}} above will not mount the NFS share until it is accessed: use {{ic|auto}} for it to be available immediately. <br> If you have any issues with the mount failing due to the network not being up/available, [[systemd#Using units|enable]] {{ic|NetworkManager-wait-online.service}}: this will ensure that {{ic|network.target}} has all the links available prior to being active.}}<br />
<br />
===== Using autofs =====<br />
<br />
Using [[autofs]] is useful when multiple machines want to connect via NFS; they could both be clients as well as servers. The reason this method is preferable over the earlier one is that if the server is switched off, the client will not throw errors about being unable to find NFS shares. See [[autofs#NFS network mounts]] for details.<br />
<br />
==== Mounting from Windows ====<br />
<br />
{{Note|Only the Ultimate and Enterprise editions of Windows 7 and the Enterprise edition of Windows 8 include "Client for NFS".}}<br />
NFS shares can be mounted from Windows if the "Client for NFS" service is activated (which it is not by default).<br />
To install the service go to "Programs and features" in the Control Panel and click on "Turn Windows features on or off". Locate "Services for NFS" and activate it as well as both subservices ("Administrative tools" and "Client for NFS").<br />
<br />
Some global options can be set by opening the "Services for Network File System" (locate it with the search box) and right click on ''client > properties''.<br />
<br />
{{Warning|Serious performance issues may occur (it randomly takes 30-60 seconds to display a folder, 2 MB/s file copy speed on gigabit LAN, ...) to which Microsoft does not have a solution yet.[https://social.technet.microsoft.com/Forums/en-CA/w7itpronetworking/thread/40cc01e3-65e4-4bb6-855e-cef1364a60ac]}}<br />
<br />
To mount a share using Explorer:<br />
<br />
{{ic|Computer}} > {{ic|Map network drive}} > {{ic|servername:/srv/nfs4/music}}<br />
<br />
==== Mounting from OS X ====<br />
<br />
{{Note|OS X by default uses an insecure (>1024) port to mount a share.}}<br />
Either export the share with the {{ic|insecure}} flag, and mount using Finder:<br />
<br />
{{ic|Go}} > {{ic|Connect to Server}} > {{ic|nfs://servername/}}<br />
<br />
Or, mount the share using a secure port using the terminal:<br />
# mount -t nfs -o resvport,nolocks,locallocks servername:/srv/nfs4 /Volumes/servername<br />
<br />
See https://blogs.oracle.com/jag/entry/nfs_on_snow_leopard for an explanation on why to use the {{ic|nolocks}} and {{ic|locallocks}} options.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Performance tuning ===<br />
<br />
In order to get the most out of NFS, it is necessary to tune the {{ic|rsize}} and {{ic|wsize}} mount options to meet the requirements of the network configuration.<br />
<br />
=== Automatic mount handling ===<br />
<br />
This trick is useful for laptops that require nfs shares from a local wireless network. If the nfs host becomes unreachable, the nfs share will be unmounted to hopefully prevent system hangs when using the hard mount option. See https://bbs.archlinux.org/viewtopic.php?pid=1260240#p1260240<br />
<br />
Make sure that the NFS mount points are correctly indicated in {{ic|/etc/fstab}}:<br />
<br />
{{hc|$ cat /etc/fstab|<nowiki><br />
lithium:/mnt/data /mnt/data nfs noauto,noatime,rsize=32768,wsize=32768,intr,hard 0 0<br />
lithium:/var/cache/pacman /var/cache/pacman nfs noauto,noatime,rsize=32768,wsize=32768,intr,hard 0 0</nowiki><br />
}}<br />
<br />
The {{ic|noauto}} mount option tells systemd not to automatically mount the shares at boot. systemd would otherwise attempt to mount the nfs shares that may or may not exist on the network causing the boot process to appear to stall on a blank screen.<br />
<br />
In order to mount NFS share by non-root user {{ic|user}} may be required to be added to fstab entry. Also enable rpc-statd.service.<br />
<br />
Create the {{ic|auto_share}} script that will be used by ''cron'' to check if the NFS host is reachable,<br />
<br />
{{hc|/root/bin/auto_share|<nowiki><br />
#!/bin/bash<br />
<br />
SERVER="YOUR_NFS_HOST"<br />
<br />
MOUNT_POINTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " " | cut -f2 -d" ")<br />
<br />
ping -c 1 "${SERVER}" &>/dev/null<br />
<br />
if [ $? -ne 0 ]; then<br />
# The server could not be reached, unmount the shares<br />
for umntpnt in ${MOUNT_POINTS}; do<br />
umount -l -f $umntpnt &>/dev/null<br />
done<br />
else<br />
# The server is up, make sure the shares are mounted<br />
for mntpnt in ${MOUNT_POINTS}; do<br />
mountpoint -q $mntpnt || mount $mntpnt<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
# chmod +x /root/bin/auto_share<br />
<br />
Create the root cron entry to run {{ic|auto_share}} every minute:<br />
<br />
{{hc|# crontab -e|<nowiki><br />
* * * * * /root/bin/auto_share<br />
</nowiki>}}<br />
<br />
A systemd unit file can also be used to mount the NFS shares at startup. The unit file is not necessary if NetworkManager is installed and configured on the client system. See [[#NetworkManager dispatcher]].<br />
<br />
{{hc|/etc/systemd/system/auto_share.service|<nowiki><br />
[Unit]<br />
Description=NFS automount<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/root/bin/auto_share<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Now enable {{ic|auto_share}}.<br />
<br />
==== NetworkManager dispatcher ====<br />
<br />
In addition to the method described previously, NetworkManager can also be configured to run a script on network status change.<br />
<br />
Enable and start the {{ic|NetworkManager-dispatcher}} service.<br />
<br />
The easiest method for mount shares on network status change is to just symlink to the {{ic|auto_share}} script:<br />
<br />
# ln -s /root/bin/auto_share /etc/NetworkManager/dispatcher.d/30_nfs.sh<br />
<br />
Or use the following mounting script that checks for network availability:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30_nfs.sh|<nowiki><br />
#!/bin/bash<br />
<br />
SSID="CHANGE_ME"<br />
<br />
MOUNT_POINTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " " | cut -f2 -d" ")<br />
<br />
ISNETUP=$(nmcli dev wifi | \grep $SSID | tr -s ' ' | cut -f 10 -d ' ') 2>/dev/null<br />
<br />
# echo "$ISNETUP" >> /tmp/nm_dispatch_log<br />
<br />
if [[ "$ISNETUP" == "yes" ]]; then<br />
for mntpnt in ${MOUNT_POINTS}; do<br />
mountpoint -q $mntpnt || mount $mntpnt<br />
done<br />
else<br />
for srvexp in ${MOUNT_POINTS}; do<br />
umount -l -f $srvexp &>/dev/null<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
Now when the wireless SSID "CHANGE_ME" goes up or down, the {{ic|nfs.sh}} script will be called to mount or unmount the shares as soon as possible.<br />
<br />
== Troubleshooting ==<br />
<br />
There is a dedicated article [[NFS Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* See also [[Avahi]], a Zeroconf implementation which allows automatic discovery of NFS shares.<br />
* HOWTO: [[Diskless network boot NFS root]]<br />
* [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm NFS Performance Management]<br />
* If you are setting up the Arch Linux NFS server for use by Windows clients through Microsoft's SFU, you will save a lot of time and hair-scratching by looking at [https://bbs.archlinux.org/viewtopic.php?pid=523934#p523934 this forum post] first !<br />
* [http://blogs.msdn.com/sfu/archive/2008/04/14/all-well-almost-about-client-for-nfs-configuration-and-performance.aspx Microsoft Services for Unix NFS Client info]<br />
* [http://blogs.msdn.com/sfu/archive/2007/05/01/unix-interoperability-and-windows-vista.aspx Unix interoperability and Windows Vista] Prerequisites to connect to NFS with Vista</div>NorthAntrimhttps://wiki.archlinux.org/index.php?title=ECryptfs&diff=273254ECryptfs2013-08-30T18:31:41Z<p>NorthAntrim: </p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[fr:Encryption avec eCryptfs]]<br />
[[it:System Encryption with eCryptfs]]<br />
[[ru:System Encryption with eCryptfs]]<br />
{{Article summary start}}<br />
{{Article summary text|Setup and usage of eCryptfs}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary end}}<br />
<br />
This article describes basic usage of [https://launchpad.net/ecryptfs eCryptfs]. It guides you through the process of creating a private and secure encrypted directory within your ''$HOME'' directory, where you can store all your sensitive files and private data.<br />
<br />
In implementation eCryptfs differs from dm-crypt, which provides a ''block device encryption layer'', while eCryptfs is an actual file-system &ndash; a [http://en.wikipedia.org/wiki/Cryptographic_filesystems stacked cryptographic file system] to be exact. For comparison of the two you can refer to [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare this table ]. <br />
<br />
The summary is that it doesn't require special on-disk storage allocation effort, such as separate partitions, you can mount eCryptfs on top of any single directory to protect it. That includes e.g. your entire $HOME and network file systems (i.e. having encrypted NFS shares). All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. There are other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you can't protect your swap space with it (instead you can combine it with dm-crypt).<br />
<br />
For more details on how eCryptfs compares to other disk encryption solutions, see [[Disk Encryption#Comparison table]]. <br />
<br />
== Deficiencies ==<br />
<br />
eCyptfs does not handle [https://en.wikipedia.org/wiki/Sparse_file sparse files] well; this should be considered before encrypting large portions of the directory structure ($HOME, for example). For most intents and purposes this deficiency does not pose a problem. Using eCryptfs to encrypt sparse files, however, currently encrypts the entire allocated space of the sparse file, which, in the case of big files, can starve the system of resources. (This bug may be tracked [https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/431975 on Launchpad]). One popular and inadvisable application of eCryptfs is to encrypt a BitTorrent download location; this often requires eCryptfs to handle sparse files of 10 GB or more and may lead to intense disk starvation. A simple workaround is to place sparse files in an unencrypted '''.Public''' directory (as opposed to the standard eCryptfs '''.Private''' directory, explained below).<br />
<br />
=== Login password ===<br />
<br />
{{note|1= With {{pkg|shadow}} 4.1.4.3-3 ''sha512'' is the default for new passwords (see [https://bugs.archlinux.org/task/13591#comment85993 bug 13591] and corresponding [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shadow&id=98001501a8306ef5a0df55d1cffc048851894940 commit]).}}<br />
<br />
If you are encrypting your whole home, with auto-mounting you should use a strong password and consider changing the hash algorithm for ''/etc/shadow'' from '''md5''' to stronger ones like '''sha512/bcrypt''' that helps to protect your password against rainbow-table attacks. See https://wiki.archlinux.org/index.php/SHA_password_hashes for more information.<br />
<br />
== Basics ==<br />
eCryptfs is a part of Linux since version 2.6.19. But to work with it you will need the userspace tools provided by the package {{pkg|ecryptfs-utils}} available in the [[Official Repositories]].<br />
<br />
Once you have installed that package you can load the ecryptfs module and continue with the setup:<br />
# modprobe ecryptfs<br />
<br />
The ecryptfs-utils package is distributed with a few helper scripts which will help you with key management and similar tasks. Some were written to automate this whole process of setting up encrypted directories (''ecryptfs-setup-private'') or help you combine eCryptfs with dm-crypt to protect swap space (''ecryptfs-setup-swap''). Despite those scripts we will go trough the process manually so you get a better understanding of what is really being done.<br />
<br />
Before we say anything else it's advised that you check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.<br />
<br />
=== Setup (simple) ===<br />
<br />
As a user run<br />
ecryptfs-setup-private<br />
and follow the instructions.<br />
<br />
=== Setup (migrating) ===<br />
<br />
If a user's home directory wasn't setup beforehand, you can migrate it.<br />
<br />
Ensure that the user you want to migrate ''owns no processes'' and is ''logged out''. You also need to ensure that you have {{pkg|rsync}} installed. Once the prerequisites have been met run as root:<br />
<br />
ecryptfs-migrate-home -u archey<br />
<br />
(replacing "archey" with your user) and follow the instructions. It is imperative that the user logs in ''before'' the next reboot.<br />
<br />
=== Setup (in detail) ===<br />
<br />
First create your private directories, in this example we will call them exactly that: Private<br />
$ su -<br />
# mkdir -m 700 /home/username/.Private<br />
# mkdir -m 500 /home/username/Private<br />
# chown username:username /home/username/{.Private,Private}<br />
<br />
Let's summarize<br />
* Actual encrypted data will be stored in ~/.Private directory (so-called ''lower'' directory)<br />
* While mounted, decrypted data will be available in ~/Private directory (so-called ''upper'' directory)<br />
** While not mounted nothing can be written to this directory<br />
** While mounted it has the same permissions as the lower directory<br />
<br />
eCryptfs can now be mounted on top of ~/Private.<br />
# mount -t ecryptfs /home/username/.Private /home/username/Private<br />
<br />
You will need to answer a few questions and provide a passphrase which should be used to mount this directory in the future. However you can also have different keys encrypting different data (more about this below). For convenience we will limit this guide to only one key and passphrase. Let's see an example:<br />
Key type: passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
Cipher: aes<br />
Key byte: 16<br />
Plaintext passtrough: no<br />
Filename encryption: no<br />
Add signature to cache: yes <br />
<br />
Let's summarize<br />
* The passphrase is your '''mount passphrase''' which will be salted, hashed and loaded into the kernel keyring.<br />
** In eCryptfs terms, this salted, hashed passphrase is your "file encryption key, encryption key", or '''fekek'''.<br />
* eCryptfs supports a few different ciphers (AES, blowfish, twofish...). You can read about them on Wikipedia.<br />
* Plaintext passtrough enables you to store and work with '''un-encrypted''' files stored in the lower directory.<br />
* Filename encryption is available since Linux 2.6.29<br />
** In eCryptfs terms the key used to protect filenames is known as "filename encryption key", or '''fnek'''.<br />
* The signature of the key(s) will be stored in {{ic|/root/.ecryptfs/sig-cache.txt}}.<br />
<br />
Since our later goal is to be able to mount without root privileges, we will now move the eCryptfs configuration directory to your own home and transfer the ownership to you:<br />
# mv /root/.ecryptfs /home/username<br />
# chown username:username /home/username/.ecryptfs<br />
<br />
Your setup is now complete and directory is mounted. You can place any file in the '''~/Private''' directory and it will get encrypted in '''~/.Private'''.<br />
<br />
Now copy a few files to your new private directory, and then un-mount it. If you inspect the files you will see that they are unreadable &ndash; encrypted. That was cool you say, but how do I get them back... and that brings us to:<br />
<br />
==== Extra Notes ====<br />
<br />
Above is detailed the simplest way to setup the mount point, but '''ecryptfs-setup-private''' runs through some extra steps.<br />
<br />
* The above '''mount passphrase''' is derived from the passphrase you type in. This is not considered very [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#pubkey-about secure], so the setup script grabs some characters from {{ic|/dev/random}} for safety:<br />
<br />
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g"<br />
<br />
* '''ecryptfs-setup-private''' also takes the resulting mount passphrase and wraps it with your login passphrase (pasword) and stores this in '''~/.ecryptfs/wrapped-passphrase'''. You can replicate this with: <br />
<br />
$ ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase <br />
Passphrase to wrap: <br />
Wrapping passphrase:<br />
<br />
=== Mounting (the hard way) ===<br />
Whenever you need your files available you can repeat the above mount procedure, using the same passphrase and options if you want to access your previously encrypted files or using a different passphrase (and possibly options) if for some reason you want to have different keys protecting different data (imagine having a publicly shared directory where different data is encrypted by different users, and their keys).<br />
<br />
In any case going trough those questions every time could be a bit tedious.<br />
<br />
One solution would be to create an entry in the '''{{ic|/etc/fstab}}''' file for this mount point:<br />
<br />
/home/user/.Private /home/user/Private ecryptfs [... user ... ecryptfs_sig=XY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0<br />
<br />
* You will notice that we defined the '''user''' option, it enables you to mount the directory as a user (if it does not works as a normal user, you may need to setuid mount.ecryptfs by running as root: ''chmod +s /sbin/mount.ecryptfs'')<br />
* Notice the '''ecryptfs_sig''' option, replace ''XY'' with your own key signature (as seen in the '''mtab''' line earlier and in {{ic|sig-cache.txt}})<br />
* If you enabled filename encryption then pass an additional mount option: '''ecryptfs_fnek_sig'''=''XY'', where ''XY'' is the same signature you provide with the '''ecryptfs_sig''' option.<br />
* Last option '''ecrypfs_unlink_sigs''' ensures that your keyring is cleared every time the directory is un-mounted<br />
<br />
Since your key was deleted from the kernel keyring when you un-mounted, in order to mount you need to insert it into the keyring again. You can use the '''ecryptfs-add-passphrase''' utility or the '''ecryptfs-manager''' to do it:<br />
<br />
When the key is inserted you can mount the directory: <br />
$ ecryptfs-add-passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
<br />
$ mount -i /home/username/Private<br />
<br />
You will notice that we used the '''{{Ic|-i}}''' option this time. It disables invoking the mount helper. Speaking of which, using {{Ic|-i}} by default mounts with: '''nosuid, noexec''' and '''nodev'''. If you want to have at least executable files in your private directory you can add the '''exec''' option to the fstab line.<br />
<br />
This would be a good place to mention the '''keyctl''' utility from the (earlier installed) ''keyutils'' package. It can be used for any advanced key management tasks. Following examples show how to list your keyring contents and how to clear them:<br />
$ keyctl list @u<br />
$ keyctl clear @u<br />
<br />
{{Note|However, one should remember that /etc/fstab is for system-wide partitions only and should not be used for user-specific mounts}}<br />
<br />
=== Auto-mounting (the easy way) ===<br />
A better way is to use PAM directly, see 'PAM MODULE' in:<br />
/usr/share/doc/ecryptfs-utils/README<br />
<br />
1. Check if '''~/.ecryptfs/auto-mount''' and '''~/.ecryptfs/wrapped-passphrase''' (these are automatically created by '''ecryptfs-setup-private''') exist.<br />
<br />
2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login.<br />
<br />
Open '''/etc/pam.d/system-auth''' and add this ''after'' the line containing '''auth required pam_unix.so [...]''':<br />
auth required pam_ecryptfs.so unwrap<br />
, then add this ''above'' the line containing '''password required pam_unix.so [...]''':<br />
password optional pam_ecryptfs.so<br />
, and this ''after'' the line '''session required pam_unix.so''':<br />
session optional pam_ecryptfs.so unwrap<br />
<br />
3. Relogin (you need to type the user's password for obvious reason ;) and check output of '''mount''' which should now contain a mountpoint, e.g.:<br />
/home/$USER/.Private on /home/$USER/Private type ecryptfs (...)<br />
Your user's encrypted directory should be perfectly readable, e.g. $HOME/Private/<br />
<br />
Note that the latter will be automatically unmounted and made unavailable when the user log off.<br />
<br />
=== Usage ===<br />
Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Take ''Firefox'' for an example, not only does it have an internal password manager but the browsing history and cache can also be sensitive. Protecting it is easy:<br />
$ mv ~/.mozilla ~/Private/mozilla<br />
$ ln -s ~/Private/mozilla ~/.mozilla<br />
<br />
=== Removal ===<br />
If you want to move a file out of the private directory just move it to it's new destination while ~/Private is mounted. Also note that there are no special steps involved if you want to remove your private directory. Make sure it is un-mounted and delete ~/.Private, along with all the files.<br />
<br />
=== Backup ===<br />
Setup explained here separates the directory with encrypted data from the mount point, so the encrypted data is available for backup at any time. With an overlay mount (i.e. ''~/Secret'' mounted over ''~/Secret'') the lower, encrypted, data is harder to get to. Today when cronjobs and other automation software do automatic backups the risk of leaking your sensitive data is higher.<br />
<br />
We explained earlier that all cryptographic metadata is stored in the headers of files. You can easily do backups, or incremental backups, of your '''~/.Private''' directory, treating it like any other directory.<br />
<br />
== Advanced ==<br />
This wiki article covers only the basic setup of a private encrypted directory. There is however another article about eCryptfs on Arch Linux, which covers encryption of your entire $HOME and encrypting swap space without breaking hibernation (suspend to disk).<br />
<br />
That article includes many more steps (i.e. using PAM modules and automatic mounting) and the author was opposed to replicating it here, because there is just no single "right" way to do it. The author proposes some solutions and discusses the security implications, but they are his solutions and as such might not be the best nor are they endorsed by the eCryptfs project in any way.<br />
<br />
Article: [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html eCryptfs and $HOME] by Adrian C. (anrxc).<br />
<br />
Consider that ''Chromium OS'', as released by Google, is using eCryptfs to protect devices that are, and will be, powered by it. Some implementation details are available and they make excellent reading. You can read them [http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data here], they could help a lot as you're coming up with your own strategy.<br />
<br />
=== PAM Mount ===<br />
<br />
The above "''eCryptfs and $HOME''" article uses a shell init file to mount the home directory. The same can be done using [[pam_mount]] with the added benefit that home is un-mounted when all sessions are logged out. Add the following lines to {{ic|/etc/security/pam_mount.conf.xml}}:<br />
<br />
<luserconf name=".pam_mount.conf.xml" /><br />
<mntoptions require="" /> <!-- Default required mount options are ; this clears them --><br />
<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount> <!-- --><br />
<br />
Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters.<br />
Explanation:<br />
* the first line indicates where the user-based configuration file is located (here {{ic|~/.pam_mount.conf.xml}}) ;<br />
* the second line overwrites the default required mount options which are unnecessary ("nosuid,nodev") ;<br />
* the last line indicates which mount command to run (eCryptfs needs the {{Ic|-i}} switch).<br />
<br />
Then set the volume definition, preferably to {{ic|~/.pam_mount.conf.xml}}:<br />
<pam_mount><br />
<volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/><br />
</pam_mount><br />
<br />
"noroot" is needed because the encryption key will be added to the user's keyring<br />
<br />
Finally, edit {{ic|/etc/pam.d/login}} as described in [[pam_mount]]'s article.<br />
<br />
==== Optional step ====<br />
<br />
To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check ''pmvarrun'' to see the number of open sessions:<br />
#!/bin/sh<br />
#<br />
# /usr/local/bin/doecryptfs<br />
<br />
exit $(/usr/sbin/pmvarrun -u$PAM_USER -o0)<br />
<br />
With the following line added before the eCryptfs unwrap module in your PAM stack:<br />
auth [success=ignore default=1] pam_exec.so quiet /usr/local/bin/doecryptfs<br />
auth required pam_ecryptfs.so unwrap<br />
The article suggests adding these to {{ic|/etc/pam.d/login}}, but the changes will need to be added to all other places you login, such as {{ic|/etc/pam.d/kde}}.<br />
<br />
=== PAM mount by eCryptfs module ===<br />
To use the eCryptfs PAM module it self for mounting you should know it depends on some hard-coded Ubuntu defaults. Like using AES cipher with a 16 byte key. As described in this BBS post [https://bbs.archlinux.org/viewtopic.php?pid=727422#p727422] you have to do the following steps:<br />
<br />
1) For your understanding and preparation, read the guide mentioned above. [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html]<br />
<br />
2) Install [https://www.archlinux.org/packages/core/x86_64/keyutils/ keyutils] and [https://www.archlinux.org/packages/community/x86_64/ecryptfs-utils/ ecryptfs-utils] from the official Repos.<br />
<br />
'''[Do the following steps as root!]'''<br />
<br />
3) Make a "ecryptfs" Group:<br />
groupadd ecryptfs<br />
4) Add the user to it:<br />
usermod -aG ecryptfs user<br />
5) Load the ecryptfs module<br />
modprobe ecryptfs<br />
6) Change your /etc/pam.d/system-auth to look something like this (lines to add are bold):<br />
#%PAM-1.0<br />
<br />
auth required pam_env.so<br />
auth required pam_unix.so try_first_pass nullok<br />
'''auth required pam_ecryptfs.so unwrap'''<br />
auth optional pam_permit.so<br />
<br />
account required pam_unix.so<br />
account optional pam_permit.so<br />
account required pam_time.so<br />
<br />
'''password required pam_ecryptfs.so'''<br />
password required pam_unix.so try_first_pass nullok sha512 shadow<br />
password optional pam_permit.so<br />
<br />
'''session required pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
session required pam_env.so<br />
session required pam_unix.so<br />
session optional pam_permit.so<br />
<br />
<br />
6a) When using [[GDM]] < 3.2 to log in, edit /etc/pam.d/gdm like this:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6b) For [[GDM]] >= 3.2, make the following changes to /etc/pam.d/gdm-password (thanks to grawity for [https://bbs.archlinux.org/viewtopic.php?pid=998061#p998061 this]):<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth requisite pam_unix.so nullok<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
auth sufficient pam_succeed_if.so uid >= 1000 quiet<br />
auth required pam_deny.so<br />
account required pam_unix.so<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
session required pam_loginuid.so<br />
-session optional pam_systemd.so<br />
session optional pam_keyinit.so '''force''' revoke<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
6c) For [[KDM]], make the following changes to /etc/pam.d/kde:<br />
<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_nologin.so<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
<br />
6d) For [[LXDM]], make the following changes to /etc/pam.d/lxdm:<br />
<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6e) For [[LightDM]], make the following changes to /etc/pam.d/lightdm<br />
<br />
#%PAM-1.0<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
<br />
7) To be able to automatically mount your encrypted home directory on login using SSH, edit /etc/pam.d/sshd:<br />
#%PAM-1.0<br />
#auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_env.so<br />
account required pam_nologin.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password required pam_unix.so<br />
password optional pam_ecryptfs.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
session optional pam_ck_connector.so nox11<br />
<br />
8) Using Ubuntu defaults<br />
<br />
There's a method to automatically setup your HOME with AES and a 16 byte key. You could execute (it can take some while, it automatically encrypts your home files)<br />
ecryptfs-migrate-home -u user<br />
<br />
...and follow the on screen instructions (Delete backup afterwards (/home/user.XXXXX) / Record the passphrase generated by ecryptfs -> ecryptfs-unwrap-passphrase / ...)<br />
<br />
9) Log in and check if everything worked correctly.<br />
<br />
This is a working solution and ecryptfs is exactly used as in Ubuntu (10.04/10.10) - and is easy to set up. <br />
Besides this, it has the advantage of auto-unmount at log-out, which shell profile files (ie. ~/.bash_logout) could have trouble doing, because there could still be open file-descriptors by the shell at the time of umount. To encrypt swap see: [[System_Encryption_with_LUKS#Encrypting_the_Swap_partition]] (some of the tools provided by ecryptfs, such as ecryptfs-setup-swap, only work in ubuntu).<br />
<br />
== ecryptfs-simple ==<br />
Use [http://xyne.archlinux.ca/projects/ecryptfs-simple/ ecryptfs-simple] if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in fstab, nor is it limited to hard-coded directories such as ~/.Private. The package is available in the [https://aur.archlinux.org/packages.php?ID=59612 AUR] and in [http://xyne.archlinux.ca/repos/ Xyne's repos].<br />
<br />
As the name implies, usage is simple:<br />
# simple mounting<br />
ecryptfs-simple /path/to/foo /path/to/bar<br />
<br />
# automatic mounting: prompts for options on the first mount of a directory then reloads them next time<br />
ecryptfs-simple -a /path/to/foo /path/to/bar<br />
<br />
# unmounting by source directory<br />
ecryptfs-simple -u /path/to/foo<br />
<br />
# unmounting by mountpoint<br />
ecryptfs-simple -u /path/to/bar</div>NorthAntrimhttps://wiki.archlinux.org/index.php?title=ECryptfs&diff=273184ECryptfs2013-08-30T11:48:59Z<p>NorthAntrim: </p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[fr:Encryption avec eCryptfs]]<br />
[[it:System Encryption with eCryptfs]]<br />
[[ru:System Encryption with eCryptfs]]<br />
{{Article summary start}}<br />
{{Article summary text|Setup and usage of eCryptfs}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary end}}<br />
<br />
This article describes basic usage of [https://launchpad.net/ecryptfs eCryptfs]. It guides you through the process of creating a private and secure encrypted directory within your ''$HOME'' directory, where you can store all your sensitive files and private data.<br />
<br />
In implementation eCryptfs differs from dm-crypt, which provides a ''block device encryption layer'', while eCryptfs is an actual file-system &ndash; a [http://en.wikipedia.org/wiki/Cryptographic_filesystems stacked cryptographic file system] to be exact. For comparison of the two you can refer to [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare this table ]. <br />
<br />
The summary is that it doesn't require special on-disk storage allocation effort, such as separate partitions, you can mount eCryptfs on top of any single directory to protect it. That includes e.g. your entire $HOME and network file systems (i.e. having encrypted NFS shares). All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. There are other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you can't protect your swap space with it (instead you can combine it with dm-crypt).<br />
<br />
For more details on how eCryptfs compares to other disk encryption solutions, see [[Disk Encryption#Comparison table]]. <br />
<br />
== Deficiencies ==<br />
<br />
eCyptfs does not handle [https://en.wikipedia.org/wiki/Sparse_file sparse files] well; this should be considered before encrypting large portions of the directory structure ($HOME, for example). For most intents and purposes this deficiency does not pose a problem. Using eCryptfs to encrypt sparse files, however, currently encrypts the entire allocated space of the sparse file, which, in the case of big files, can starve the system of resources. (This bug may be tracked [https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/431975 on Launchpad]). One popular and inadvisable application of eCryptfs is to encrypt a BitTorrent download location; this often requires eCryptfs to handle sparse files of 10 GB or more and may lead to intense disk starvation. A simple workaround is to place sparse files in an unencrypted '''.Public''' directory (as opposed to the standard eCryptfs '''.Private''' directory, explained below).<br />
<br />
=== Login password ===<br />
<br />
{{note|1= With {{pkg|shadow}} 4.1.4.3-3 ''sha512'' is the default for new passwords (see [https://bugs.archlinux.org/task/13591#comment85993 bug 13591] and corresponding [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shadow&id=98001501a8306ef5a0df55d1cffc048851894940 commit]).}}<br />
<br />
If you are encrypting your whole home, with auto-mounting you should use a strong password and consider changing the hash algorithm for ''/etc/shadow'' from '''md5''' to stronger ones like '''sha512/bcrypt''' that helps to protect your password against rainbow-table attacks. See https://wiki.archlinux.org/index.php/SHA_password_hashes for more information.<br />
<br />
== Basics ==<br />
eCryptfs is a part of Linux since version 2.6.19. But to work with it you will need the userspace tools provided by the package {{pkg|ecryptfs-utils}} available in the [[Official Repositories]].<br />
<br />
Once you have installed that package you can load the ecryptfs module and continue with the setup:<br />
# modprobe ecryptfs<br />
<br />
The ecryptfs-utils package is distributed with a few helper scripts which will help you with key management and similar tasks. Some were written to automate this whole process of setting up encrypted directories (''ecryptfs-setup-private'') or help you combine eCryptfs with dm-crypt to protect swap space (''ecryptfs-setup-swap''). Despite those scripts we will go trough the process manually so you get a better understanding of what is really being done.<br />
<br />
Before we say anything else it's advised that you check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.<br />
<br />
=== Setup (simple) ===<br />
<br />
As a user run<br />
ecryptfs-setup-private<br />
and follow the instructions.<br />
<br />
=== Setup (migrating) ===<br />
<br />
If a user's home directory wasn't setup beforehand, you can migrate it.<br />
<br />
Ensure that the user you want to migrate owns no processes and is logged out. You also need to ensure that you have rsync installed then as root run:<br />
<br />
ecryptfs-migrate-home -u archey<br />
<br />
(replacing "archey" with your user) and follow the instructions. It is imperative that the user logs in ''before'' the next reboot.<br />
<br />
=== Setup (in detail) ===<br />
<br />
First create your private directories, in this example we will call them exactly that: Private<br />
$ su -<br />
# mkdir -m 700 /home/username/.Private<br />
# mkdir -m 500 /home/username/Private<br />
# chown username:username /home/username/{.Private,Private}<br />
<br />
Let's summarize<br />
* Actual encrypted data will be stored in ~/.Private directory (so-called ''lower'' directory)<br />
* While mounted, decrypted data will be available in ~/Private directory (so-called ''upper'' directory)<br />
** While not mounted nothing can be written to this directory<br />
** While mounted it has the same permissions as the lower directory<br />
<br />
eCryptfs can now be mounted on top of ~/Private.<br />
# mount -t ecryptfs /home/username/.Private /home/username/Private<br />
<br />
You will need to answer a few questions and provide a passphrase which should be used to mount this directory in the future. However you can also have different keys encrypting different data (more about this below). For convenience we will limit this guide to only one key and passphrase. Let's see an example:<br />
Key type: passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
Cipher: aes<br />
Key byte: 16<br />
Plaintext passtrough: no<br />
Filename encryption: no<br />
Add signature to cache: yes <br />
<br />
Let's summarize<br />
* The passphrase is your '''mount passphrase''' which will be salted, hashed and loaded into the kernel keyring.<br />
** In eCryptfs terms, this salted, hashed passphrase is your "file encryption key, encryption key", or '''fekek'''.<br />
* eCryptfs supports a few different ciphers (AES, blowfish, twofish...). You can read about them on Wikipedia.<br />
* Plaintext passtrough enables you to store and work with '''un-encrypted''' files stored in the lower directory.<br />
* Filename encryption is available since Linux 2.6.29<br />
** In eCryptfs terms the key used to protect filenames is known as "filename encryption key", or '''fnek'''.<br />
* The signature of the key(s) will be stored in {{ic|/root/.ecryptfs/sig-cache.txt}}.<br />
<br />
Since our later goal is to be able to mount without root privileges, we will now move the eCryptfs configuration directory to your own home and transfer the ownership to you:<br />
# mv /root/.ecryptfs /home/username<br />
# chown username:username /home/username/.ecryptfs<br />
<br />
Your setup is now complete and directory is mounted. You can place any file in the '''~/Private''' directory and it will get encrypted in '''~/.Private'''.<br />
<br />
Now copy a few files to your new private directory, and then un-mount it. If you inspect the files you will see that they are unreadable &ndash; encrypted. That was cool you say, but how do I get them back... and that brings us to:<br />
<br />
==== Extra Notes ====<br />
<br />
Above is detailed the simplest way to setup the mount point, but '''ecryptfs-setup-private''' runs through some extra steps.<br />
<br />
* The above '''mount passphrase''' is derived from the passphrase you type in. This is not considered very [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#pubkey-about secure], so the setup script grabs some characters from {{ic|/dev/random}} for safety:<br />
<br />
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g"<br />
<br />
* '''ecryptfs-setup-private''' also takes the resulting mount passphrase and wraps it with your login passphrase (pasword) and stores this in '''~/.ecryptfs/wrapped-passphrase'''. You can replicate this with: <br />
<br />
$ ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase <br />
Passphrase to wrap: <br />
Wrapping passphrase:<br />
<br />
=== Mounting (the hard way) ===<br />
Whenever you need your files available you can repeat the above mount procedure, using the same passphrase and options if you want to access your previously encrypted files or using a different passphrase (and possibly options) if for some reason you want to have different keys protecting different data (imagine having a publicly shared directory where different data is encrypted by different users, and their keys).<br />
<br />
In any case going trough those questions every time could be a bit tedious.<br />
<br />
One solution would be to create an entry in the '''{{ic|/etc/fstab}}''' file for this mount point:<br />
<br />
/home/user/.Private /home/user/Private ecryptfs [... user ... ecryptfs_sig=XY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0<br />
<br />
* You will notice that we defined the '''user''' option, it enables you to mount the directory as a user (if it does not works as a normal user, you may need to setuid mount.ecryptfs by running as root: ''chmod +s /sbin/mount.ecryptfs'')<br />
* Notice the '''ecryptfs_sig''' option, replace ''XY'' with your own key signature (as seen in the '''mtab''' line earlier and in {{ic|sig-cache.txt}})<br />
* If you enabled filename encryption then pass an additional mount option: '''ecryptfs_fnek_sig'''=''XY'', where ''XY'' is the same signature you provide with the '''ecryptfs_sig''' option.<br />
* Last option '''ecrypfs_unlink_sigs''' ensures that your keyring is cleared every time the directory is un-mounted<br />
<br />
Since your key was deleted from the kernel keyring when you un-mounted, in order to mount you need to insert it into the keyring again. You can use the '''ecryptfs-add-passphrase''' utility or the '''ecryptfs-manager''' to do it:<br />
<br />
When the key is inserted you can mount the directory: <br />
$ ecryptfs-add-passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
<br />
$ mount -i /home/username/Private<br />
<br />
You will notice that we used the '''{{Ic|-i}}''' option this time. It disables invoking the mount helper. Speaking of which, using {{Ic|-i}} by default mounts with: '''nosuid, noexec''' and '''nodev'''. If you want to have at least executable files in your private directory you can add the '''exec''' option to the fstab line.<br />
<br />
This would be a good place to mention the '''keyctl''' utility from the (earlier installed) ''keyutils'' package. It can be used for any advanced key management tasks. Following examples show how to list your keyring contents and how to clear them:<br />
$ keyctl list @u<br />
$ keyctl clear @u<br />
<br />
{{Note|However, one should remember that /etc/fstab is for system-wide partitions only and should not be used for user-specific mounts}}<br />
<br />
=== Auto-mounting (the easy way) ===<br />
A better way is to use PAM directly, see 'PAM MODULE' in:<br />
/usr/share/doc/ecryptfs-utils/README<br />
<br />
1. Check if '''~/.ecryptfs/auto-mount''' and '''~/.ecryptfs/wrapped-passphrase''' (these are automatically created by '''ecryptfs-setup-private''') exist.<br />
<br />
2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login.<br />
<br />
Open '''/etc/pam.d/system-auth''' and add this ''after'' the line containing '''auth required pam_unix.so [...]''':<br />
auth required pam_ecryptfs.so unwrap<br />
, then add this ''above'' the line containing '''password required pam_unix.so [...]''':<br />
password optional pam_ecryptfs.so<br />
, and this ''after'' the line '''session required pam_unix.so''':<br />
session optional pam_ecryptfs.so unwrap<br />
<br />
3. Relogin (you need to type the user's password for obvious reason ;) and check output of '''mount''' which should now contain a mountpoint, e.g.:<br />
/home/$USER/.Private on /home/$USER/Private type ecryptfs (...)<br />
Your user's encrypted directory should be perfectly readable, e.g. $HOME/Private/<br />
<br />
Note that the latter will be automatically unmounted and made unavailable when the user log off.<br />
<br />
=== Usage ===<br />
Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Take ''Firefox'' for an example, not only does it have an internal password manager but the browsing history and cache can also be sensitive. Protecting it is easy:<br />
$ mv ~/.mozilla ~/Private/mozilla<br />
$ ln -s ~/Private/mozilla ~/.mozilla<br />
<br />
=== Removal ===<br />
If you want to move a file out of the private directory just move it to it's new destination while ~/Private is mounted. Also note that there are no special steps involved if you want to remove your private directory. Make sure it is un-mounted and delete ~/.Private, along with all the files.<br />
<br />
=== Backup ===<br />
Setup explained here separates the directory with encrypted data from the mount point, so the encrypted data is available for backup at any time. With an overlay mount (i.e. ''~/Secret'' mounted over ''~/Secret'') the lower, encrypted, data is harder to get to. Today when cronjobs and other automation software do automatic backups the risk of leaking your sensitive data is higher.<br />
<br />
We explained earlier that all cryptographic metadata is stored in the headers of files. You can easily do backups, or incremental backups, of your '''~/.Private''' directory, treating it like any other directory.<br />
<br />
== Advanced ==<br />
This wiki article covers only the basic setup of a private encrypted directory. There is however another article about eCryptfs on Arch Linux, which covers encryption of your entire $HOME and encrypting swap space without breaking hibernation (suspend to disk).<br />
<br />
That article includes many more steps (i.e. using PAM modules and automatic mounting) and the author was opposed to replicating it here, because there is just no single "right" way to do it. The author proposes some solutions and discusses the security implications, but they are his solutions and as such might not be the best nor are they endorsed by the eCryptfs project in any way.<br />
<br />
Article: [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html eCryptfs and $HOME] by Adrian C. (anrxc).<br />
<br />
Consider that ''Chromium OS'', as released by Google, is using eCryptfs to protect devices that are, and will be, powered by it. Some implementation details are available and they make excellent reading. You can read them [http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data here], they could help a lot as you're coming up with your own strategy.<br />
<br />
=== PAM Mount ===<br />
<br />
The above "''eCryptfs and $HOME''" article uses a shell init file to mount the home directory. The same can be done using [[pam_mount]] with the added benefit that home is un-mounted when all sessions are logged out. Add the following lines to {{ic|/etc/security/pam_mount.conf.xml}}:<br />
<br />
<luserconf name=".pam_mount.conf.xml" /><br />
<mntoptions require="" /> <!-- Default required mount options are ; this clears them --><br />
<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount> <!-- --><br />
<br />
Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters.<br />
Explanation:<br />
* the first line indicates where the user-based configuration file is located (here {{ic|~/.pam_mount.conf.xml}}) ;<br />
* the second line overwrites the default required mount options which are unnecessary ("nosuid,nodev") ;<br />
* the last line indicates which mount command to run (eCryptfs needs the {{Ic|-i}} switch).<br />
<br />
Then set the volume definition, preferably to {{ic|~/.pam_mount.conf.xml}}:<br />
<pam_mount><br />
<volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/><br />
</pam_mount><br />
<br />
"noroot" is needed because the encryption key will be added to the user's keyring<br />
<br />
Finally, edit {{ic|/etc/pam.d/login}} as described in [[pam_mount]]'s article.<br />
<br />
==== Optional step ====<br />
<br />
To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check ''pmvarrun'' to see the number of open sessions:<br />
#!/bin/sh<br />
#<br />
# /usr/local/bin/doecryptfs<br />
<br />
exit $(/usr/sbin/pmvarrun -u$PAM_USER -o0)<br />
<br />
With the following line added before the eCryptfs unwrap module in your PAM stack:<br />
auth [success=ignore default=1] pam_exec.so quiet /usr/local/bin/doecryptfs<br />
auth required pam_ecryptfs.so unwrap<br />
The article suggests adding these to {{ic|/etc/pam.d/login}}, but the changes will need to be added to all other places you login, such as {{ic|/etc/pam.d/kde}}.<br />
<br />
=== PAM mount by eCryptfs module ===<br />
To use the eCryptfs PAM module it self for mounting you should know it depends on some hard-coded Ubuntu defaults. Like using AES cipher with a 16 byte key. As described in this BBS post [https://bbs.archlinux.org/viewtopic.php?pid=727422#p727422] you have to do the following steps:<br />
<br />
1) For your understanding and preparation, read the guide mentioned above. [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html]<br />
<br />
2) Install [https://www.archlinux.org/packages/core/x86_64/keyutils/ keyutils] and [https://www.archlinux.org/packages/community/x86_64/ecryptfs-utils/ ecryptfs-utils] from the official Repos.<br />
<br />
'''[Do the following steps as root!]'''<br />
<br />
3) Make a "ecryptfs" Group:<br />
groupadd ecryptfs<br />
4) Add the user to it:<br />
usermod -aG ecryptfs user<br />
5) Load the ecryptfs module<br />
modprobe ecryptfs<br />
6) Change your /etc/pam.d/system-auth to look something like this (lines to add are bold):<br />
#%PAM-1.0<br />
<br />
auth required pam_env.so<br />
auth required pam_unix.so try_first_pass nullok<br />
'''auth required pam_ecryptfs.so unwrap'''<br />
auth optional pam_permit.so<br />
<br />
account required pam_unix.so<br />
account optional pam_permit.so<br />
account required pam_time.so<br />
<br />
'''password required pam_ecryptfs.so'''<br />
password required pam_unix.so try_first_pass nullok sha512 shadow<br />
password optional pam_permit.so<br />
<br />
'''session required pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
session required pam_env.so<br />
session required pam_unix.so<br />
session optional pam_permit.so<br />
<br />
<br />
6a) When using [[GDM]] < 3.2 to log in, edit /etc/pam.d/gdm like this:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6b) For [[GDM]] >= 3.2, make the following changes to /etc/pam.d/gdm-password (thanks to grawity for [https://bbs.archlinux.org/viewtopic.php?pid=998061#p998061 this]):<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth requisite pam_unix.so nullok<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
auth sufficient pam_succeed_if.so uid >= 1000 quiet<br />
auth required pam_deny.so<br />
account required pam_unix.so<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
session required pam_loginuid.so<br />
-session optional pam_systemd.so<br />
session optional pam_keyinit.so '''force''' revoke<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
6c) For [[KDM]], make the following changes to /etc/pam.d/kde:<br />
<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_nologin.so<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
<br />
6d) For [[LXDM]], make the following changes to /etc/pam.d/lxdm:<br />
<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6e) For [[LightDM]], make the following changes to /etc/pam.d/lightdm<br />
<br />
#%PAM-1.0<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
<br />
7) To be able to automatically mount your encrypted home directory on login using SSH, edit /etc/pam.d/sshd:<br />
#%PAM-1.0<br />
#auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_env.so<br />
account required pam_nologin.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password required pam_unix.so<br />
password optional pam_ecryptfs.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
session optional pam_ck_connector.so nox11<br />
<br />
8) Using Ubuntu defaults<br />
<br />
There's a method to automatically setup your HOME with AES and a 16 byte key. You could execute (it can take some while, it automatically encrypts your home files)<br />
ecryptfs-migrate-home -u user<br />
<br />
...and follow the on screen instructions (Delete backup afterwards (/home/user.XXXXX) / Record the passphrase generated by ecryptfs -> ecryptfs-unwrap-passphrase / ...)<br />
<br />
9) Log in and check if everything worked correctly.<br />
<br />
This is a working solution and ecryptfs is exactly used as in Ubuntu (10.04/10.10) - and is easy to set up. <br />
Besides this, it has the advantage of auto-unmount at log-out, which shell profile files (ie. ~/.bash_logout) could have trouble doing, because there could still be open file-descriptors by the shell at the time of umount. To encrypt swap see: [[System_Encryption_with_LUKS#Encrypting_the_Swap_partition]] (some of the tools provided by ecryptfs, such as ecryptfs-setup-swap, only work in ubuntu).<br />
<br />
== ecryptfs-simple ==<br />
Use [http://xyne.archlinux.ca/projects/ecryptfs-simple/ ecryptfs-simple] if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in fstab, nor is it limited to hard-coded directories such as ~/.Private. The package is available in the [https://aur.archlinux.org/packages.php?ID=59612 AUR] and in [http://xyne.archlinux.ca/repos/ Xyne's repos].<br />
<br />
As the name implies, usage is simple:<br />
# simple mounting<br />
ecryptfs-simple /path/to/foo /path/to/bar<br />
<br />
# automatic mounting: prompts for options on the first mount of a directory then reloads them next time<br />
ecryptfs-simple -a /path/to/foo /path/to/bar<br />
<br />
# unmounting by source directory<br />
ecryptfs-simple -u /path/to/foo<br />
<br />
# unmounting by mountpoint<br />
ecryptfs-simple -u /path/to/bar</div>NorthAntrimhttps://wiki.archlinux.org/index.php?title=ECryptfs&diff=273183ECryptfs2013-08-30T11:47:56Z<p>NorthAntrim: </p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[fr:Encryption avec eCryptfs]]<br />
[[it:System Encryption with eCryptfs]]<br />
[[ru:System Encryption with eCryptfs]]<br />
{{Article summary start}}<br />
{{Article summary text|Setup and usage of eCryptfs}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary end}}<br />
<br />
This article describes basic usage of [https://launchpad.net/ecryptfs eCryptfs]. It guides you through the process of creating a private and secure encrypted directory within your ''$HOME'' directory, where you can store all your sensitive files and private data.<br />
<br />
In implementation eCryptfs differs from dm-crypt, which provides a ''block device encryption layer'', while eCryptfs is an actual file-system &ndash; a [http://en.wikipedia.org/wiki/Cryptographic_filesystems stacked cryptographic file system] to be exact. For comparison of the two you can refer to [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare this table ]. <br />
<br />
The summary is that it doesn't require special on-disk storage allocation effort, such as separate partitions, you can mount eCryptfs on top of any single directory to protect it. That includes e.g. your entire $HOME and network file systems (i.e. having encrypted NFS shares). All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. There are other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you can't protect your swap space with it (instead you can combine it with dm-crypt).<br />
<br />
For more details on how eCryptfs compares to other disk encryption solutions, see [[Disk Encryption#Comparison table]]. <br />
<br />
== Deficiencies ==<br />
<br />
eCyptfs does not handle [https://en.wikipedia.org/wiki/Sparse_file sparse files] well; this should be considered before encrypting large portions of the directory structure ($HOME, for example). For most intents and purposes this deficiency does not pose a problem. Using eCryptfs to encrypt sparse files, however, currently encrypts the entire allocated space of the sparse file, which, in the case of big files, can starve the system of resources. (This bug may be tracked [https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/431975 on Launchpad]). One popular and inadvisable application of eCryptfs is to encrypt a BitTorrent download location; this often requires eCryptfs to handle sparse files of 10 GB or more and may lead to intense disk starvation. A simple workaround is to place sparse files in an unencrypted '''.Public''' directory (as opposed to the standard eCryptfs '''.Private''' directory, explained below).<br />
<br />
=== Login password ===<br />
<br />
{{note|1= With {{pkg|shadow}} 4.1.4.3-3 ''sha512'' is the default for new passwords (see [https://bugs.archlinux.org/task/13591#comment85993 bug 13591] and corresponding [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shadow&id=98001501a8306ef5a0df55d1cffc048851894940 commit]).}}<br />
<br />
If you are encrypting your whole home, with auto-mounting you should use a strong password and consider changing the hash algorithm for ''/etc/shadow'' from '''md5''' to stronger ones like '''sha512/bcrypt''' that helps to protect your password against rainbow-table attacks. See https://wiki.archlinux.org/index.php/SHA_password_hashes for more information.<br />
<br />
== Basics ==<br />
eCryptfs is a part of Linux since version 2.6.19. But to work with it you will need the userspace tools provided by the package {{pkg|ecryptfs-utils}} available in the [[Official Repositories]].<br />
<br />
Once you have installed that package you can load the ecryptfs module and continue with the setup:<br />
# modprobe ecryptfs<br />
<br />
The ecryptfs-utils package is distributed with a few helper scripts which will help you with key management and similar tasks. Some were written to automate this whole process of setting up encrypted directories (''ecryptfs-setup-private'') or help you combine eCryptfs with dm-crypt to protect swap space (''ecryptfs-setup-swap''). Despite those scripts we will go trough the process manually so you get a better understanding of what is really being done.<br />
<br />
Before we say anything else it's advised that you check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.<br />
<br />
=== Setup (simple) ===<br />
<br />
As a user run<br />
ecryptfs-setup-private<br />
and follow the instructions.<br />
<br />
== Setup (migrating) ==<br />
<br />
If a user's home directory wasn't setup beforehand, you can migrate it.<br />
<br />
Ensure that the user you want to migrate owns no processes and is logged out. You also need to ensure that you have rsync installed then as root run:<br />
<br />
ecryptfs-migrate-home -u archey<br />
<br />
(replacing "archey" with your user) and follow the instructions. It is imperative that the user logs in ''before'' the next reboot.<br />
<br />
=== Setup (in detail) ===<br />
<br />
First create your private directories, in this example we will call them exactly that: Private<br />
$ su -<br />
# mkdir -m 700 /home/username/.Private<br />
# mkdir -m 500 /home/username/Private<br />
# chown username:username /home/username/{.Private,Private}<br />
<br />
Let's summarize<br />
* Actual encrypted data will be stored in ~/.Private directory (so-called ''lower'' directory)<br />
* While mounted, decrypted data will be available in ~/Private directory (so-called ''upper'' directory)<br />
** While not mounted nothing can be written to this directory<br />
** While mounted it has the same permissions as the lower directory<br />
<br />
eCryptfs can now be mounted on top of ~/Private.<br />
# mount -t ecryptfs /home/username/.Private /home/username/Private<br />
<br />
You will need to answer a few questions and provide a passphrase which should be used to mount this directory in the future. However you can also have different keys encrypting different data (more about this below). For convenience we will limit this guide to only one key and passphrase. Let's see an example:<br />
Key type: passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
Cipher: aes<br />
Key byte: 16<br />
Plaintext passtrough: no<br />
Filename encryption: no<br />
Add signature to cache: yes <br />
<br />
Let's summarize<br />
* The passphrase is your '''mount passphrase''' which will be salted, hashed and loaded into the kernel keyring.<br />
** In eCryptfs terms, this salted, hashed passphrase is your "file encryption key, encryption key", or '''fekek'''.<br />
* eCryptfs supports a few different ciphers (AES, blowfish, twofish...). You can read about them on Wikipedia.<br />
* Plaintext passtrough enables you to store and work with '''un-encrypted''' files stored in the lower directory.<br />
* Filename encryption is available since Linux 2.6.29<br />
** In eCryptfs terms the key used to protect filenames is known as "filename encryption key", or '''fnek'''.<br />
* The signature of the key(s) will be stored in {{ic|/root/.ecryptfs/sig-cache.txt}}.<br />
<br />
Since our later goal is to be able to mount without root privileges, we will now move the eCryptfs configuration directory to your own home and transfer the ownership to you:<br />
# mv /root/.ecryptfs /home/username<br />
# chown username:username /home/username/.ecryptfs<br />
<br />
Your setup is now complete and directory is mounted. You can place any file in the '''~/Private''' directory and it will get encrypted in '''~/.Private'''.<br />
<br />
Now copy a few files to your new private directory, and then un-mount it. If you inspect the files you will see that they are unreadable &ndash; encrypted. That was cool you say, but how do I get them back... and that brings us to:<br />
<br />
==== Extra Notes ====<br />
<br />
Above is detailed the simplest way to setup the mount point, but '''ecryptfs-setup-private''' runs through some extra steps.<br />
<br />
* The above '''mount passphrase''' is derived from the passphrase you type in. This is not considered very [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#pubkey-about secure], so the setup script grabs some characters from {{ic|/dev/random}} for safety:<br />
<br />
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g"<br />
<br />
* '''ecryptfs-setup-private''' also takes the resulting mount passphrase and wraps it with your login passphrase (pasword) and stores this in '''~/.ecryptfs/wrapped-passphrase'''. You can replicate this with: <br />
<br />
$ ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase <br />
Passphrase to wrap: <br />
Wrapping passphrase:<br />
<br />
=== Mounting (the hard way) ===<br />
Whenever you need your files available you can repeat the above mount procedure, using the same passphrase and options if you want to access your previously encrypted files or using a different passphrase (and possibly options) if for some reason you want to have different keys protecting different data (imagine having a publicly shared directory where different data is encrypted by different users, and their keys).<br />
<br />
In any case going trough those questions every time could be a bit tedious.<br />
<br />
One solution would be to create an entry in the '''{{ic|/etc/fstab}}''' file for this mount point:<br />
<br />
/home/user/.Private /home/user/Private ecryptfs [... user ... ecryptfs_sig=XY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0<br />
<br />
* You will notice that we defined the '''user''' option, it enables you to mount the directory as a user (if it does not works as a normal user, you may need to setuid mount.ecryptfs by running as root: ''chmod +s /sbin/mount.ecryptfs'')<br />
* Notice the '''ecryptfs_sig''' option, replace ''XY'' with your own key signature (as seen in the '''mtab''' line earlier and in {{ic|sig-cache.txt}})<br />
* If you enabled filename encryption then pass an additional mount option: '''ecryptfs_fnek_sig'''=''XY'', where ''XY'' is the same signature you provide with the '''ecryptfs_sig''' option.<br />
* Last option '''ecrypfs_unlink_sigs''' ensures that your keyring is cleared every time the directory is un-mounted<br />
<br />
Since your key was deleted from the kernel keyring when you un-mounted, in order to mount you need to insert it into the keyring again. You can use the '''ecryptfs-add-passphrase''' utility or the '''ecryptfs-manager''' to do it:<br />
<br />
When the key is inserted you can mount the directory: <br />
$ ecryptfs-add-passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
<br />
$ mount -i /home/username/Private<br />
<br />
You will notice that we used the '''{{Ic|-i}}''' option this time. It disables invoking the mount helper. Speaking of which, using {{Ic|-i}} by default mounts with: '''nosuid, noexec''' and '''nodev'''. If you want to have at least executable files in your private directory you can add the '''exec''' option to the fstab line.<br />
<br />
This would be a good place to mention the '''keyctl''' utility from the (earlier installed) ''keyutils'' package. It can be used for any advanced key management tasks. Following examples show how to list your keyring contents and how to clear them:<br />
$ keyctl list @u<br />
$ keyctl clear @u<br />
<br />
{{Note|However, one should remember that /etc/fstab is for system-wide partitions only and should not be used for user-specific mounts}}<br />
<br />
=== Auto-mounting (the easy way) ===<br />
A better way is to use PAM directly, see 'PAM MODULE' in:<br />
/usr/share/doc/ecryptfs-utils/README<br />
<br />
1. Check if '''~/.ecryptfs/auto-mount''' and '''~/.ecryptfs/wrapped-passphrase''' (these are automatically created by '''ecryptfs-setup-private''') exist.<br />
<br />
2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login.<br />
<br />
Open '''/etc/pam.d/system-auth''' and add this ''after'' the line containing '''auth required pam_unix.so [...]''':<br />
auth required pam_ecryptfs.so unwrap<br />
, then add this ''above'' the line containing '''password required pam_unix.so [...]''':<br />
password optional pam_ecryptfs.so<br />
, and this ''after'' the line '''session required pam_unix.so''':<br />
session optional pam_ecryptfs.so unwrap<br />
<br />
3. Relogin (you need to type the user's password for obvious reason ;) and check output of '''mount''' which should now contain a mountpoint, e.g.:<br />
/home/$USER/.Private on /home/$USER/Private type ecryptfs (...)<br />
Your user's encrypted directory should be perfectly readable, e.g. $HOME/Private/<br />
<br />
Note that the latter will be automatically unmounted and made unavailable when the user log off.<br />
<br />
=== Usage ===<br />
Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Take ''Firefox'' for an example, not only does it have an internal password manager but the browsing history and cache can also be sensitive. Protecting it is easy:<br />
$ mv ~/.mozilla ~/Private/mozilla<br />
$ ln -s ~/Private/mozilla ~/.mozilla<br />
<br />
=== Removal ===<br />
If you want to move a file out of the private directory just move it to it's new destination while ~/Private is mounted. Also note that there are no special steps involved if you want to remove your private directory. Make sure it is un-mounted and delete ~/.Private, along with all the files.<br />
<br />
=== Backup ===<br />
Setup explained here separates the directory with encrypted data from the mount point, so the encrypted data is available for backup at any time. With an overlay mount (i.e. ''~/Secret'' mounted over ''~/Secret'') the lower, encrypted, data is harder to get to. Today when cronjobs and other automation software do automatic backups the risk of leaking your sensitive data is higher.<br />
<br />
We explained earlier that all cryptographic metadata is stored in the headers of files. You can easily do backups, or incremental backups, of your '''~/.Private''' directory, treating it like any other directory.<br />
<br />
== Advanced ==<br />
This wiki article covers only the basic setup of a private encrypted directory. There is however another article about eCryptfs on Arch Linux, which covers encryption of your entire $HOME and encrypting swap space without breaking hibernation (suspend to disk).<br />
<br />
That article includes many more steps (i.e. using PAM modules and automatic mounting) and the author was opposed to replicating it here, because there is just no single "right" way to do it. The author proposes some solutions and discusses the security implications, but they are his solutions and as such might not be the best nor are they endorsed by the eCryptfs project in any way.<br />
<br />
Article: [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html eCryptfs and $HOME] by Adrian C. (anrxc).<br />
<br />
Consider that ''Chromium OS'', as released by Google, is using eCryptfs to protect devices that are, and will be, powered by it. Some implementation details are available and they make excellent reading. You can read them [http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data here], they could help a lot as you're coming up with your own strategy.<br />
<br />
=== PAM Mount ===<br />
<br />
The above "''eCryptfs and $HOME''" article uses a shell init file to mount the home directory. The same can be done using [[pam_mount]] with the added benefit that home is un-mounted when all sessions are logged out. Add the following lines to {{ic|/etc/security/pam_mount.conf.xml}}:<br />
<br />
<luserconf name=".pam_mount.conf.xml" /><br />
<mntoptions require="" /> <!-- Default required mount options are ; this clears them --><br />
<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount> <!-- --><br />
<br />
Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters.<br />
Explanation:<br />
* the first line indicates where the user-based configuration file is located (here {{ic|~/.pam_mount.conf.xml}}) ;<br />
* the second line overwrites the default required mount options which are unnecessary ("nosuid,nodev") ;<br />
* the last line indicates which mount command to run (eCryptfs needs the {{Ic|-i}} switch).<br />
<br />
Then set the volume definition, preferably to {{ic|~/.pam_mount.conf.xml}}:<br />
<pam_mount><br />
<volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/><br />
</pam_mount><br />
<br />
"noroot" is needed because the encryption key will be added to the user's keyring<br />
<br />
Finally, edit {{ic|/etc/pam.d/login}} as described in [[pam_mount]]'s article.<br />
<br />
==== Optional step ====<br />
<br />
To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check ''pmvarrun'' to see the number of open sessions:<br />
#!/bin/sh<br />
#<br />
# /usr/local/bin/doecryptfs<br />
<br />
exit $(/usr/sbin/pmvarrun -u$PAM_USER -o0)<br />
<br />
With the following line added before the eCryptfs unwrap module in your PAM stack:<br />
auth [success=ignore default=1] pam_exec.so quiet /usr/local/bin/doecryptfs<br />
auth required pam_ecryptfs.so unwrap<br />
The article suggests adding these to {{ic|/etc/pam.d/login}}, but the changes will need to be added to all other places you login, such as {{ic|/etc/pam.d/kde}}.<br />
<br />
=== PAM mount by eCryptfs module ===<br />
To use the eCryptfs PAM module it self for mounting you should know it depends on some hard-coded Ubuntu defaults. Like using AES cipher with a 16 byte key. As described in this BBS post [https://bbs.archlinux.org/viewtopic.php?pid=727422#p727422] you have to do the following steps:<br />
<br />
1) For your understanding and preparation, read the guide mentioned above. [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html]<br />
<br />
2) Install [https://www.archlinux.org/packages/core/x86_64/keyutils/ keyutils] and [https://www.archlinux.org/packages/community/x86_64/ecryptfs-utils/ ecryptfs-utils] from the official Repos.<br />
<br />
'''[Do the following steps as root!]'''<br />
<br />
3) Make a "ecryptfs" Group:<br />
groupadd ecryptfs<br />
4) Add the user to it:<br />
usermod -aG ecryptfs user<br />
5) Load the ecryptfs module<br />
modprobe ecryptfs<br />
6) Change your /etc/pam.d/system-auth to look something like this (lines to add are bold):<br />
#%PAM-1.0<br />
<br />
auth required pam_env.so<br />
auth required pam_unix.so try_first_pass nullok<br />
'''auth required pam_ecryptfs.so unwrap'''<br />
auth optional pam_permit.so<br />
<br />
account required pam_unix.so<br />
account optional pam_permit.so<br />
account required pam_time.so<br />
<br />
'''password required pam_ecryptfs.so'''<br />
password required pam_unix.so try_first_pass nullok sha512 shadow<br />
password optional pam_permit.so<br />
<br />
'''session required pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
session required pam_env.so<br />
session required pam_unix.so<br />
session optional pam_permit.so<br />
<br />
<br />
6a) When using [[GDM]] < 3.2 to log in, edit /etc/pam.d/gdm like this:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6b) For [[GDM]] >= 3.2, make the following changes to /etc/pam.d/gdm-password (thanks to grawity for [https://bbs.archlinux.org/viewtopic.php?pid=998061#p998061 this]):<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth requisite pam_unix.so nullok<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
auth sufficient pam_succeed_if.so uid >= 1000 quiet<br />
auth required pam_deny.so<br />
account required pam_unix.so<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
session required pam_loginuid.so<br />
-session optional pam_systemd.so<br />
session optional pam_keyinit.so '''force''' revoke<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
6c) For [[KDM]], make the following changes to /etc/pam.d/kde:<br />
<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_nologin.so<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
<br />
6d) For [[LXDM]], make the following changes to /etc/pam.d/lxdm:<br />
<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6e) For [[LightDM]], make the following changes to /etc/pam.d/lightdm<br />
<br />
#%PAM-1.0<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
<br />
7) To be able to automatically mount your encrypted home directory on login using SSH, edit /etc/pam.d/sshd:<br />
#%PAM-1.0<br />
#auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_env.so<br />
account required pam_nologin.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password required pam_unix.so<br />
password optional pam_ecryptfs.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
session optional pam_ck_connector.so nox11<br />
<br />
8) Using Ubuntu defaults<br />
<br />
There's a method to automatically setup your HOME with AES and a 16 byte key. You could execute (it can take some while, it automatically encrypts your home files)<br />
ecryptfs-migrate-home -u user<br />
<br />
...and follow the on screen instructions (Delete backup afterwards (/home/user.XXXXX) / Record the passphrase generated by ecryptfs -> ecryptfs-unwrap-passphrase / ...)<br />
<br />
9) Log in and check if everything worked correctly.<br />
<br />
This is a working solution and ecryptfs is exactly used as in Ubuntu (10.04/10.10) - and is easy to set up. <br />
Besides this, it has the advantage of auto-unmount at log-out, which shell profile files (ie. ~/.bash_logout) could have trouble doing, because there could still be open file-descriptors by the shell at the time of umount. To encrypt swap see: [[System_Encryption_with_LUKS#Encrypting_the_Swap_partition]] (some of the tools provided by ecryptfs, such as ecryptfs-setup-swap, only work in ubuntu).<br />
<br />
== ecryptfs-simple ==<br />
Use [http://xyne.archlinux.ca/projects/ecryptfs-simple/ ecryptfs-simple] if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in fstab, nor is it limited to hard-coded directories such as ~/.Private. The package is available in the [https://aur.archlinux.org/packages.php?ID=59612 AUR] and in [http://xyne.archlinux.ca/repos/ Xyne's repos].<br />
<br />
As the name implies, usage is simple:<br />
# simple mounting<br />
ecryptfs-simple /path/to/foo /path/to/bar<br />
<br />
# automatic mounting: prompts for options on the first mount of a directory then reloads them next time<br />
ecryptfs-simple -a /path/to/foo /path/to/bar<br />
<br />
# unmounting by source directory<br />
ecryptfs-simple -u /path/to/foo<br />
<br />
# unmounting by mountpoint<br />
ecryptfs-simple -u /path/to/bar</div>NorthAntrim