1

TL;DR: MongoDB complains about permissions on a directory where everything is allowed.

I am running MongoDB v2.4.10 on Debian Jessie ARM. I'd like to store data on an external drive, which is formatted to ext4 and mounted via /etc/fstab with the following line:

UUID=<uuid goes here> /mnt/external1 ext4 defaults,noatime 0 0

The permissions on /mnt/external1 are:

$ ls -l | grep external1
drwxrwxrwx 4 root plugdev 4096 Jul 31 10:57 external1

They were set after the drive was mounted by issuing:

$ sudo chown -R root:plugdev /mnt/external1
$ sudo chmod 777 -R /mnt/external1

The mongodb user is in the group plugdev:

$ cat /etc/group | grep mongodb
plugdev:x:46:mongodb
mongodb:x:112:mongodb

However, after running sudo service mongodb start I see the following in /mnt/external1/mongodb.log:

Fri Jul 31 10:56:17.341 [initandlisten] MongoDB starting : pid=27189 port=27017 dbpath=/mnt/external1/mongodb 32-bit host=odroidc1
Fri Jul 31 10:56:17.341 [initandlisten]
Fri Jul 31 10:56:17.341 [initandlisten] ** NOTE: This is a 32 bit MongoDB binary.
Fri Jul 31 10:56:17.341 [initandlisten] **       32 bit builds are limited to less than 2GB of data (or less with --journal).
Fri Jul 31 10:56:17.341 [initandlisten] **       See http://dochub.mongodb.org/core/32bit
Fri Jul 31 10:56:17.343 [initandlisten]
Fri Jul 31 10:56:17.343 [initandlisten] db version v2.4.10
Fri Jul 31 10:56:17.343 [initandlisten] git version: nogitversion
Fri Jul 31 10:56:17.343 [initandlisten] build info: Linux hartmann 3.16.0-0.bpo.4-armmp-lpae #1 SMP Debian 3.16.7-ckt4-3~bpo70+1 (2015-02-12) armv7l BOOST_LIB_VERSION=1_55
Fri Jul 31 10:56:17.343 [initandlisten] allocator: system
Fri Jul 31 10:56:17.343 [initandlisten] options: { bind_ip: "<ip goes here>", config: "/etc/mongodb.conf", dbpath: "/mnt/external1/mongodb", journal: "true", logappend: "true", logpath: "/mnt/external1/mongodb.log" }
Fri Jul 31 10:56:18.002 [initandlisten] journal dir=/mnt/external1/mongodb/journal
Fri Jul 31 10:56:18.002 [initandlisten] recover : no journal files present, no recovery needed
Fri Jul 31 10:56:18.003 [initandlisten] warning couldn't write to / rename file /mnt/external1/mongodb/journal/prealloc.0: couldn't open file /mnt/external1/mongodb/journal/prealloc.0 for writing errno:1 Operation not permitted
Fri Jul 31 10:56:18.022 [initandlisten] couldn't open /mnt/external1/mongodb/local.ns errno:1 Operation not permitted
Fri Jul 31 10:56:18.022 [initandlisten] error couldn't open file /mnt/external1/mongodb/local.ns terminating
Fri Jul 31 10:56:18.022 dbexit:
Fri Jul 31 10:56:18.022 [initandlisten] shutdown: going to close listening sockets...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: going to flush diaglog...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: going to close sockets...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: waiting for fs preallocator...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: lock for final commit...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: final commit...
Fri Jul 31 10:56:18.023 [initandlisten] shutdown: closing all files...
Fri Jul 31 10:56:18.023 [initandlisten] closeAllFiles() finished
Fri Jul 31 10:56:18.023 [initandlisten] journalCleanup...
Fri Jul 31 10:56:18.023 [initandlisten] removeJournalFiles
Fri Jul 31 10:56:18.027 [initandlisten] shutdown: removing fs lock...
Fri Jul 31 10:56:18.028 dbexit: really exiting now

which means that MongoDB can append to existing files (the log itself), but cannot create new ones.

If instead of root:plugdev (which I believe is the standard way to mount external drives; please correct me if I'm wrong) I set the owner to mongodb:mongodb, the problem goes away. However, I'd like to get it right instead of hacking a way through.

How do I get it right?

1 Answer 1

0

Setting the owner of just /mnt/external1/mongodb and /mnt/external1/mongodb.log to mongodb:mongodb solves the problem. However, this solution will not work if the drive is formatted to NTFS and mounted via ntfs-3g, unless the owner of the entire drive is set to mongodb:mongodb. I'm marking the question as solved, since from the formal viewpoint this is indeed a solution of the problem in my case.

You must log in to answer this question.

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