Host Configuration Guides

This section explains some host considerations when configuring storage to be used for persistent data. This only applies to volume map profiles.

Using NFS

For any multi server deployment we recommend using NFS for all Persistent data. Without a central file share across all Kasm Agents in the deployment each individual Kasm Agent would have different data stored. The user would get different data depending on which Kasm Agent they were launched to.

NFS Server Setup

• Install an NFS server on this host.

Ubuntu/DebianRHEL/Oracle

sudo apt-get update
sudo apt-get install -y nfs-kernel-server

• Create the folder to host the share.

  sudo mkdir /kasmdata
  sudo chown -R 1000:1000 /kasmdata/
  

• Add the entry to /etc/exports. In this example the IP of the NFS Client is 192.168.1.3. Note the use of all_squash, anonuid, and anongid settings to ensure that all files are accessed and written as the default Kasm session UID 1000. See https://linux.die.net/man/5/exports for more details.

  /kasmdata       192.168.1.3(rw,sync,all_squash,anonuid=1000,anongid=1000,no_subtree_check)
  

• Expose the new additions defined in the exports.

  sudo exportfs -ar
  

NFS Client Setup

• Install an NFS client on this host.

Ubuntu/DebianRHEL/Oracle

sudo apt-get update
sudo apt-get install -y nfs-common

• Create a directory for the mount.

  sudo mkdir -p /mnt/kasm-nfs
  

• Add an entry to `/etc/fstab for the NFS mount. In this example the IP of the NFS Server is 192.168.1.2

  192.168.1.2:/kasmdata /mnt/kasm-nfs nfs defaults 0 0
  

• Mount the share.

  sudo mount /mnt/kasm-nfs
  

• Test creating a file.

  sudo touch /mnt/kasm-nfs/example.txt
  

• Inspect the file from the NFS Server to ensure the permissions are UID/GID 1000.

  ls -la /kasmdata/
  total 8
  drwxr-xr-x  2 1000 1000 4096 Feb 24 08:39 .
  drwxr-xr-x 20 root root 4096 Feb 23 16:00 ..
  -rw-r--r--  1 1000 1000    0 Feb 24 08:39 example.txt
  

• You can now reference the NFS share in volume mappings or persistent profile configurations. In this example we are configuring a shared directory for all users that have access to this Workspace available at the path /share to them using a volume mapping. Please see the Volume Mapping Documentation for more information.

  {
     "/mnt/kasm-nfs":{
        "bind":"/share",
        "mode":"rw",
        "uid": 1000,
        "gid": 1000,
        "required": true,
        "skip_check": false
     }
  }
  

File Permissions and Isolation

By default users inside of Kasm Workspaces sessions will run under the Linux UID and GID of 1000. What this means is that when creating persistent data paths it is important to understand that if exposed one user will have the same access to the other users files and vice versa. This becomes particularly important when using volume mappings. If mapping in a non user scoped directory IE /mnt/kasm/ and continuing to use that path for user scoped directories IE /mnt/kasm/desktop/{username} anyone with access to the Workspace with the initial /mnt/kasm volume mapping will also have read and write access to all of the other users storage in /mnt/kasm/desktop/. Also because of this one user design it means that Administrators can limit access to specific files by modifying their owner and file permissions host level.

In this example we will create a read only folder inside of the volume mapping. Lets say you would like to have a universal share folder where users can save/load/delete files in this directory this directory host level is /mnt/kasm_share mounted into the launched Workspaces sessions as /share/. On the host with access to /mnt/kasm_share we create the folder we want to be read only and place files/folder into it.

mkdir /mnt/kasm_share/read_only_documents
cp -ax /my_data/documents/* /mnt/kasm_share/read_only_documents/

Then we modify the user that owns this directory and the permissions: (in this example we use root but any user outside of 1000:1000 will work)

sudo chown root:root /mnt/kasm_share/read_only_documents/
sudo chmod -R 664 /mnt/kasm_share/read_only_documents/

The user will be able to open and copy the files in this directory, but will not be able to make modifications from inside their Workspaces session:

default:~$ rm /share/read_only_documents/test.doc 
rm: remove write-protected regular empty file '/share/read_only_documents/test.doc'? y
rm: cannot remove '/share/read_only_documents/test.doc': Permission denied
default:~$ cp /share/read_only_documents/test.doc /home/kasm-user/Desktop/
default:~$ ls -l /home/kasm-user/Desktop/test.doc 
-rw-r--r-- 1 kasm-user kasm-user 0 Jan 26 20:49 /home/kasm-user/Desktop/test.doc

This is just a simple example Linux user and file permissions are a bit more complex than that. In this case we are setting the owner to root and then telling the filesystem:

• First Number 6- Anyone that is the root user has read and write access.

• Second Number 6- Anyone that belongs to the group root has read and write access.

• Third Number 4- Anyone else only has read access.

Please review this infographic for a better explanation:

Linux File/Folder Permissions