Why a command works outside tmux but gets permission denied inside

tmux is persistent process context, not a permission layer

tmux does not normally invent a second Linux user or apply its own file mode rules. It runs a long-lived server process, and shells inside its windows descend from that server. Those child processes inherit credentials and other context from their parents. A shell opened by a fresh SSH login may therefore differ from a shell created by a tmux server that has been alive for days, even though both prompts display the same username.

Treat the difference as evidence that the two processes are not operating with identical context. Avoid starting with chmod, chown, sudo, or a recursive permission change. Those commands can hide the original cause, broaden access unnecessarily, and damage ownership or executable bits across a large data directory.

Compare the two shells before changing anything

Run the same inspection commands once in the working shell and once in tmux. Start with id, umask, pwd, and a filtered environment comparison. Check the exact target with namei -l /path/to/file, because Linux requires search permission on every directory in the path, not only read or write permission on the final file. Use getfacl when access control lists may supplement the ordinary owner, group, and mode bits.

Record the exact failing operation and error. Reading a file, listing its parent directory, creating a sibling file, renaming across mounts, and opening a Docker bind mount exercise different checks. Test with a harmless command such as stat or test -r before retrying a script that writes or deletes data.

• Identity: id; id -G; cat /proc/$$/status | grep '^Groups:'.
• Path traversal: namei -l /absolute/path/to/target.
• ACLs: getfacl -p /absolute/path/to/target and its parent directories.
• Mount context: findmnt -T /absolute/path/to/target; readlink /proc/$$/ns/mnt.
• Environment: compare env | sort output, especially HOME, PATH, SSH_AUTH_SOCK, XDG_RUNTIME_DIR, and application-specific variables.

Stale supplementary groups are a common tmux-specific cause

Linux processes carry a set of supplementary group IDs. A child inherits that set from its parent, and executing a new program preserves it. If an administrator adds your account to a storage, Docker, or project group after the tmux server starts, a new login can receive the new group while the old tmux server and every shell it creates continue with the earlier group list.

Compare id -G inside and outside tmux. If the lists differ, finish or checkpoint important jobs before replacing the stale server. A separate test server, for example tmux -L permission-test new, can confirm the diagnosis without touching existing sessions. Logging out fully and starting a new tmux server refreshes login credentials; tmux kill-server also does so, but it terminates every session and must not be used while valuable jobs are running.

Environment, ACL, and namespace differences can look like file permissions

tmux maintains server and session environments for processes it starts. Reattaching from a new SSH connection can update selected variables, but an already-running shell keeps the environment it received when it started. A stale SSH_AUTH_SOCK may cause an authentication failure, a different HOME may select another configuration file, and a missing XDG_RUNTIME_DIR may redirect an application to an inaccessible location. These failures are often reported loosely as permission problems even when Unix mode bits are not the deciding factor.

Also compare ACLs and mount namespaces. Removable disks, network shares, container bind mounts, systemd services, and sandboxed launchers can expose the same pathname through different mounts or identity mappings. findmnt and the namespace link under /proc reveal whether the two shells see the same filesystem context. If the namespace differs, fix how tmux is launched or where the filesystem is mounted instead of weakening permissions on the data.

Apply the narrowest durable fix

For a stale group list, start a fresh login and tmux server after protecting active work. For a real ownership problem, assign the intended owner or shared group and grant only the required directory search, read, or write access. For collaborative directories, a deliberate group plus setgid directory policy or a documented ACL is usually clearer than world-writable modes.

For stale variables, update the relevant tmux environment and open a new pane or shell; existing processes cannot have their complete environment rewritten from outside. For a mount or container mismatch, correct the mount, namespace, or user mapping. Re-run the original read-only inspection after the change so the fix is explained by a specific difference rather than by chmod 777.