I get that I can use mount to set up / directories and that I can use the /etc/fstab to remount them on reboot.

Testing the fstab file is also fun with mount -faV.

When I'm looking at the fstab file, the number of space is disconcerting. I would have expected one space (like a separator between command parameters) or four spaces (like a tab). I'm seeing seven spaces at a time, almost as convention.

My question is: What are all the spaces in the /etc/fstab for?

(Perhaps also - Will it matter if I get the wrong number?)

  • 2
    Also very nice if you wanted more readable structur mount | column -t :)
    – demonking
    Dec 4, 2015 at 9:14
  • 13
    "...four spaces (like a tab)". These young whippersnappers:-) Tabs (once they were standardised) were originally every eight characters (see Wiki).
    – TripeHound
    Dec 4, 2015 at 13:02
  • 3
    "Testing the fstab file is also fun.." Running anything on Linux can be a fun pasttime.
    – Octopus
    Dec 4, 2015 at 21:55
  • @TripeHound "see Wiki". These old grey(beards|hairs) ... quote: A wiki is a hypertext publication collaboratively edited and managed by its own audience (see Wiki_pedia_) ... sorry, could not resist. 😁️ May 8, 2020 at 20:28
  • 2
    @0xC0000022L Single asterisks instead of underscores do the trick.
    – TripeHound
    May 8, 2020 at 22:16

3 Answers 3


The number of spaces is a way to cosmetically separate the columns/fields. It has no meaning other than that. I.e. no the amount of white space between columns does not matter.

The space between columns is comprised of white space (including tabs), and the columns themselves, e.g. comma-separated options, mustn't contain unquoted white space.

From the fstab(5) man page:

[...] fields on each line are separated by tabs or spaces.


If the name of the mount point contains spaces these can be escaped as `\040'.


With the following lines alignment using solely a single tab becomes hard to achieve. In the end the fstab without white space looks messier than what you consider disconcerting now.

/dev/md3 /data/vm btrfs defaults 0   0
/var/spool/cron/crontabs /etc/crontabs bind defaults,bind
//bkpsrv/backup /mnt/backup-server cifs iocharset=utf8,rw,credentials=/etc/credentials.txt,file_mode=0660,dir_mode=0770,_netdev

Can you still see the "columns"?

  • 1
    You wouldn't see the "columns" anyway because some line have very long "column" and anyway any line can be longer than 80 columns and so might display "badly" when you do cat /etc/fstab in a small terminal, not to mention the use of UUID! So you'll end up bothering adding spaces all over the file.
    – cylgalad
    Dec 4, 2015 at 9:23
  • 3
    @cylgalad Use less -S then. Displaying tabular data on screens with small widths is always an issue.
    – musiKk
    Dec 4, 2015 at 10:21
  • 1
    @cylgalad True the spaces are not as helpful as they were back when the convention with spaces was introduced. In those days the length of each field was still short enough to stay within the column, and the columns were narrow enough to fit all of them in 80 characters.
    – kasperd
    Dec 4, 2015 at 12:50
  • 2
    And here I am just realizing all that time spent counting spaces were just a waste.
    – Aloha
    Dec 5, 2015 at 7:37
  • "mustn't contain unquoted white space" So there's no way to break up long lines to make them more readable?
    – endolith
    Oct 10, 2016 at 1:02

The spaces or tabs delimit the fields. Use as few or as many as suits. If you find fstab a little unreadable try using column to prettify it.

example of column -t usage for fstab

  • 16
    Ooh column is nice Dec 4, 2015 at 12:40
  • In fact, on my main computer fstab, column makes it less readable than cat!
    – cylgalad
    Dec 5, 2015 at 9:25

getmntent raises a parse error if a line exceeds the character limit. (getmntent is the recommended way to read /etc/fstab).

man getmntent reveals:

The getmntent() function reads the next line of the filesystem description file from stream and returns a pointer to a structure containing the broken out fields from a line in the file.

As can be seen from getmtent_r, the structure mount used for storing file descriptor info is stored as an array of buflen - so the parse error occurs for larger entries than buflen.

So this design was chosen because the \ escape character will not work in fstab for multiple line breaks in a single entry.

You can easily verify this, and the difference is NOT just cosmetic...

  • It seems like too many characters per line might in fact cause problems. The man page isn't very clear about this. The mntent struct itself only contains pointers. Technically the C strings behind them could have arbitrary length. However, no dynamic memory management seems to be involved, instead the man page mentions a static area of memory which is used, so I the size has to be limited. Do you have a source you can point us to for further information (like the max. length of the strings/line)? May 20, 2020 at 4:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .