Translated using DeepL

Machine-translated page for increased accessibility for English questioners.

Accessing disks on your own machine

You can access the Unix home directory /home/login and the /data/login directory on your own or another machine in several ways - via Samba (CIFS), NFS, or SSHFS. Autofs can be used to simplify mounting. In the section on Samba, you will also find a way to mount the Windows home directory.

The tutorials below are targeted at Unix OSes. If you want to access your home directory on a Windows OS machine, the necessary procedure can be found here.

General information

The commands mount and umount are used for mounting and unmounting, for example, see the man pages for more information about them. The directory where you want to access the remote directory is called mountpoint. The mountpoint is not created by calling the mount command - it must exist beforehand (exception: Autofs can create it automatically). All mounted (mounted) directories can be displayed by using the mount command without parameters.

Samba (CIFS)

Access via Samba is only possible for machines on the FI network and allows access to the home directory or the /data/login directory. The Samba protocol is generally blocked on the Internet due to its frequent abuse. You need root access and the mount.cifs tool on your machine (for example, available under Debian in the cifs-utils package). Samba directory exports are allowed from staff/lab machines with a fixed faculty IP address, from classrooms, or from VPNs. Connection requires authentication credentials. For security reasons, it is best to store them in a file that only root can access, as it contains the faculty password in clear form. The file can be created at /etc/samba/fi_cred.conf, for example, set its access rights to 600 and its contents should be as follows:


The actual accessing of the home directory to /mnt/fi-home can be done with the command mount:

muj_stroj# mount -t cifs // /mnt/fi-home \
    -o uid=muj_login,gid=skup,credentials=/etc/samba/fi_cred.conf

The parameters uid and gid are the login and primary group on your machine (can be found by running the command id). Also, the above parameters can be placed in one line of the file /etc/fstab:

//    /mnt/fi-home    cifs
    uid=muj_login,gid=skup,credentials=/etc/samba/fi_cred.conf  0  0

and then just use the command to connect

muj_stroj# mount /mnt/fi-home

Disconnection can be done with the umount command:

muj_stroj# umount /mnt/fi-home

Accessing the /data/login directory will be done similarly, but the path to the remote directory will be of the form //

In case of problems with the Samba configuration, you can test the functionality of the connection using the smbclient command (in Debian, you can find it in the package of the same name). After a successful connection, you should see a prompt smb: \>

Connecting the home directory of Windows machines (H:)

The mount command can also be used to mount the home directory and faculty profile folder of Windows machines. Specify // as the remote directory or one of the Windows disks, for example:

mount -t cifs // /mnt/fi-win-home \
    -o uid=muj_login,gid=skup,credentials=/etc/samba/fi_cred.conf
Mounting the home directory on Linux stations

Mounting the home directory is also possible without superuser privileges thanks to GVFS, and thus also on Nymphs and Muses.

We mount our home directory and authenticate with the faculty password when prompted:

nymfe$ gio mount "smb://NTFI;$$USER"

This directory can then be accessed via the Unix file system:

nymfe$ cd /run/user/$UID/gvfs/smb-share*/profiles/$USER/
nymfe$ ls

Other Windows volumes can be accessed in a similar way; see the paths listed there.

When the session is finished, the directory will be unmounted automatically, or you can manually invoke the unmount with this command:

nymfe$ gio mount -u "smb://NTFI;$$USER"

This method of access is only available from Nymfe and Musa machines, not from Aisa.


NFS access is only available for machines on the FI network and allows access to the home directory and the /data/login directory. It is possible to connect to an NFS server unauthenticated or using a kerber ticket, which has different implications for setup and usage.

Unauthenticated connection

  • The NFS server trusts your computer to control access rights to remote files correctly and has users consistent with the server.
  • It requires that the UID and primary GID of the user you will be working under on your directory machine be the same as the UID and primary GID of the faculty Unix account.
  • The user (you) must enable the export in Faculty Administration (the change will take effect within two hours).
  • You can use legacy NFS3 (option vers=3), which supports access control using posix ACLs

Kerberized connection

  • Each request is authenticated with the user's kerber ticket, so the NFS server does not have to blindly trust clients that they are not impersonating anyone.
  • They don't have to match UIDs and GIDs; the NFS server knows which faculty account the requests belong to by the ticket and authenticates permissions accordingly.
  • Authenticating each request adds some overhead.
  • The user on the client machine needs a kerber ticket, so practically this method is only applicable where faculty login is already in place anyway.
  • If the directory being mounted is also used as the home directory on your machine, SSH key login will usually not work, since it is located in the home directory, which requires a kerber ticket that can only be accessed with a password.
  • It requires a version of NFS4, which posix ACLs do not work with.
  • Available automatically from all computers on the FI network.

In both cases, the user root is considered by the NFS server to be completely free of special privileges. Thus, he has access only to those files and directories to which everyone (more precisely, the subject "other") has access.

The mode does not need to be chosen explicitly, the client and the server agree on what they both support. If the user has export to machine enabled in the Faculty Administration, unauthenticated mode is preferred. Specific settings can be enforced by selecting sec=sys (unauthenticated mode) or sec=krb5(Kerberos).


You need root access on your machine and the mount.nfs tool (for example, under Debian, available in the nfs-common package). You can access the home directory at mountpoint /mnt/fi-home by using the mountcommand with the following options:

muj_stroj# mount -t nfs /mnt/fi-home \
    -o rw,noatime,soft,actimeo=30,sloppy,addr=
and for /data/login:
muj_stroj# mount -t nfs /mnt/fi-data \
    -o rw,noatime,soft,actimeo=30,sloppy,addr=

As a reminder, verifying the functionality of the connection by listing files needs to be done under the user, not under root, which has no special privileges over NFS.

These parameters can also be specified in the /etc/fstab file (see information in the section on Samba). Alternatively, the user option can be added to allow a normal user to mount/unmount the directory (if you want to run programs from the mountpoint, you need to add the exec option after the user option - the user option automatically disables it):	/mnt/fi-home    nfs
    rw,user,exec,noatime,soft,actimeo=30,sloppy,addr=  0  0


You need to have sshfs installed on your machine. Depending on the distribution, you may then need to add your account to a group that allows FUSE connections (see information below). This procedure can be used without any further restrictions; the only requirement is a functional login to a faculty machine (Aisa, Anxur, Nymfe, Musa, ...). You can mount any directory within your faculty home directory or the /data/login directory. For example, connecting a faculty directory /home/login/mail to the ~/fi-mail directory can be done as follows:

muj_stroj$ sshfs -o idmap=user ~/fi-mail

If this command results in an error accessing the file /etc/fuse.conf, you need to add the user to the fuse group, for example with the command muj_stroj# usermod muj_login -aG fuse).

Once connected, the sshfs command remains running in the background and secures access to remote files. Disconnection can be accomplished with the command fusermount:

muj_stroj$ fusermount -u ~/fi-mail


Autofs can ensure that a directory is mounted as needed when it is accessed, and then dismounted if not used for a certain period of time.

To install it, you need root access to the machine and the package autofs. After installation, you need to edit the contents of the files /etc/auto.master with the main autofs configuration and /etc/auto.home and /etc/ with the configuration for the machine with shared directories When mounting the home directory, add the line /etc/auto.master

/mnt/net   /etc/auto.home

and add a line to the newly created /etc/auto.home according to the protocol used, the content of which is derived from the fstab lines for that protocol:

# pro pripojovani pres Sambu

# pro pripojovani pres NFS

When mounting /data/login the path to the remote volume will be different: in case of Samba it will be //, in case of NFS

The contents of both lines are collapsed due to their length; the file must contain all parameters for each connection in a single line. Then you still need to reload the autofs configuration, for example with systemctl reload autofs or another command specific to your distribution, and autofs should be working.

The mountpoint to which the directory is automatically mounted must not exist. However, attempts to access it will cause it to be created and mounted as configured, i.e., when you access /mnt/net you will not see any directory in the listing of its contents, but the cd fi-home-smb command will succeed if configured correctly and the subsequent listing of contents will show the files in the remote directory. After a period of inactivity, the remote directory is disconnected and the mountpoint is deleted.

Possible problems

Mounting the remote directory to the file system causes the contents of the directory we are using as a mountpoint to be overlaid. The original directory still exists, but is simply not accessible until the remote directory is unmounted. However, programs that already have that directory or subdirectory open will see the original contents. Therefore, if you were at the mountpoint, mounted the remote directory and dumped its contents, seemingly nothing would change. In that case, switching to that directory again will help.

When mounting directories over a network, it is a good idea to be aware of the risk of losing network connectivity. In such a case, working with the mounted directory will of course cease. Also, programs that work with the contents of this directory may freeze (go into an uninterruptible sleep state; state D in the output of top ) and these programs may not respond to the SIGKILL signal ( kill -9). Also, directory unmounting for Samba and NFS using umount may fail. Sometimes this problem can be partially solved by a forced lazy disconnect: umount -lf; see the manual page for the umount command for more information.

It is also not a good idea to forcefully terminate a running sshfs, as it may not be possible to correctly unmount the mounted directory.