The two options are
* nocover/cover: Prevent/allow mounting over an existing root mountpoint.
E.g., "mount -t ufs -o nocover /dev/sd1a /usr/local" will fail if /usr/local
is already a mountpoint.
* emptydir/noemptydir: Prevent/allow mounting on a non-empty directory.
E.g., "mount -t ufs -o emptydir /dev/sd1a /usr" will fail.
Neither of these options is intended to be a default, for historical and
compatibility reasons.
Reviewed by: allanjude, kib
Differential Revision: https://reviews.freebsd.org/D21458
is to notify the kernel that the file system is untrusted and it
should use more extensive checks on the file-system's metadata
before using it. This option is intended to be used when mounting
file systems from untrusted media such as USB memory sticks or other
externally-provided media.
It will initially be used by the UFS/FFS file system, but should
likely be expanded to be used by other file systems that may appear
on external media like msdosfs, exfat, and ext2fs.
Reviewed by: kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D20786
While here:
- Remove deprecated ".Tn" macros.
- Improve formatting and fix typos in the description of
the -t option.
Reviewed by: bcr
Approved by: mat (mentor)
Differential Revision: https://reviews.freebsd.org/D16541
If the operation is not an update, if neither r/w nor r/o mode is
explicitly requested, if the error code hints at the possibility of the
media being read-only, and if the fallback is allowed, then we can try
to automatically downgrade to the readonly mode.
This is especially useful for auto-mounting of removable media that
sometimes can happen to be write-protected.
The fallback to r/o is not enabled by default. It can be requested on a
per-mount basis with a new mount option, 'autoro'. Or it can be
globally allowed by setting vfs.default_autoro.
Reviewed by: cem, kib
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D13361
Describe (briefly) how to compile the filesystem into the kernel and
load as a module.
Reference cd9660(5) in mount(8) and mount_cd9660(8).
MFC after: 1 month
Sponsored by: Dell EMC Isilon
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
filesystems. It differs from file(1) in that it gives machine-parseable
output, it outputs filesystem labels, doesn't get confused by other
formats metadata, and runs in Capsicum sandbox.
Differential Revision: https://reviews.freebsd.org/D1255
Relnotes: yes
Sponsored by: The FreeBSD Foundation
- Reconnect with some minor modifications, in particular now selsocket()
internals are adapted to use sbintime units after recent'ish calloutng
switch.
The "failok" option doesn't have any effect at all unless specified in
fstab(5) and combined with the -a flag. The "failok" option is already
documented in fstab(5).
PR: 177630
No objection: eadler
MFC after: 1 week
GIANT from VFS. In addition, disconnect also netsmb, which is a base
requirement for SMBFS.
In the while SMBFS regular users can use FUSE interface and smbnetfs
port to work with their SMBFS partitions.
Also, there are ongoing efforts by vendor to support in-kernel smbfs,
so there are good chances that it will get relinked once properly locked.
This is not targeted for MFC.
GIANT from VFS. This code is particulary broken and fragile and other
in-kernel implementations around, found in other operating systems,
don't really seem clean and solid enough to be imported at all.
If someone wants to reconsider in-kernel NTFS implementation for
inclusion again, a fair effort for completely fixing and cleaning it
up is expected.
In the while NTFS regular users can use FUSE interface and ntfs-3g
port to work with their NTFS partitions.
This is not targeted for MFC.
GIANT from VFS. In addition, disconnect also netncp, which is a base
requirement for NWFS.
In the possibility of a future maintenance of the code and later
readd to the FreeBSD base, maybe we should think about a better location
for netncp. I'm not entirely sure the / top location is actually right,
however I will let network people to comment on that more specifically.
This is not targeted for MFC.
mount(8): add xref to devfs(5)
devfs(5): change example to something more likely to be useful (it is not
necessary to mount a devfs on /dev manually, but for chroots/jails it is
often needed), mention since when devfs is preferred to device nodes on ufs
PR: 146600
MFC after: 2 weeks
bottom of the manpages and order them consistently.
GNU groff doesn't care about the ordering, and doesn't even mention
CAVEATS and SECURITY CONSIDERATIONS as common sections and where to put
them.
Found by: mdocml lint run
Reviewed by: ru
does. This is not POLA violation, because there is no single file system in the
base that use MNT_IGNORE currently, although ZFS snapshots will be mounted with
MNT_IGNORE after next commit.
Reviewed by: kib
MFC after: 3 days
an alternative program to be used for mounting a file system.
Ideally, all file systems
should be converted to pass string arguments to nmount(), so that
/sbin/mount can handle them. However, certain file systems such as FUSE have
not done this, and want to have their own userland mount programs.
For example, to mount an NTFS file system with the FUSE NTFS driver:
mount -t ntfs -o mountprog=/usr/local/bin/ntfs-3g /dev/acd0 /mnt
or via an fstab entry:
/dev/acd0 /mnt ntfs ro,noauto,mountprog=/usr/local/bin/ntfs-3g 0 0
PR: 120784
Requested by: Dominic Fandrey
not be mounted unless the -l flag was specified.
Add an rc script, mountlate, which basically runs 'mount -a -l'. It runs
after DAEMON but before LOGIN.
This is useful for things like loopback mounts, because mountcritremote
runs before mountd / nfsd (since /usr might be a remote file system), so
an attempt to mount a loopback network file system in mountcritremote will
fail.
Also add a progress message to mountcritlocal, for the sake of symmetry
with similar messages in mountcritremote and mountlate.
Reviewed by: freebsd-rc
MFC after: 3 weeks
