open() failed; reason: unable to access the file system

Error message

open() failed; reason: unable to access the file system

What it means

The experimental fs module's open() resolves the path against the script entrypoint and then requires a registered 'file' filesystem in the init environment (initEnv.FileSystems["file"]). When the execution context provides no such filesystem handle, opening any file is impossible and this error is returned.

Source

Thrown at internal/js/modules/k6/experimental/fs/module.go:121

func (mi *ModuleInstance) openImpl(path string) (*File, error) {
	initEnv := mi.vu.InitEnv()
	// Strip file scheme if available as we should support only this scheme
	path = strings.TrimPrefix(path, "file://")

	// We resolve the path relative to the entrypoint script, as opposed to
	// the current working directory (the k6 command is called from).
	//
	// This is done on purpose, although it diverges in some respect with
	// how files are handled in different k6 contexts, so that we cater to
	// and intuitive user experience.
	//
	// See #2781 and #2674.
	path = fsext.Abs(initEnv.CWD.Path, path)

	fs, ok := initEnv.FileSystems["file"]
	if !ok {
		return nil, errors.New("open() failed; reason: unable to access the file system")
	}

	if exists, err := fsext.Exists(fs, path); err != nil {
		return nil, fmt.Errorf("open() failed, unable to verify if %q exists; reason: %w", path, err)
	} else if !exists {
		return nil, newFsError(NotFoundError, fmt.Sprintf("no such file or directory %q", path))
	}

	if isDir, err := fsext.IsDir(fs, path); err != nil {
		return nil, fmt.Errorf("open() failed, unable to verify if %q is a directory; reason: %w", path, err)
	} else if isDir {
		return nil, newFsError(
			InvalidResourceError,
			fmt.Sprintf("cannot open %q: opening a directory is not supported", path),
		)
	}

	data, err := mi.cache.open(path, fs)

View on GitHub (pinned to 93accf6570)

Solutions

Run the script with a k6 version/build that registers the local filesystem (standard k6 run does)
In tests or embedded runners, populate the init environment: InitEnv.FileSystems["file"] = fsext.NewOsFs() (or afero fs)
Verify you call fs.open() in the init context; other fs failures produce different messages

Example fix

// Go (test harness) before: FileSystems empty -> JS fs.open() fails
// after
runtime.VU.InitEnvField.FileSystems = map[string]fsext.Fs{
    "file": fsext.NewOsFs(),
}

Defensive patterns

Strategy: try-catch

Try / catch

let file;
try {
  file = fs.open(path);
} catch (e) {
  if (String(e.message).includes('unable to access the file system')) {
    throw new Error(`fs unavailable in this execution context; cannot open ${path}`);
  }
  throw e;
}

Prevention

Confirm the runner registers the 'file' filesystem (standard k6 run does; custom/embedded runners must set InitEnv.FileSystems)
In Go tests, always set InitEnvField.FileSystems = map[string]fsext.Fs{"file": ...}
Call fs.open() only in the init context -- later phases produce different failures

When it happens

Trigger: Calling fs.open() in an execution context where the 'file' filesystem was never attached: embedded/test harnesses building a VU without FileSystems, or execution environments that do not expose a local/bundled filesystem to the script.

Common situations: Running scripts in environments where local file access is not wired up; extension or module unit tests that forget to set InitEnv.FileSystems = map[string]fsext.Fs{"file": ...}; mismatched k6 versions where the runner does not register the file fs.

Related errors

AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/682f488075d6ce2a. Report an issue: GitHub.