Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to follow a regular text file with tail -f -n 50 filename. I get the information from the file just fine, except I always get this error message:

tail: unrecognized file system type 0xbeefdead

It happens on every file. The 0xbeefdead worries me -- it looks like a hacker tag.

$ tail --version
tail (GNU coreutils) 8.4
share|improve this question
Shouldn't it be 0xdeadbeef instead? :P – devnull Mar 24 '14 at 18:00
Close vote retracted. – slm Mar 24 '14 at 21:06
Probably obvious but 0xDEADBEEF is often used to indicate uninitialized bytes and things like that. BEEFDEAD is probably a smartass twist on this. en.wikipedia.org/wiki/Hexspeak (search for deadbeef) – user426724 Mar 24 '14 at 21:36
@goldilocks: It is a nice story but there is no question. Also, fix your caps lock key. – Ben Voigt Mar 24 '14 at 23:15
@BenVoigt Caps lock aside, he made a valid point. The question is perfectly clear: He is just asking if his beef is normal. – Navin Mar 25 '14 at 0:31
up vote 29 down vote accepted

If you're getting this warning when using the StorNext filesystem and are running coreutils 8.21 or earlier, there isn't much to worry about; this warning message is expected.

GNU tail has hardwired knowledge about a number of filesystem types, and warns when it encounters an unknown type. Support for the StorNext filesystem was added to tail in coreutils in April 2013, and was released in coreutils 8.22. The commit is here. If you can't get that version of coreutils, or wish to edit and recompile the source yourself, here is the diff from that commit:

@@ -399,6 +399,8 @@ enum
     return "selinux";
   case S_MAGIC_SMB: /* 0x517B remote */
     return "smb";
+  case S_MAGIC_SNFS: /* 0xBEEFDEAD remote */
+    return "snfs";
   case S_MAGIC_SOCKFS: /* 0x534F434B local */
     return "sockfs";
   case S_MAGIC_SQUASHFS: /* 0x73717368 local */
share|improve this answer
Why does a userspace program like tail need to be compatible with a specific filesystem? I guess what I mean is, is there no filesystem abstraction it can rely on? – Survenant Lazurite Mar 24 '14 at 20:54
@illuminÉ, the main reason for determining the filesystem type is the "tail -f" operation: the most efficient way to figure out if new data has been written to a file varies from one filesystem to another. – Mark Mar 24 '14 at 21:29
tail with the -f option uses inotify if it can. But inotify can only monitor changes caused by activity done by the local system's kernel. So tail will use inotify only if the file argument is on what it classifies as a "local" filesystem. – Mark Plotnick Mar 24 '14 at 22:40
And the final missing piece of information is that the kernel gives no clear indication that anything is wrong when you try to use inotify on a filesystem that doesn't support it, so this magic number kludgefest is basically the only safe way to use it. – Wumpus Q. Wumbley Mar 25 '14 at 2:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.