[SERVER-26696] Accessing lost+found when using directoryPerDB Created: 19/Oct/16 Updated: 17/Jan/17 Resolved: 17/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Lorne Schachter | Assignee: | Mark Agarunov |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
Client is using directoryPerDB and dbPath=/data is a mount point. It looks like mongoldb is treating the lost+found directory as a database and trying to access the ns file, which obviously doesn't exist. We should make sure we don't try to access this directory. 2016-10-17T05:53:11.077-0700 E NETWORK [conn3] Uncaught std::exception: boost::filesystem::status: Permission denied: "/data/lost+found/lost+found.ns", terminating |
| Comments |
| Comment by Mark Agarunov [ 17/Jan/17 ] |
|
Doesn't reproduce on 3.4.1. Verified that lost+found exists on a clean ext4 filesystem mounted at /data/ and mongod starts without issue using /data/ as the dbpath with both WiredTiger and mmapv1 engines. |
| Comment by Ramon Fernandez Marina [ 19/Oct/16 ] |
|
That's a fun one! Sending to the Storage group for triage. |