Can I change the permissions used by NextExplorer?

Hi,

I installed NextExplorer on ZimaOS.

Is it possible to change the permissions or the user/group that NextExplorer uses to access files?

At the moment, I can create new files, but I cannot edit or save some existing files because of permission errors.

Is there a recommended way to configure NextExplorer so it has the required permissions to edit existing files?

Thanks!

Hi Isanto

Yes. I tested NextExplorer v2.2.7 on ZimaOS, and it supports changing its runtime user and group through PUID and PGID.

The configuration is:

environment:
  - PUID=1000
  - PGID=1000

However, 1000:1000 is only an example. The correct values must match the numeric ownership or shared group permissions of your existing files.

Because you can create new files but cannot save some existing files, I believe those particular files have different ownership or permissions. It could also be caused by the mount options if they are stored on NTFS, exFAT, SMB or NFS.

Changing PUID and PGID controls the identity NextExplorer uses, but it does not automatically repair existing file permissions. I would not use recursive chmod 777, change ownership across the entire disk, or run the container as root.

Please post the output of these commands first. Replace nextexplorer if your container has a different name:

docker inspect nextexplorer --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -E '^(PUID|PGID)='
docker inspect nextexplorer --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

Also provide the exact path of one file that cannot be saved. We can then check that file’s numeric ownership and permissions and determine the correct PUID, PGID or group configuration without changing unrelated files.

One ZimaOS-specific warning: verify the container receives PUID=1000, not PUID="1000" with literal quotation marks. Literal quotes cause NextExplorer’s user-mapping step to fail.

Hi gelbuilding,

Here is the requested information:

PUID=1000
PGID=1000

Mounts:

/DATA/AppData/nextexplorer/config -> /config
/ -> /mnt/NAS
/DATA/AppData/nextexplorer/cache -> /cache

The entire host filesystem is mounted to /mnt/NAS.

New files can be created, renamed and deleted without any problem.

However, some existing files cannot be edited or saved.

One example is:

/media/sda0/AppData/rss2/framework/views/014058e7acf036a40462ad2752ef38bb.php

Could you check whether this looks like a permission/ownership issue or something in NextExplorer itself?

Thanks, this narrows it down.

PUID=1000 and PGID=1000 are configured correctly. Since NextExplorer can create, rename and delete files, the application and bind mount are writable. This specific failure is more likely the ownership or permissions of the existing file.

The path also appears to be a generated framework view belonging to the rss2 application. We should not change its ownership until we confirm which user that application requires.

Please post these two outputs:

stat -c 'Path=%n Owner=%U(%u) Group=%G(%g) Mode=%A(%a)' '/media/sda0/AppData/rss2/framework/views/014058e7acf036a40462ad2752ef38bb.php' '/media/sda0/AppData/rss2/framework/views'
findmnt -T '/media/sda0/AppData/rss2/framework/views/014058e7acf036a40462ad2752ef38bb.php' -o TARGET,SOURCE,FSTYPE,OPTIONS

One other concern: mounting / to /mnt/NAS exposes the entire host filesystem to NextExplorer. I strongly recommend replacing that later with only the specific storage folders you need.

Thanks. Here are the results:

Path=/media/sda0/AppData/rss2/framework/views/014058e7acf036a40462ad2752ef38bb.php
Owner=root(0)
Group=samba(1000)
Mode=-rwxr-xr-x (755)

Path=/media/sda0/AppData/rss2/framework/views
Owner=root(0)
Group=samba(1000)
Mode=drwxr-sr-x (2755)

The filesystem is Btrfs:

FSTYPE=btrfs
OPTIONS=rw,...,noacl,...

Since the file is owned by root with mode 755, a process running as UID 1000 cannot modify it. Does NextExplorer support temporarily elevating privileges for editing such files, or would you recommend a different approach?

I need to clarify one point.

NextExplorer is able to create new folders and new files anywhere I have tested. Those newly created files can be edited, renamed and deleted without any problem.

The problem only affects files that already existed before I started using NextExplorer. Those existing files cannot be edited or deleted.

For example, the PHP file I posted is owned by root:samba with mode 755, while files created by NextExplorer are fully editable afterwards.

So the issue is not that NextExplorer cannot write. It can write, but it cannot modify certain pre-existing files.

Thanks, that clarification actually confirms the diagnosis.

NextExplorer is behaving correctly as 1000:1000:

  • New files are created by NextExplorer and are therefore writable by it.
  • The existing PHP file belongs to root:samba with mode 755.
  • Group samba is GID 1000, but group permissions are only r-x, with no write permission.
  • Its parent directory is 2755, so group 1000 also cannot rename or delete files there. Rename and deletion require write permission on the parent directory.

There is no need to change NextExplorer’s PUID or PGID, and I would not run it as root. The permissions of pre-existing files need to be handled according to who owns and manages each directory.

For ordinary shared folders, the appropriate solution is normally group-write permissions for group 1000. However, this example is inside rss2/framework/views and the hashed filename strongly suggests it is generated by the rss2 application. I would not recursively change that AppData directory or edit the generated file through NextExplorer. The safer solution is to edit the original source file or configure rss2 to create group-writable files if that is required.

So this is not a NextExplorer editing fault. It is the expected difference between new files owned by UID 1000 and existing application files owned by root.

My goal is to use NextExplorer as a real file manager and editor on ZimaOS.

I want to be able to edit, rename and delete existing text-based files such as:

.txt
.md
.json
.yaml
.yml
.conf
.log
.xml
.ini
.sh
.py
.js
.css
.html

At the moment, I can create new files and folders, and those are fully editable.

However, many files that already exist on the NAS are read-only from within NextExplorer, even though they are plain text files.

Is this an intended limitation, or should NextExplorer be able to edit existing files when the permissions allow it?

The built-in ZimaOS File Manager is too limited for system administration.

I often need to edit existing configuration files such as .json, .yaml, .conf, .sh, .md, .html, .css, etc.

That is why I started testing NextExplorer. My goal is to have a full-featured file manager and text editor directly inside ZimaOS.

Your clarification makes the goal clear.

This is not a limitation based on file age or extension. NextExplorer should edit existing files whenever its Linux user has permission.

The difference in your case is ownership:

  • Files created by NextExplorer belong to UID/GID 1000:1000, so it can modify them.
  • Existing files such as root:samba with mode 755 give group 1000 read and execute access, but no write access.
  • Renaming or deleting also requires write permission on the parent directory. A directory with mode 2755 does not provide that.

NextExplorer does not provide temporary root elevation. I would not run it as root while / is mounted, because that would effectively give a web-based file manager unrestricted control of the ZimaOS host.

I suggest separating the two use cases:

  • For normal NAS folders that NextExplorer should manage, use a shared group such as GID 1000, group-write permissions, setgid directories and an appropriate umask such as 0002.
  • For system files and application-generated files under AppData, use the terminal, SSH or the application’s supported configuration method. Changing permissions recursively across those directories could break other containers.

So yes, NextExplorer is a full file manager and editor for files it is permitted to manage. It is not designed to bypass Linux permissions or act as a root-level ZimaOS administration editor.

I completely agree that NextExplorer should not bypass Linux permissions or run as root.

My goal is different.

I would like a file manager that complements the built-in ZimaOS File Manager by providing access to system locations that are currently hidden, such as /etc, /var/lib/casaos, /var/lib/extensions, and other administration paths.

I don’t want to bypass Linux permissions. I just want a convenient way to work with files that I already have permission to access, without having to switch to SSH every time.

Thanks, that makes sense. In that case, I believe NextExplorer can complement the ZimaOS File Manager exactly as you describe.

Any host path bind-mounted into NextExplorer will be visible, while normal Linux permissions remain enforced. The important distinction is that NextExplorer operates as UID/GID 1000:1000; it does not inherit the root permissions you may have through SSH.

Your current / -> /mnt/NAS mapping already exposes locations such as /etc, /var/lib/casaos and /var/lib/extensions. However, I would still recommend mounting only the administration paths you need:

  • Use read-only mounts for general inspection.
  • Use read-write mounts only for specific directories where UID/GID 1000:1000 already has write permission.
  • Keep root-owned files such as root:samba 755 read-only unless their owning application is intentionally configured to allow group editing.

That gives you the convenient browser-based file manager you want without bypassing Linux permissions or giving NextExplorer root access.

Thanks for the explanation and for taking the time to help.

The issue is resolved now. I eventually realized that the built-in ZimaOS editor saves files with Ctrl+S. I had been looking for a Save button the whole time, so I mistakenly thought saving wasn’t implemented.

I really appreciate your help and your detailed explanations. They helped me better understand how NextExplorer and the Linux permissions work.

Thanks again!

1 Like