# No output module named file-store?

**URL:** <https://forum.suricata.io/t/no-output-module-named-file-store/1182>\
**Category:** Help\
**Tags:** file-extraction\
**Created:** [March 3, 2021, 5:11pm UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182 "2021-03-03T17:11:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![TTwTh3210](https://avatars.discourse-cdn.com/v4/letter/t/c89c15/32.png) [@TTwTh3210](https://forum.suricata.io/u/TTwTh3210)\
**Post date:** [March 3, 2021, 5:11pm UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/1 "2021-03-03T17:11:11Z")

</div>

I’m trying to enable the `file-store` module, but Suricata is saying: `[ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - No output module named file-store`. I’m using v6.0.1 compiled from source on Debian.

My config (under outputs):

```
  - file-store:
      version: 2
      enabled: yes
      xff:
        enabled: no
        mode: extra-data
        deployment: reverse
        header: X-Forwarded-For

```

How can I make sure I can use the `file-store` module?  
Thanks.

---

<div class="post-metadata">

**Author:** ![Livio\_Ricciulli](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/livio_ricciulli/32/669_2.png) [@Livio\_Ricciulli](https://forum.suricata.io/u/Livio_Ricciulli)\
**Post date:** [March 4, 2021, 11:57pm UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/2 "2021-03-04T23:57:34Z")

</div>

Same problem here… The suricata output is contradictory (seems like a bug):  
[ERRCODE: SC\_ERR\_INVALID\_ARGUMENT(13)] - No output module named file-store  
ERRCODE: SC\_WARN\_ALERT\_CONFIG(324)] - One or more rule(s) depends on the file-store output log which is not enabled. Enable the output “file-store”.

Help…

---

<div class="post-metadata">

**Author:** ![Livio\_Ricciulli](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/livio_ricciulli/32/669_2.png) [@Livio\_Ricciulli](https://forum.suricata.io/u/Livio_Ricciulli)\
**Post date:** [March 5, 2021, 12:33am UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/3 "2021-03-05T00:33:44Z")

</div>

Actually, I fixed it. You need to install the nss-devel package before configuring and compiling.  
On CentOS is “yum install nss-devel”  
On debian is apt-get install nss-devel? I am not sure.

---

<div class="post-metadata">

**Author:** ![Livio\_Ricciulli](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/livio_ricciulli/32/669_2.png) [@Livio\_Ricciulli](https://forum.suricata.io/u/Livio_Ricciulli)\
**Post date:** [March 5, 2021, 1:16am UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/4 "2021-03-05T01:16:02Z")

</div>

Now, one thing I still do not understand:  
The files are stored under filestore/\*/ when a rule with the command “filestore”; triggers.  
But the eve.json record for that event says “stored”:false

I am not sure why, shouldn’t it say true?

---

<div class="post-metadata">

**Author:** ![TTwTh3210](https://avatars.discourse-cdn.com/v4/letter/t/c89c15/32.png) [@TTwTh3210](https://forum.suricata.io/u/TTwTh3210)\
**Post date:** [March 5, 2021, 3:44pm UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/5 "2021-03-05T15:44:11Z")

</div>

I built it again with `libnss` support (and others) and file-store is now working, thanks!

Are your rules set to block file transfers? With `alert` rules `eve.json` showed `"stored":true` but the `drop` rules show `"stored":false`.

---

<div class="post-metadata">

**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\
**Post date:** [March 6, 2021, 7:58am UTC](https://forum.suricata.io/t/no-output-module-named-file-store/1182/6 "2021-03-06T07:58:49Z")

</div>

There is a similar report here [Bug #3703: fileinfo "stored: false" even if the file is kept on disk - Suricata - Open Information Security Foundation](https://redmine.openinfosecfoundation.org/issues/3703)

We’ll look at that one soon. If you have other test cases to share, please add them to the ticket.