Automatically mount a network drive when freebsd boots. File system

Youtube

Home > Operating systems > UNIX > BSD > FreeBSD

Add a hard drive to FreeBSD in 5 minutes

I often draw attention to the fact that simple questions are often poorly covered on the Internet. This is probably because all the gurus are sure that no one will ever ask such stupid questions, because everyone knows this. But my practice has shown that it is these small simple questions that are the most common not only among beginners, but also among serious administrators who simply have not had to deal with this. Even serious administrators do not do this every day, but, in order not to forget, they keep some kind of cheat sheet for themselves, without admitting it to anyone. Let's fix everything. Now you will learn how to add a hard drive to FreeBSD in 5 minutes. So. First, complete instructions will be given to understand the process, and at the end there will be a short list of actions, which will only contain a list of commands as a cheat sheet.

Detailed instructions with explanations

Selecting a hard drive name

First we need to determine the name of the device we just added. The following command will help us with this:

Geom disk list

Or this command:

Camcontrol devlist

In a real system, these commands will show more useful information, namely device names and serial numbers.

Before installing the new device, we knew that our system was installed on ada0, which means, logically, our new drive is ada1. You can determine this by the name of the new device, its serial number or volume.

Now let's check if there is marking on our new disk

Gpart show ada1

The disk does not have any markings.

Removing existing markup

If the disk has already been used and there is a need to remove markings from it, simply run:

Gpart destroy -F ada1

Creating GPT markup

First, we must create a disk partition. I highly recommend forgetting about MBR and switching to a new, more convenient and functional one - GPT.

We create GPT markup on the disk, then check what happens:

Gpart create -s gpt /dev/ada1 gpart show ada1

Now our disk has GPT markup. From the output you can see that absolutely the entire disk, starting from LBA 34 and ending with LBA 8388541, is empty. LBA 0-33 - reserved by the system for the partition table.

Let's say we need to create two partitions on this disk:

swap- swap partition
data- a section of the ufs type for storing any data we need.

Creating sections (slices)

If the installation is carried out on modern hard drives with a sector size of 4 KB, then alignment must be used when creating partitions. You can do it in two ways:
1) if we specify the section parameters in blocks, then enter the block number as a multiple of 8, for example: -b 40;
2) if we indicate the size of the partition in bytes, or do not indicate the beginning and size at all, use the parameter -a 4k, which will adjust the beginning and end of the section to sectors of 4 kb in size. Since in this example we are performing a test installation on a virtual hard disk, we don’t have to do this. In any case, before creating partitions, you need to know exactly the sector size of your drive, otherwise it will result in terrible work slowdowns.

Now let's create the partitions. To do this, there is a gpart add command with various parameters. First parameter -t- indicates the type of file system being created. In our case, two types will be used: freebsd-swap and freebsd-ufs. Next are two optional parameters: -b- indicates the LBA number from which the partition needs to be created. If you do not specify this parameter, the partition will be created automatically from the first free LBA. -s- indicates the size of the partition in the LBA. Size of one LBA block = 512 bytes. It is advisable to indicate in the number of LBA blocks, but it is also possible in kilo/mega/giga/… bytes (suffix k/M/G). If you do not specify this parameter, the partition will be created to the maximum possible LBA within the empty area. You can also specify the section label as a parameter, for example: -l swap1- in this case, the label /dev/gpt/swap1 will be created, which can be used to more conveniently access the partition. The last required parameter is the path to the disk. In our case: /dev/ada1.

Let's create two partitions and then see what we have. We will create the first partition without specifying the initial LBA, but specifying the size of 1 GB (2097152 blocks). We will create the second partition without specifying the initial LBA and without specifying the size - thus it will be created on the entire free space.

Gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1 gpart show ada1

The size can be specified in bytes rather than blocks. It's much more convenient. The only negative is that the system cannot always correctly calculate the number of blocks. There may be cases when a certain number of blocks will remain empty on the disk when specifying the partition size in bytes.

Creating a file system (formatting)

There is no need to format swap partitions. But partitions like ufs must be formatted before use. It would be more correct to say: a file system should be created on them.

In order to create a file system on the second partition, just run the following command:

Newfs -U /dev/ada1p2

In this case, the -U parameter was used - it indicates that the Soft Updates mechanism should be used in this file system. You can omit this option to avoid enabling this mechanism.

Mounting

The next step is to mount the partitions. First, so as not to forget, let's add our new sections to /etc/fstab. My file after editing looks like this:

In order to remount all partitions according to the /etc/fstab file, simply run the command:

Mount -a

As you can see from the output, the /dev/ada1p2 partition is mounted. Now let's see what happened to the SWAP section. Let's run the command:

As you can see, the new SWAP partition is not mounted. In order for SWAP to be mounted, you need to enable it with a special command:

Swapon /dev/ada1p1

In the same way, using the swapoff command, you need to disable the SWAP partition before performing any actions on it.

This completes all steps to add a new hard drive to the system.

Brief instructions

Given: hard drive /dev/ada1

Target: Delete the existing partition, create a new GPT partition, create two partitions: swap and data and connect them to the working system.

After each action, do gpart show to observe the result. Sequencing:

Remove existing markup:
gpart destroy -F ada1
Create new markup:
gpart create -s gpt /dev/ada1
Create two partitions: swap and data:
gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1
Create a file system UFSv2 on the second section:
newfs -U /dev/ada1p2
Add lines to the /etc/fstab file for automounting at boot:
/dev/ada1p1 none swap sw 0 0 /dev/ada1p2 /mnt ufs rw 2 2
Mount a new partition (the command mounts all partitions from the /etc/fstab file):
mount -a
Enable the new swap partition with the command:
swapon /dev/ada1p1 Material taken from the site:

I often draw attention to the fact that simple questions are often poorly covered on the Internet. This is probably because all the gurus are sure that no one will ever ask such stupid questions, because everyone knows this. But my practice has shown that it is precisely these small simple questions that are the most common not only among beginners, but also among serious administrators who simply have not had to deal with this. Even serious administrators do not do this every day, but, in order not to forget, they keep some kind of cheat sheet for themselves, without admitting it to anyone. Let's fix everything. Now you will learn how to add a hard drive to FreeBSD in 5 minutes. So. First, complete instructions will be given to understand the process, and at the end there will be a short list of actions, which will only contain a list of commands as a cheat sheet.

Detailed instructions with explanations

Selecting a hard drive name

First we need to determine the name of the device we just added. The following command will help us with this:

Geom disk list

Or this command:

Camcontrol devlist

In a real system, these commands will show more useful information, namely device names and serial numbers.

Now let's check if there is marking on our new disk

Gpart show ada1

The disk does not have any markings.

Removing existing markup

If the disk has already been used and there is a need to remove markings from it, simply run:

Gpart destroy -F ada1

Creating GPT markup

First, we must create a disk partition. I highly recommend forgetting about MBR and switching to a new, more convenient and functional one - GPT.

We create GPT markup on the disk, then check what happens:

Gpart create -s gpt /dev/ada1 gpart show ada1

Now our disk has GPT markup. From the output you can see that absolutely the entire disk, starting from LBA 34 and ending with LBA 8388541, is empty. LBA 0−33 - reserved by the system for the partition table.

Let's say we need to create two partitions on this disk:

swap- swap partition
data- a section of the ufs type for storing any data we need.

Creating sections (slices)

If the installation is carried out on modern hard drives with a sector size of 4 KB, then alignment must be used when creating partitions. You can do this in two ways: 1) if we specify the section parameters in blocks, then enter the block number as a multiple of 8, for example: -b 40; 2) if we indicate the size of the partition in bytes, or do not indicate the beginning and size at all, use the parameter -a 4k, which will adjust the beginning and end of the section to sectors of 4 kb in size. Since in this example we are performing a test installation on a virtual hard disk, we don’t have to do this. In any case, before creating partitions, you need to know exactly the sector size of your drive, otherwise it will result in terrible work slowdowns.

Gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1 gpart show ada1

Creating a file system (formatting)

There is no need to format swap partitions. But partitions like ufs must be formatted before use. It would be more correct to say: a file system should be created on them.

In order to create a file system on the second partition, just run the following command:

Newfs -U /dev/ada1p2

In this case, the -U parameter was used - it indicates that the Soft Updates mechanism should be used in this file system. You can omit this option to avoid enabling this mechanism.

Mounting

The next step is to mount the partitions. First, so as not to forget, let's add our new sections to /etc/fstab. My file after editing looks like this:

In order to remount all partitions according to the /etc/fstab file, simply run the command:

Mount -a

As you can see from the output, the /dev/ada1p2 partition is mounted. Now let's see what happened to the SWAP section. Let's run the command:

As you can see, the new SWAP partition is not mounted. In order for SWAP to be mounted, you need to enable it with a special command:

Swapon /dev/ada1p1

In the same way, using the swapoff command, you need to disable the SWAP partition before performing any actions on it.

This completes all steps to add a new hard drive to the system.

Brief instructions

Given: hard drive /dev/ada1

Target: Delete the existing partition, create a new GPT partition, create two partitions: swap and data and connect them to the working system.

After each action, do gpart show to observe the result. Sequencing:

Remove existing partition: gpart destroy -F ada1
Create a new partition: gpart create -s gpt /dev/ada1
Create two partitions: swap and data: gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1
Create a file system UFSv2 on the second partition: newfs -U /dev/ada1p2
Add lines to the /etc/fstab file for automounting at boot: /dev/ada1p1 none swap sw 0 0 /dev/ada1p2 /mnt ufs rw 2 2
Mount a new partition (the command mounts all partitions from the /etc/fstab file): mount -a
Enable the new swap partition with the command: swapon /dev/ada1p1

This completes the setup.

Preparing disk space for use does not end with creating partitions and file systems on them. All created file systems must also be made available to FreeBSD. Why should they be mounted - that is, included in a single hierarchy of directories and files, which is also designated by the name of the file system. However, if earlier we were talking about the physical organization of data, now it’s time to get acquainted with its logic.

File system logic

Logically, the FreeBSD file system (like any Unix system) is organized according to a tree principle: at its base is the root (the root directory, denoted by the symbol / and also called the root directory; the latter should not be confused with the / root directory, which serves as the home directory for superuser).

From the root directory, which can be more like a tree trunk, there are branches - subdirectories nested in it, and shoots - ordinary files. The latter, however, are few: in FreeBSD versions this is a certain entropy file (/entropy) and a file describing the copyright of the system /COPYRIGHT.

But there are quite a lot of subdirectories in the root directory, and some of them are arranged very complexly inside, containing a fair number of nested subdirectories of deeper levels.

In principle, the directory hierarchy in all Unix systems is similar, since it is regulated, firstly, by a long-standing tradition, and secondly, by all kinds of standardizing documents, in particular, FHS (Filesystem Hierarchy Standard), which is now available in Russian translation (for which thanks Viktor Kostromin).

The FHS standard was originally developed to organize the directory structure of numerous Linux distributions. And only later it was adapted for other Unix-like systems (including the BSD clan). However, it is the FreeBSD directory hierarchy that can serve as an example for exemplary adherence to the spirit of the FHS. And literally individual deviations in it from its letter are always functionally determined.

The FHS standard rests on two fundamental principles - a clear separation in the file hierarchy of shared and non-shared directories, on the one hand, and immutable and mutable, on the other.

The contrast between shared and non-shared directories is due to the inherent network nature of Unix in general and FreeBSD in particular. That is, data related to the local machine (for example, configuration files for its devices) should be located in directories separate from those whose contents are accessible from other machines on the network, local or global (an example of which is not only user data, but also programs) .

The essence of the contrast between immutable and mutable directories can be easily explained with an example. Thus, the same user programs must, by their nature, be unchangeable (or rather, available for modification only to the system administrator, but not to the user himself who uses them in his work). At the same time, these programs, during their operation, generate not only data files, say, texts or images (their variable nature is clear without comment), but all kinds of service information, such as log files, temporary files, and the like). Which should be grouped in directories separated from the actual executable files of programs, libraries, configuration files, etc., necessary for their launch.

Strict adherence to the concept of separating shared and non-shared, immutable and immutable directories from each other allows, within a single tree-like file hierarchy, to isolate its individual branches physically - that is, in the form of independent file systems located on isolated devices (disks, disk slices, partitions; in the general case - and on remote, network-connected media, but this will not be discussed now). There are many reasons for this - increasing speed, increasing reliability, and simply considerations of convenience - but we won’t talk about them now. Because now all that matters to us is that these branches of the file tree must be incorporated into the overall file system.

In Unix systems, every file (including a directory) is recognized by the system not by its name, but by the unique identifier of its entry in the table inodes. There are tools to view these file IDs. One is the ls command with the -i option, which will print the IDs of each named file. Given for the root directory -

$ ls -i /

it will show us a somewhat unexpected picture (to simplify the output, information about regular files and symbolic links in the root is excluded from the output, and the remaining directories are sorted by their identifiers):

2 ../ 2 ./ 2 dev/ 2 home/ 2 tmp/ 2 usr/ 2 var/ 3 cdrom/ 4 mnt/ 5 root/ 8257 dist/ 8258 bin/ 8294 proc/ 8295 sbin/ 16512 stand/ 24768 etc/ 24776 boot/

From this example (relating to the file system of the machine on which these lines are written) it is clear that as many as 7 directories have the same digital identifiers, equal to 2. The question is, what is the uniqueness here?

The first two elements of the list are easy to understand: ./ represents the current directory (in this case, the root), and ../ is the parent directory of the current one; and since, by definition, there is nothing above the root in the file hierarchy, the latter denotes itself. So it is not surprising that ./ and ../ have the same identifier - they are different designations (hard links, or, in other words, duplicate names) for the same, root, directory.

But the same, as it seems at first glance, the meaning of the identifier for the /dev, /home, /tmp, /usr, /var directories requires explanation. However, it is simple: all of these are directories in which independent file systems are mounted, either located on separate devices - disk partitions, such as the /home, /usr, /var directories, or virtual file systems that do not build on any real disk device ( the /dev directory with the device file system and, in this case, the /tmp directory, in which the file system in RAM is mounted, which will be discussed later). And since the table inodes- different for each file system, it is not surprising that the root of each of them is identified by the number 2 - numbering inodes in them goes in its own frame of reference.

So, mounting is the inclusion of a file from the system in any of the directories existing in the root system (not necessarily directly in the root, it can be of any degree of nesting, which is illustrated below). Without this, the directories and files of such a mounted system are simply inaccessible. This is important to understand when you come across expressions like "create the /usr filesystem". From the above, it is obvious that what is being created (by the newfs command) is simply some kind of abstract file system, and it acquires its “name” only at the moment of mounting it in the specified directory.

It is interesting that the directory identifier for mounting (also called the mount point) is found only at the time of mounting. To verify this, let's conduct a simple experiment. In the /mnt directory, intended specifically for mounting temporarily mounted file systems), you can see three subdirectories - /mnt/disk, mnt/iso, /mnt/usb (this is on my system, I created them for my own convenience; initially the /mnt directory was in FreeBSD is empty). When the system starts, nothing is mounted in them, and their usual state is to be empty. If you look at their identifiers, you can see something like this:

$ ls -i /mnt 18 disk/ 24 iso/ 19 usb/

Now let’s take and mount a flash drive with a USB interface into /mnt/usb (this is exactly what I intended it for) and repeat the viewing. And we see:

18 disk/ 24 iso/ 2 usb/

That is, the identifiers of the directories that remained empty (/mnt/disk and /mnt/iso) did not change, but the directory identifier /mnt/usb magically changed to 2. Because at the moment of mounting it became the root for its own file system and the reference point for calculus inodes all files recorded on it.

Let's digress a little and remember about hard links, through which the same inode and the data blocks associated with it can be given different names. Now it’s clear why all such duplicate files should be located in the same file system: after all, different file systems have their own, non-matching numbering inodes, and it is impossible to identify them by numbers (otherwise how would the system distinguish between the /usr and /var directories from our example - after all, it doesn’t care about file names). For symbolic links that have their own inode(in fact, almost nothing except them) with their identifiers, numbered in the reference frame of the file system in which they are located, there is no such restriction. And symbolic links can be located anywhere (including on a remote machine - not just on another partition).

Let's return, however, to the example of our root directory. From everything considered, it is clear that a number of its branches lie on separate partitions and form their own file systems (in fact, this is exactly why we created both of them). And, therefore, they all need to be mounted.

Mounting practice

However, the process of mounting the root file system is as inevitable as the victory of socialism on a global scale: just as socialism, without winning on a global scale, simply loses the ability to exist (which we recently observed), so can an OS exist without a root system can not. In Linux, this causes kernel panic mode - approximately the state into which our leaders fell about 20 years ago. True, they turned out to be stronger than Linux and recovered quite quickly - so they are still rebooting us (or rebooting? - but we are getting stronger :)). However, this does not apply to the installation matter that I will try to present to you now.

So, to mount all file systems except the root one, you need to take some steps. First we'll look at how to do them manually, and then how to immortalize them in the appropriate configuration files.

So, the mount command. Actually, this is a whole family of programs, each of which is designed to mount file systems of certain types - not only UFS, but any of those supported by FreeBSD. The list of these is quite extensive - you can get an idea about it by looking at the /sbin directory:

$ ls -1 /sbin/mount*

what will give us in response

/sbin/mount_cd9660* /sbin/mount_devfs* /sbin/mount_ext2fs* /sbin/mount_fdescfs* /sbin/mount_linprocfs* /sbin/mount_mfs* /sbin/mount_msdosfs* /sbin/mount_nfs* /sbin/mount_nfs4* /sbin/mount_ntfs* /sbin/mount_nullfs* /sbin/mount_procfs* /sbin/mount_std* /sbin/mount_udf* /sbin/mount_umapfs* /sbin/mount_unionfs*

Each command on this list is responsible for mounting a different type of file system, some of which we will return to later. For now, let’s only note /sbin/mount itself, designed to work with UFS and UFS2.

Called from the command line, it requires two arguments - the name of the device to be mounted and the mount point (that is, the directory into which the underlying file system should be mounted). The device name should indicate a patricia already mapped on an existing BSD slice with a UFS2 file system (UFS) created on it, for example,

$ mount /dev/ads0d /usr

mounts the file system on the specified partition in the /usr directory of the root of the file tree. If the file system on the device is not created or is of a type other than UFS/UFS2, an error message will appear indicating an incorrect super block: unlike the Linux utility of the same name, the FreeBSD mount command itself cannot recognize the file system type.

The following requirements are imposed on the mount point: a) a directory with the same name must exist at the time of mounting, and b) be as empty as possible. The first is a must, but the second is not entirely true. Mounting into a directory with any files will go smoothly (I remember that in Linux not so long ago this caused a system crash), but all its contents will become inaccessible until unmounted. And if the files it contains play a significant role for any subsystem, this can cause all sorts of bad consequences. For example, if the contents of the /tmp directory were blocked by mounting a file system there while the X window system was running, the result would likely be a crash of the X server. Fortunately, if necessary, you can perform a combined mount (see below).

In the specified form, mounting will be performed with some default characteristics: the file system will be read/write in the so-called mode. noasync (the same one in which metadata operations are performed synchronously, and data operations are performed asynchronously). This position can be changed using the values of the -o option. There are quite a few of them, but practically the main ones for us at this stage will be:

async - will provide a completely asynchronous mode (despite the dire warnings in previous posts, I will later talk about the situation when this may be justified);
sync - on the contrary, enabling a fully synchronous mode (though I don’t really understand why this is practically necessary);
noatime is a very useful option that prevents the file last access time attribute from being updated, which greatly improves performance;
rdonly - mounts the file system in read-only mode (sometimes this is necessary);
union is the same option that allows you to perform a union mount, in which the previous contents of the mount point directory remain visible; true - with some limitations - see man (8) mount .

There are several other values of the -o option that prohibit certain types of files from being placed on the mounted file system, for example, executable files (-o noexec), device files (-o nodev), or files with so-called. a bit of suicidity. However, they are of practical importance mainly for server administrators and serve security purposes. On a desktop machine, the usual form of mounting would be something like this:

$ mount -o noatime /dev/ads0d /usr; $ mount -o noatime /dev/ads0e /var; $ mount -o noatime /dev/ads0f /home

All of the above applies only to mounting FreeBSD file systems. However, in practice there is often a need to incorporate other types of file systems into its directory tree. This is especially often required for ISO9660 (the usual file system for all CDs except Mac ones) and FATs of various kinds. In this case, the appropriate mount command must be called explicitly, e.g.

$ mount_cd9660 /dev/acd0 /cdrom

for mounting a compact, or

$ mount_msdosfs /dev/ad## /mnt

for FAT of any kind (including FAT32). However, this can also be done indirectly by specifying the -t file_system_type option to the mount command. Thus, the command

$ mount -t ext2fs /dev/ad## /mnt/linux

mounts the Linux file system (if the corresponding feature is included in the kernel). In this case, the standard mount for BSD partitions is simply replaced by the /mount_ext2fs command, designed to mount ext2fs partitions (and ext3fs too - but, of course, without any journaling functions). That is, the form

$ mount -t fstype ... ...

will be the complete equivalent of the command

$mount_fstype ... ...

All operations for mounting file systems (including on removable media) in FreeBSD require superuser rights. The values of the -o option here, unlike the Linux version of the mount command, do not include the -o user parameter, which allows mounting to ordinary users. True, there are several ways to get around this, as discussed in a special note.

Setting up automatic mounting

However, in practice, manual mounting is resorted to only for rarely used file systems. All file systems that are fundamentally important for the functioning of FreeBSD are mounted automatically at system startup, and frequently used ones are mounted in a semi-automatic, so to speak, mode.

For automatic mounting, the mount program is run during the boot process from the initialization scripts. It looks for its configuration file - /etc/fstab, and mounts everything it finds in it, with some exceptions (discussed below).

The /etc/fstab file itself is generated automatically when FreeBSD is installed, including all the file systems necessary to support life. However, in the future it can be edited manually in order to add new devices for mounting or additional options for already enabled devices.

The /etc/fstab file is a simple database in text format (fields separated by spaces or tabs), including the following fields:

Device - the file name of the device on which the file system is located, similar to the first argument of the mount command when used manually;
Mountpoint - mount point (corresponds to the second argument of the mount command);
FStype - file system type, also specified as the value of the -t option;
Options - additional mounting options, similar to the values of the -o option;
Dump - conditions for performing a file system backup using the dump utility;
Pass# - conditions for checking the file system with the fsck utility.

In a freshly installed FreeBSD /etc/fstab will necessarily include the following entries (example for the 1st slice of the Master disk on the 1st IDE channel):

# Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1b none swap sw 0 0

If you follow the advice of reasonable people (and the defaults of sysinstall) and select some branches of the file system from the root, entries like

/dev/ad0s1d /var ufs rw 0 0 /dev/ad0s1e /usr ufs rw 0 0 /dev/ad0s1f /tmp ufs rw 0 0

/dev/ad0s1g /home ufs rw 0 0

responsible for the file system with user home directories.

Obviously, in the Options field you can add any available (and reasonable) values of the -o option (separated by commas, without spaces), for example, noatime for all file systems, and for /tmp - also async , because the contents of this directory are not supposed to saving after reboot.

The above applies to file systems that are mounted automatically at startup. However, no one bothers you to make entries in /etc/fstab for systems that are connected from time to time - in this case they can be mounted according to a simplified scheme (this is what I meant above by semi-automatic mode). So, for a CD drive you can add a line (in fact, it automatically appears when generating the /etc/fstab file if CD was selected as the installation source in sysinstall)

/dev/acd0 /cdrom cd9660 ro,noauto 0 0

in which the options, as you might guess, prescribe refusal to mount at startup (noauto) and read-only mode (ro). After which, to mount a CD, it will be enough to specify only the mount point -

$mount/cdrom

or. on the contrary, the device file name

$ mount /dev/acd0

Similar entries can be made for all removable drives (Zip, USB drives, even floppy disks) and for non-BSD partitions (FAT or Ext2fs). By the way, you can mount file systems using a simplified scheme immediately after making changes to /etc/fstab, without waiting for the machine to reboot.

Unmounting

All involved file systems must be unmounted before turning off the power or rebooting the machine. Upon graceful shutdown, this is done automatically, resulting in each writable file system receiving a clean unmount bit written in its own superblock. The presence of this bit prevents the fsck utility from checking file systems for consistency the next time the system is started.

However, in a number of cases (for example, when connecting or disconnecting the Soft Updates mechanism or to perform an integrity check), it becomes necessary to manually unmount (and remount) file systems, for which the umount command is used. It requires a single argument - specifying the mount point of the file system "removed" from the directory tree, for example:

$umount/tmp

or, as in the case of semi-automatic mounting, the file name of the “shutdown” device:

$ umount /dev/ad#s#?

You can unmount multiple file systems with one line:

$ umount /usr /var /home

Or you can - all mounted file systems or all file systems listed in the /etc/fstab file (except the root), which will require options

$umount -A

$umount -a

respectively. It is also possible to unmount certain types of file systems by specifying the values of the -t option. Yes, team

$ umount -t ufs

will unmount only BSD partitions, without affecting the CD and everything else that is involved in the system.

File systems should not be in use at the time of unmounting, that is, there should be no access to the files located on them. So, being in any directory of a file system is a sufficient reason for refusing to unmount it (with a message like device busy), which is why none of the commands listed above will be able to unmount the root file system. The reason for refusing to unmount will be the reading of the data file by any program - as with deleting a file, the file descriptor opened by any process will not allow this.

However, you can also unmount the file system you are using - to do this, you will need to issue the umount command with the -f option (from force - that is, by force). True, this can lead to errors, so it is better not to resort to it unless absolutely necessary. And the forced unmount option will not have any effect on the root file system.

Bulk mount

To continue working after performing low-level operations on file systems, they will need to be mounted back. This can be done not only without rebooting, but also without tedious individual mounting. Just use the -a option:

$mount -a

through which all file systems for which there are entries in /etc/fstab will be mounted. In this case, an attempt will be made to mount those that are marked with the noauto flag. To avoid this, you can further define the file system type. That is, the team

$ mount -a -t ufs

will mount only BSD partitions, without encroaching on CDs or flash drives. Or, on the contrary, you can exclude from the global mounting process some of the file systems listed in /etc/fstab, for example, currently unnecessary FATs:

$ mount -a -t nomsdosfs

Preamble instead of conclusion

/dev/ad0s1a on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) /dev/ccd0e on /var (ufs, local, noatime, soft-updates) /dev/ccd1e on / usr (ufs, local, noatime, soft-updates) /dev/ccd2e on /home (ufs, local, noatime, soft-updates) /dev/md0 on /tmp (ufs, local, noatime, async)

The first line of output shows that the /dev/ad0s1a partition is mounted in our root directory, carries a UFS file system (specifically in this case - UFS2, but in the output of the mount command they do not differ) with the Soft Updates mechanism enabled, is local ( that is, located on the disk of this machine - network drives are also mounted with the mount command) and is not subject to updating the atime attribute.

$ more /etc/fstab /dev/ad0s1b none swap sw 0 0 /dev/ar0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw,noatime 1 1 /dev/ccd0e /var ufs rw,noatime 2 2 /dev/ ccd1e /usr ufs rw,noatime 2 2 /dev/ccd2e /home ufs rw,noatime 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1 /mnt/usb ext2fs rw,noauto,noatime 0 0 / dev/md0 /tmp mfs rw,noatime,async,-s32m 2 0

then we will see that one of the output lines

Devfs on /dev (devfs, local)

There is no correspondence at all among his records. What are these devices and file systems?

You can change the access rights and owner of files and directories in using the commands chmod And chown. The mask for setting rights to created files can be changed globally, in /etc/profile for Linux and /etc/login.conf for FreeBSD. Usually, the default mask 022 . Meaning umask subtracted from 777 , so permissions will matter 755 . exec - execution allowed read - read permission write - write permission SUID bit - the file attribute, in conjunction with the executable file attribute, allows the file to be executed to be executed with the effective UID of the file's owner, rather than the one running the file 1 --x execute # Permissions 764 = exec/read/write | read/write | read 2 -w- write # For: |-- Owner --| |-Group-| |Oth| 4 r-- read ugo=a u=user, g=group, o=others, a=everyone# chmod MODE[,MODE] FILE # MODE has the form: *([-+=]()) # chmod 640 /var/log/maillog # Set permissions to equal -rw-r----- # chmod u=rw,g=r,o= /var/log/maillog # Same as above # chmod -R o-r /home/* # Recursively change permissions, disallow reading for Other # chmod u+s /path/to/prog # Install SUID bit per executable file (be careful here, you must understand what you are doing)# find / -perm -u+s -print # Find all programs with installed SUID bit# chown user:group /path/to/file # Set the user and group as the owner of the file# chgrp group /path/to/file # Change the group that owns the file# chmod 640 `find ./ -type f -print` # Change permissions to 640 for all files# chmod 751 `find ./ -type d -print` # Change permissions to 751 for all directories

Disk Information

# diskinfo -v /dev/ad2 # View disk information ( sector/size) FreeBSD# hdparm -I /dev/sda # Information about IDE/ATA disk (Linux)# fdisk /dev/ad2 # Show change disk partitions# smartctl -a /dev/ad2 # Show SMART disk information

Loading

FreeBSD

To load the old kernel in an emergency situation, for example after an unsuccessful build and installation of a new one, stop the download by pressing 6 during the countdown to get to the command line prompt. # unload # load kernel.old # boot

Mount points, disk usage

#mount | column -t # Show mounted filesystems#df # Show the amount of free space and mounted devices# cat /proc/partitions # Show all registered partitions (Linux)

Directory information

# du -sh * # Directory sizes as a list# du -csh # Total volume of the current directory# du -ks * | sort -n -r # List of directories sorted by size in kilobytes# ls -lSr # List of directories, reverse sorting

Who opened which files

Sometimes it is necessary to find out which file has locked a partition, causing the command umount gives the corresponding error. # umount /home/ umount: unmount of /home # It is not possible to unmount a partition until /home blocked failed: Device busy

FreeBSD and most Unix-like systems

# fstat -f /home # for mount point# fstat -p PID # for application with PID# fstat -u user # for username Find open file for Xorg: # ps ax | grep Xorg | awk "(print $1)" 1252 # fstat -p 1252 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root Xorg 1252 root / 2 drwxr-xr-x 512 r root Xorg 1252 text /usr 216016 -rws-- x--x 1679848 r root Xorg 1252 0 /var 212042 -rw-r--r-- 56987 w Find file with inum 212042 in the directory /var you can do this: # find -x /var -inum 212042 /var/log/Xorg.0.log

Linux

Find an open file in a directory using fuser or lsof: # fuser -m /home # List of processes that have access to /home # lsof /home COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME tcsh 29029 eedcoba cwd DIR 0.18 12288 1048587 /home/eedcoba (guam:/home) lsof 29140 eedcoba cwd DIR 0.18 12288 1048587 /home/eedcoba (guam: /home) Find by PID applications: ps ax | grep Xorg | awk "(print $1)" 3324 # lsof -p 3324 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME Xorg 3324 root 0w REG 8.6 56296 12492 /var/log/Xorg.0.log By file name: # lsof /var /log/Xorg.0.log COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME Xorg 3324 root 0w REG 8.6 56296 12492 /var/log/Xorg.0.log

Mounting/remounting file systems

For example cdrom, registered in /etc/fstab: # mount /cdrom Or you can find the device in /dev or in output dmesg

FreeBSD

# mount -v -t cd9660 /dev/cd0c /mnt # Mount disk Cdrom(method one)# mount_cd9660 /dev/wcd0c /cdrom # Mount disk Cdrom(method two)# mount -v -t msdos /dev/fd0c /mnt # Floppy disk Write to /etc/fstab: # Device Mountpoint FStype Options Dump Pass# /dev/acd0 /cdrom cd9660 ro,noauto 0 0 Allow users to mount disks: # sysctl vfs.usermount=1 # Or enter the line "vfs.usermount=1" in /etc/sysctl.conf

Linux

# mount -t auto /dev/cdrom /mnt/cdrom # Typical disk mount command cdrom # mount /dev/hdc -t iso9660 -r /cdrom # Mount disk IDE # mount /dev/scd0 -t iso9660 -r /cdrom # Mount disk SCSI cdrom# mount /dev/sdc0 -t ntfs-3g /windows # Mount disk SCSI Sign up for /etc/fstab: /dev/cdrom /media/cdrom subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec 0 0

Mounting a FreeBSD partition with Linux

Look at the section number in fdisk, usually this is the root partition, but it can be on another BSD slice. If there are many slices on the FreeBSD partition, they will not be visible through fdisk, but they can be found in dev/sda* or /dev/hda*. # fdisk /dev/sda # Find the FreeBSD partition/dev/sda3 * 5357 7905 20474842+ a5 FreeBSD # mount -t ufs -o ufstype=ufs2,ro /dev/sda3 /mnt /dev/sda10 = /tmp; /dev/sda11 /usr # Another slice

Rewiring

Remount the device without first unmounting it, for example to fsck# mount -o remount,ro / # Linux # mount -o ro / # FreeBSD Copy data stream from CDROM"and to the file ISO image. # dd if=/dev/cd0c of=file.iso

Creating a swap partition on the fly

Suppose you need to increase the swap partition, say to 2 gigabyte, /swap2gb(for Linux) # dd if=/dev/zero of=/swap2gb bs=1024k count=2000 # mkswap /swap2gb # Create swap # swapon /swap2gb # Enable swap, now it can be used# swapoff /swap2gb # Disable swap # rm /swap2gb

Mounting an SMB partition

CIFS- Common Internet File System SMB- server message block Suppose you need to access a shared SMB section myshare on server smbserver, the address typed on a Windows machine will be \\smbserver\myshare\. We will mount it on /mnt/smbshare. Don't forget for cifs IP address or domain name required.

Linux

# smbclient -U user -I 192.168.16.229 -L //smbshare/ # List the shares # mount -t smbfs -o username=winuser //smbserver/myshare /mnt/smbshare # mount -t cifs -o username=winuser, password=winpwd //192.168.16.229/myshare /mnt/share Additionally package mount.cifs allows you to store privileges in a file, for example /home/user/.smb: username=winuser password=winpwd And now we mount: # mount -t cifs -o credentials=/home/user/.smb //192.168.16.229/myshare /mnt/smbshare

FreeBSD

Use the key -I to set the IP address (or DNS); smbserver, this is a Windows name. # smbutil view -I 192.168.16.229 //winuser@smbserver # List of shared resources# mount_smbfs -I 192.168.16.229 //winuser@smbserver/myshare /mnt/smbshare

Mount image

Linux loop-back

# mount -t iso9660 -o loop file.iso /mnt # Mount CD image# mount -t ext3 -o loop file.img /mnt # Mount image with file system ext3

FreeBSD

Using md- memory device (if necessary, make kldload md.ko): # mdconfig -a -t vnode -f file.iso -u 0 # mount -t cd9660 /dev/md0 /mnt # umount /mnt; mdconfig -d -u 0 # Clear memory device Or using a pseudo device( VN, Virtual node): # vnconfig /dev/vn0c file.iso; mount -t cd9660 /dev/vn0c /mnt # umount /mnt; vnconfig -u /dev/vn0c # Clear pseudo device

Creating and Burning an ISO Image

We will copy a CD or DVD sector by sector. # dd if=/dev/hdc of=/tmp/mycd.iso bs=2048 conv=notrunc Use mkisofs to create an image from a file in a directory. To overcome filename restrictions, use the option -r, including the extension RockRidge, basic for UNIX systems, -J includes Joliet, used by Microsoft, -L allows ISO9660 names starting with a dot. # mkisofs -J -L -r -V TITLE -o imagefile.iso /path/to/dir On FreeBSD, mkisofs can be installed from /usr/ports/sysutils/cdrtools.

Burning CD/DVD ISO images

FreeBSD

FreeBSD does not install DMA on ATAPI devices, this can be done through a variable sysctl or in a file /boot/loader.conf, the following entries. hw.ata.ata_dma="1" hw.ata.atapi_dma="1" Use burncd for ATAPI devices ( burncd, standard program, part of the base system) and cdrecord(from /usr/ports/sysutils/cdrtools) for SCSI devices. # burncd -f /dev/acd0 data imagefile.iso fixate # For ATAPI devices# cdrecord -scanbus # Find recorder # cdrecord dev=1,0,0 imagefile.iso

Linux

Use it the same way cdrecord, as described above. In addition, you can use the native ATAPI interface: # cdrecord dev=ATAPI -scanbus Record as described above.

dvd+rw-tools

The dvd+rw-tools package (FreeBSD: ports/sysutils/dvd+rw-tools) has all the functionality needed to work with DVDs, plus growisofs, for burning CD or DVD. Documentation with examples can be found in the FreeBSD handbook Chapter 18.7 # -dvd-compat closes the disk# growisofs -dvd-compat -Z /dev/dvd=imagefile.iso # Burn existing iso image# growisofs -dvd-compat -Z /dev/dvd -J -R /p/to/data # Write directly

Convert image from Nero .nrg file to .iso file

Nero adds a 300kb header to the image, which can be trimmed using dd. # dd bs=1k if=imagefile.nrg of=imagefile.iso skip=300

Convert bin/cue image to .iso

This can be done using a small program, bchunk. On FreeBSD it can be found in ports /usr/ports/sysutils/bchunk. # bchunk imagefile.bin imagefile.cue imagefile.iso

Creating an image from a file

For example, a 1GB partition uses the file /usr/vdisk.img. In this case we use the key -u 0, but the number can be anything.

FreeBSD

# dd if=/dev/random of=/usr/vdisk.img bs=1K count=1M # mdconfig -a -t vnode -f /usr/vdisk.img -u 0 # Create a device /dev/md1 # bsdlabel -w /dev/md0 # newfs /dev/md0c # mount /dev/md0c /mnt # umount /mnt; mdconfig -d -u 0; rm /usr/vdisk.img # Clear md An image created from a file can be mounted during system boot by writing a line to /etc/rc.conf And /etc/fstab. You can check if your settings are correct using the command /etc/rc.d/mdconfig start(after removing the device md0 using the command # mdconfig -d -u 0). Keep in mind that automatic image mounting will only work if the image file is NOT in the root partition, due to the fact that the script /etc/rc.d/mdconfig performed at an early stage of boot, when the root partition is not yet writable. Images located outside the root partition will be mounted later by the script /etc/rc.d/mdconfig2.

/boot/loader.conf: md_load="YES" /etc/rc.conf: mdconfig_md0="-t vnode -f /usr/vdisk.img" # /usr not in the root partition/etc/fstab: (0 0 at the end, very important, this will indicate fsck ignore device check since it does not exist yet) /dev/md0 /usr/vdisk ufs rw 0 0

In addition, you can subsequently increase the image size, say by 300 MB. #umount/mnt; mdconfig -d -u 0 # dd if=/dev/zero bs=1m count=300 >> /usr/vdisk.img # mdconfig -a -t vnode -f /usr/vdisk.img -u 0 # growfs /dev /md0 # mount /dev/md0c /mnt # Now the file partition is 300 MB larger

Linux

# dd if=/dev/zero of=/usr/vdisk.img bs=1024k count=1024 # mkfs.ext3 /usr/vdisk.img # mount -o loop /usr/vdisk.img /mnt # umount /mnt; rm /usr/vdisk.img # Clear

Linux and losetup

/dev/zero much faster than urandom, but less secure for encryption. # dd if=/dev/urandom of=/usr/vdisk.img bs=1024k count=1024 # losetup /dev/loop0 /usr/vdisk.img # Create /dev/loop0 # mkfs.ext3 /dev/loop0 # mount /dev/loop0 /mnt # losetup -a # Check # umount /mnt # losetup -d /dev/loop0 # Disconnect # rm /usr/vdisk.img

Creating an In-Memory File System

The in-memory file system is very fast, it makes sense to use it for applications with high disk IO. Let's create a partition of 64 MB in size and mount it in /memdisk:

FreeBSD

# mount_mfs -o rw -s 64M md /memdisk # umount /memdisk; mdconfig -d -u 0 # Clear md device md /memdisk mfs rw,-s64M 0 0 # write to /etc/fstab

Linux

# mount -t tmpfs -osize=64m tmpfs /memdisk

Disk performance

Read and write 1GB file in section ad4s3c (/home) # time dd if=/dev/ad4s3c of=/dev/null bs=1024k count=1000 # time dd if=/dev/zero bs=1024k count=1000 of=/home/1Gb.file # hdparm -tT / dev/hda # Linux only

The FHS standard rests on two fundamental principles: a clear separation in the file hierarchy of shared and non-shared directories, on the one hand, and immutable and mutable, on the other.

The contrast between shared and non-shared directories is due to the inherent network nature of Unix in general and FreeBSD in particular. That is, data related to the local machine (for example, configuration files for its devices) should be located in directories separate from those whose data is accessible from other machines on the network, local or global (an example of which is not only user data, but also programs) .

Strict adherence to the concept of separating shared and non-shared, immutable and immutable directories from each other allows, within a single tree-like file hierarchy, to isolate its individual branches physically - that is, in the form of independent file systems located on isolated devices (disks, disk slices, partitions; in the general case and on remote, network-connected media, but this will not be discussed now). There are many reasons for this - increasing speed, increasing reliability, and simply considerations of convenience, but we won’t talk about them now. Because now all that matters to us is that these branches of the file tree must be incorporated into the overall file system.

The previous note said that every file (including a directory) is recognized by the system not by its name, but by the unique identifier of its entry in the inodes table. There are tools to view these file IDs. One is the ls command with the i option, which will print the IDs of each named file. Given for the root directory - $ ls -i

it will show us a somewhat unexpected picture (to simplify the output, information about ordinary files and symbolic links in the root is excluded from the output, and the remaining directories are sorted by their identifiers) 2 ../ 2 ./ 2 dev/ 2 home/ 2 tmp/ 2 usr/ 2 var/ 3 cdrom/ 4 mnt/ 5 root/ 8257 dist/ 8258 bin/ 8294 proc/ 8295 sbin/ 16512 stand/ 24768 etc/ 24776 boot/

The first two elements of the list are easy to understand: ./ represents the current directory (in this case, the root), and ../ the parent directory of the current one; and since, by definition, there is nothing above the root in the file hierarchy, it denotes itself. So it is not surprising that ./ and ../ have the same identifier - these are different designations (hard links, or otherwise duplicate names) for the same root directory.

But the same, as it seems at first glance, the meaning of the identifier for the /dev, /home, /tmp, /usr, /var directories requires explanation. However, it is simple: all of these are directories in which independent file systems are mounted, either located on separate devices - disk partitions, such as the /home, /usr, /var directories, or virtual file systems that do not build on any real disk device ( the /dev directory with the device file system and, in this case, the /tmp directory, in which the file system in RAM is mounted, which will be discussed later). And since the inodes table is different for each file system, it is not surprising that the root of each of them is identified by the number 2; the inodes in them are numbered in their own reference system.

So, mounting is the inclusion of a file from the system in any of the directories existing in the root system (not necessarily directly in the root, it can be of any degree of nesting, which is illustrated below). Without this, the directories and files of such a mounted system are simply inaccessible. This is important to understand when you encounter expressions like “create the /usr filesystem.” From the above, it is obvious that what is being created (by the newfs command) is simply a certain abstract file system, and it acquires its “name” only at the moment of mounting it in the specified directory.

It is interesting that the directory identifier for mounting (also called the mount point) is found only at the time of mounting. To verify this, let's conduct a simple experiment. In the /mnt directory, intended specifically for mounting temporarily mounted file systems), you can see three subdirectories /mnt/disk, mnt/iso, /mnt/usb (this is on my system, I created them for my own convenience; initially the /mnt directory was in FreeBSD is empty). When the system starts, nothing is mounted in them, and their normal state is to be empty. If you look at their identifiers, you can see something like this: $ ls -i1 /mnt 16:46 ttyp0 18 disk/ 24 iso/ 19 usb/

Now let’s take and mount a flash drive with a USB interface into /mnt/usb (this is exactly what I intended it for) and repeat the viewing. And we see: 18 disk/ 24 iso/ 2 usb/

Let's digress a little and remember about hard links, through which the same inode and the data blocks related to it can be assigned different names. Now it’s clear why all such duplicate files should be located in the same file system: after all, different file systems have their own, non-matching, numbering of inodes, and it is impossible to identify them by numbers (otherwise how would the system distinguish the /usr and /var directories from our example after all, she doesn’t care about file names). For symbolic links that have their own inodes (in fact, and nothing except them) with their own identifiers, numbered in the reference system of the file system in which they are located, there is no such restriction. And symbolic links can be located anywhere (including on a remote machine, not just on another partition).

Mounting purposes are served by the mount command, executed either automatically during system boot or manually from the command line. Actually, in the full sense, only the root file system is automatically mounted in any case. It does not have to be on the disk; when starting from a rescue CD or other safety media, it can be located on a virtual disk in RAM. However, the process of mounting the root file system is as inevitable as the victory of socialism on a global scale: just as socialism, without winning on a global scale, simply loses the ability to exist (which we recently observed), so can an OS exist without a root system can not. In Linux, this causes kernel panic mode approximately the state into which our leaders fell 20 years ago. True, they turned out to be stronger than Linux and recovered quite quickly so they are still rebooting us (or rebooting? but we are getting stronger :)). However, this does not apply to the installation matter that I will try to present to you now.

So, to mount all file systems except the root one, you need to take some steps. First we'll look at how to do them manually, and then how to immortalize them in the appropriate configuration files.

So, the mount command. Actually, this is a whole family of programs, each of which is designed to mount file systems of certain types - not only UFS, but also any of those supported by FreeBSD. The list of these is quite extensive; you can get an idea about it by looking at the /sbin directory: $ ls /sbin/mount*

which will give us in response /sbin/mount /sbin/mount_msdosfs /sbin/mount_smbfs /sbin/mount_cd9660 /sbin/mount_nfs /sbin/mount_std /sbin/mount_devfs /sbin/mount_ntfs /sbin/mount_udf /sbin/mount_ext2fs /sbin/mount_nullfs / sbin/mount_umapfs /sbin/mount_fdescfs /sbin/mount_nwfs /sbin/mount_unionfs /sbin/mount_linprocfs /sbin/mount_portalfs /sbin/mount_mfs /sbin/mount_procfs

Each command on this list is responsible for a different type of file system, some of which we will return to later. For now, let’s only note /sbin/mount itself, designed to work with UFS and UFS2.

Called from the command line, it requires two arguments: the name of the device to be mounted and the mount point (that is, the directory into which the underlying file system should be mounted). The device name should indicate a patricia already mapped on an existing BSD slice with a UFS2 file system (UFS) created on it, for example, $ mount /dev/ads0d /usr

mounts the file system on the specified partition in the /usr directory of the root of the file tree. If the file system on the device is not created or is of a type other than 4.2BSD, an error message will appear indicating an incorrect super block: unlike the Linux utility of the same name, the FreeBSD mount command itself cannot recognize the file system type.

The following requirements are imposed on the mount point: a) a directory with the same name must exist at the time of mounting, and b) be as empty as possible. The first is mandatory, but the second is not entirely necessary. Mounting into a directory with any files will go smoothly (I remember that in Linux not so long ago this caused a system crash), but all its contents will become inaccessible until unmounted. And if the files it contains play a significant role for any subsystem, this can cause all sorts of bad consequences. For example, if the contents of the /tmp directory were blocked by mounting a file system there while the X window system was running, the result would likely be a crash of the X server. Fortunately, if necessary, you can perform a combined mount (see below).

In the specified form, mounting will be performed with some default characteristics: the file system will be read/write in the so-called mode. noasync (the same one in which metadata operations are performed synchronously, and data operations are performed asynchronously). This position can be changed using the -o option. There are quite a few of them, but practically the main ones for us at this stage will be:

async will provide a completely asynchronous mode (despite the dire warnings in previous posts, I will later talk about a situation when this can be justified);
sync on the contrary, enabling a fully synchronous mode (though I don’t really understand why this is practically necessary);
noatime a very useful option that prevents the update of the last access time attribute of files, which greatly improves performance;
rdonly mounts the file system in read-only mode (sometimes this is necessary);
union the same option that allows you to perform a union mount, in which the previous contents of the mount point directory remain visible; true with some restrictions see man (8) mount.

There are several other values of the -o option that prohibit certain types of files from being placed on the mounted file system, for example, executable files (-o noexec), device files (-o nodev), or files with so-called. bit (-o nosuid), but they are of practical importance mainly for server administrators and serve security purposes. On a desktop machine, the usual form of mounting would be something like this: $ mount -o noatime /dev/ads0d /usr; $ mount -o noatime /dev/ads0e /var; $ mount -o noatime /dev/ads0f /home

to mount the compact, or $ mount_msdosfs /dev/ad## /mnt

for FAT of any kind (including FAT32). However, this can be done indirectly by specifying the -t file_system_type option to the mount command. Thus, the command $ mount -t ext2fs /dev/ad## /mnt/linux

mounts the Linux file system (if the corresponding feature is included in the kernel). In this case, the standard mount for BSD partitions is simply replaced by the /mount_ext2fs command, designed to mount ext2fs partitions (and ext3fs too, but, of course, without any journaling functions). That is, the form $mount -t fstype ... ...

will be the exact equivalent of the $mount_fstype command... ...

All operations for mounting file systems (including on removable media) in FreeBSD require superuser rights. The values of the -o option here, unlike the Linux version of the mount command, do not include a user parameter that allows mounting to ordinary users. True, there are several ways to get around this, but it’s inappropriate to talk about them now. Setting up automatic mounting

For automatic mounting, the mount program is run during the boot process from the initialization scripts. It looks for its configuration file /etc/fstab, and mounts everything it finds in it, with some exceptions (discussed below).

The /etc/fstab file is a simple database in text format (fields separated by spaces or tabs), including the following fields:

Device file name of the device on which the file system is located, similar to the first argument of the mount command when used manually;
Mountpoint mount point (corresponds to the second argument of the mount command);
FStype file system type, also specified as the value of the -t option;
Options additional mounting options, similar to the values of the -o option;
Dump conditions for performing a file system backup using the dump utility;
Pass# conditions for checking the file system with the fsck utility.

In a freshly installed FreeBSD /etc/fstab will necessarily include the following entries (example for the 1st slice of the Master disk on the 1st IDE channel): # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1b none swap sw 0 0

If you follow the advice of reasonable people (and the defaults of sysinstall) and select some branches of the file system from the root, entries like /dev/ad0s1d /var ufs rw 0 0 /dev/ad0s1e / will be added to those listed (when automatically marking the slice through sysinstall) usr ufs rw 0 0 /dev/ad0s1f /tmp ufs rw 0 0

responsible for the file system with user home directories.

Obviously, in the Options field you can add any available (and reasonable) values of the -o option (separated by commas, without spaces), for example, noatime for all file systems, and for /tmp also async, because the contents of this directory are not expected saving after reboot.

The above applies to file systems that are mounted automatically at startup. However, no one bothers you to make entries in /etcfstab for systems that are connected from time to time - in this case they can be mounted according to a simplified scheme (this is what I meant above by semi-automatic mode). So, for a CD drive you can add the line (in fact, it automatically appears when the /etc/fstab file is generated) /dev/acd0 /cdrom cd9660 ro,noauto 0 0

in which the options, as you might guess, require refusal to mount at startup (noauto) and read-only mode (ro). After that, to mount a CD, it will be enough to specify only the mount point - $ mount /cdrom

Similar entries can be made for all removable drives (Zip, USB drives, even floppy disks) and for non-BSD partitions (FAT or Ext2fs). By the way, you can mount file systems using the simplified scheme immediately after making changes to /etc/fstab, without waiting for the machine to reboot. Unmounting

All involved file systems must be unmounted before turning off the power or rebooting the machine. Upon correct shutdown, this is done automatically, as a result of which each of the writable file systems (or rather, the partition that carries it) receives a clean unmount bit in its superblock.

However, in a number of cases (for example, when connecting or disconnecting the Soft Updates mechanism or to perform an integrity check), it becomes necessary to manually unmount (and remount) file systems, for which the umount command is used. It requires a single argument: the mount point of the file system to be removed from the directory tree, for example: $ umount /tmp

You can unmount multiple file systems with one line: $ umount /usr /var /home

Or you can all mounted file systems or all file systems listed in the /etc/fstab file (except the root), which requires the $ umount -A options

or $umount -a

respectively. It is also possible to unmount certain types of file systems by specifying the values of the -t option. So, the command $ umount -t ufs

will unmount only BSD partitions, without affecting the CD and everything else that is involved in the system.

File systems should not be in use at the time of unmounting, that is, there should be no access to the files located on them. So, being in any directory of a file system is a sufficient reason for refusing to unmount it (with a message like device busy), which is why none of the commands listed above will be able to unmount the root file system. But reading a data file by any program is not a reason for refusing to unmount the system hosting this file (after all, in the general case, communication between a file in memory and a file on disk occurs only at the time of recording changes.

However, you can also unmount the file system you are using; to do this, you will need to issue the umount command with the -f option. True, this can lead to errors, so it is better not to resort to it unless absolutely necessary. And the forced unmount option will not have any effect on the root file system. Bulk mount

By the way, the mount command without options and arguments (and in this form, unlike all the cases discussed above, it can be given by an ordinary user) will display a list of currently mounted file systems indicating the mount point, its conditions and operating mode. For example, for the machine on which these lines are written, the output will look like this: /dev/ad0s1a on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) /dev/ccd0e on /var (ufs, local, noatime, soft-updates) /dev/ccd1e on /usr (ufs, local, noatime, soft-updates) /dev/ccd2e on /home (ufs, local, noatime, soft-updates) /dev/ md0 on /tmp (ufs, local, noatime, async)

The first line of output shows that the /dev/ad0s1a partition is mounted in our root directory, carries a UFS file system (specifically in this case, UFS2, but in the output of the mount command they do not differ) with the Soft Updates mechanism enabled, is local ( that is, located on the disk of this machine; network drives are also mounted with the mount command) and are not subject to updating the atime attribute.

But then there are lines for devices and file systems, which were not discussed in previous stories. Moreover, if we look at the /etc/fstab file corresponding to the current configuration: $ more /etc/fstab /dev/ad0s1b none swap sw 0 0 /dev/ar0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw,noatime 1 1 /dev/ccd0e /var ufs rw,noatime 2 2 /dev/ccd1e /usr ufs rw,noatime 2 2 /dev/ccd2e /home ufs rw,noatime 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 / dev/da0s1 /mnt/usb ext2fs rw,noauto,noatime 0 0 /dev/md0 /tmp mfs rw,noatime,async,-s32m 2 0

then we will see that one of the output lines (devfs on /dev (devfs, local) has no match at all among its entries. What kind of devices and file systems are these?

Regarding devices like /dev/ccd0? I’ll just say for now that these are software RAID arrays (we will talk about them in more detail later). But devfs and mfs are virtual file systems, which will be discussed directly in the next note.

Automatically mount a network drive when freebsd boots. File system

Add a hard drive to FreeBSD in 5 minutes

Detailed instructions with explanations

Selecting a hard drive name

Removing existing markup

Creating GPT markup

Creating sections (slices)

Creating a file system (formatting)

Mounting

Brief instructions

Detailed instructions with explanations

Selecting a hard drive name

Removing existing markup

Creating GPT markup

Creating sections (slices)

Creating a file system (formatting)

Mounting

Brief instructions

File system logic

Mounting practice

Setting up automatic mounting

Unmounting

Bulk mount

Preamble instead of conclusion

Disk Information

Loading

FreeBSD

Mount points, disk usage

Directory information

Who opened which files

FreeBSD and most Unix-like systems

Linux

Mounting/remounting file systems

FreeBSD

Linux

Mounting a FreeBSD partition with Linux

Rewiring

Creating a swap partition on the fly

Mounting an SMB partition

Linux

FreeBSD

Mount image

Linux loop-back

FreeBSD

Creating and Burning an ISO Image

Burning CD/DVD ISO images

FreeBSD

Linux

dvd+rw-tools

Convert image from Nero .nrg file to .iso file

Convert bin/cue image to .iso

Creating an image from a file

FreeBSD

Linux

Linux and losetup

Creating an In-Memory File System

FreeBSD

Linux

Disk performance

Popular articles

Latest articles

Sections

Pages

Special projects

Contacts