fs.access throws permission error while checking W_OK on writable dir
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 122k
- Forks
- 37.3k
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 283
Description
- Version:
v10.16.0(also happening onv12.6.0) - Platform:
18.6.0 Darwin Kernel Version 18.6.0(also happening on4.15.0-54-generic Ubuntu) - Subsystem:
fs
I'm experiencing a rather unexpected behaviour when trying fs.access on a directory that's also an NFS shared mount point. The check for fs.constants.W_OK throws Error: EACCES: permission denied, access '/mnt/test/nfs' even though the directory is writable and permissions seem to be correct for the user running the node script process.
Below is a reproduction of what I'm seeing.
const os = require('os');
const path = require('path');
const fs = require('fs');
// Path to the mount directory
const MOUNT_PATH = '/mnt/test/nfs';
const filePath = path.join(MOUNT_PATH, 'foo.txt');
// Write a file
fs.writeFileSync(filePath, 'Hello world!'); // Passes OK
// Read a file
const contents = fs.readFileSync(filePath); // Passes OK
console.log(contents.toString('utf-8')); // 'Hello World!'
// Get stats
os.userInfo();
/*
{
uid: 431,
gid: 433,
username: 'test',
homedir: '/home/test',
shell: '/sbin/nologin'
}
*/
fs.stat(MOUNT_PATH, console.log);
/*
> null Stats {
dev: 52,
mode: 16895, <- '0777' octal
nlink: 1,
uid: 431, <- Correct uid
gid: 433, <- Correct gid
rdev: 0,
blksize: 4096,
ino: 263,
size: 184,
blocks: 0,
atimeMs: 1562948571578.2288,
mtimeMs: 1562897414354.1873,
ctimeMs: 1562897414354.1873,
birthtimeMs: 0,
atime: 2019-07-12T16:22:51.578Z,
mtime: 2019-07-12T02:10:14.354Z,
ctime: 2019-07-12T02:10:14.354Z,
birthtime: 1970-01-01T00:00:00.000Z
}
*/
// Test permissions
fs.access(MOUNT_PATH, fs.constants.R_OK, console.error); // Passes OK
fs.access(MOUNT_PATH, fs.constants.W_OK, console.error);
/*
[Error: EACCES: permission denied, access '/mnt/test/nfs'] {
errno: -13,
code: 'EACCES',
syscall: 'access',
path: '/mnt/test/nfs'
*/
This does not happen on any other directory outside the NFS share. I stumbled upon the exception when writing a very simple health checker script to test the mount availability for a running web service.
Am I missing something? What's the catch here? Thanks in advance.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reproduction using fs.access(MOUNT_PATH, fs.constants.W_OK) on the reported NFS mount, comparing it with fs.writeFileSync, fs.readFileSync, fs.stat, and the R_OK check. Determine whether the differing result is expected NFS behavior or an issue in Node.js fs.access handling; done means documenting the cause or identifying a focused runtime change and its validation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100