Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I believe that the FAT32 file system does not support file permissions, however when I do ls -l on a FAT32 partition, ls -l shows that the files have permissions:
-rw-r--r-- 1 john john 11 Mar 20 15:43 file1.txt
-rw-r--r-- 1 john john 5 Mar 20 15:49 file2.txt
Why is ls -l displaying the permissions of files?
The filesystem as stored on disk doesn't store all file permissions, but the filesystem driver has to provide them to the operating system since they are an integral part of the Unix filesystem concept and the system call interfaces have no way of presenting that the permissions are missing.
Also consider what would happen if a file didn't have any permission bits at all? Would it be the same as 0777, i.e. access to all; or the same as 0000, i.e. no access to anyone? But both of those are file permissions, so why not show them? Or do something more useful and have a way to set some sensible permissions.
So, the driver fakes some permissions, mostly same ones for all files. The permissions along with the files' owner and group are configurable at mount time. These are described under "Mount options for fat" in the mount(8) man page:
Mount options for fat
(Note: fat is not a separate filesystem, but a common part of the msdos, umsdos and vfat filesystems.)
uid=valueandgid=value
Set the owner and group of all files. (Default: the UID and GID of the current process.)
umask=value
Set the umask (the bitmask of the permissions that are not present). The default is the umask of the current process. The value is given in octal.
dmask=value
Set the umask applied to directories only. The default is the umask of the current process. The value is given in octal.
fmask=value
Set the umask applied to regular files only. The default is the umask of the current process. The value is given in octal.
Note that the one useful permission the FAT filesystems store is the read-only -bit, and if you run chmod ugo-w file, the read permissions on it will disappear.
That's also probably the reason that the above options take their values as permissions to masks away, so fmask=0133 would result in all files having all the x permissions removed and w removed from the group and others. The files would then have the permissions 0644/rw-r--r-- or 0444/r--r--r--, depending on if the read-only bit is cleared or set.
Also, the defaults are inherited from the process calling mount(), so if you call mount from the command line, the shell's umask will apply.
umask mount option, for which the default value is umask of mount process (see the man page linked to in this answer).
chmod ugo-w on a file will turn the read-only attribute on. Using the fmask=0133 option as in your example will not result in all files having the 0644 permission. What FAT absolutely does not store is a uid and a gid for each file. Please clarify; the answer as it stands is highly misleading.
But the files do have permissions. User john has RW access, while some random user only has read access. These permissions didn’t come from the filesystem itself but rather from mount options (-o uid/gid/umask), which doesn’t make them any less real.
You could have multiple vfat partitions mounted with different options and you could use ls to determine what those options were. You could even use mount --bind to have a single directory contain files from different vfat partitions, and ls would correctly show what permissions have been specified for each file.
ls doesn't know about FAT32, it only knows about the Virtual Filesystem (VFS) interface exposed by the kernel with POSIX open / readdir / stat system calls.
Linux doesn't support the concept of files that don't have user/group/other permission bits, struct stat simply contains a mode_t st_mode; member (and uid, gid members) that the kernel must fill out when ls -l makes stat(2) system calls.
There's no special code that means "not available" or "not applicable" for any of those fields, so the kernel's vfat driver must make something up. FAT16/FAT32 does have a read-only flag, but otherwise the owner/group come from mount options, and so does a umask.
