User Management Issues and Feature Requests

I’ve collided with some issues and bugs regarding user management. These aren’t severe but are annoying, and the changes required to remedy them are minor.

Issue One: UID Assigned to Admin User on First Installation
When Rockstor is first installed, the Web UI starts on a page that gives the Rockstor appliance a name and specifies the name and password for the Admin user. This user is given the UID 1000 automatically. This UID causes problems when Linux workstations connect to this appliance via NFS. The solution: give the initial Admin user a different UID like 5000.

Detailed Explanation
Modern Linux distros typically give the user a UID of 1000 by default. So on my workstation, user “Walt” has UID of 1000. User ID mapping through NFS is by UID not by name string, so to assign storage on the Rockstor appliance to user “Walt” I’d have to create a user named “Walt” and give it a UID of 1000. But 1000 is already taken. The workaround is to create a new Admin user account with a different UID like 5000, then log out and log back in as that new user, then delete the original Admin user account. Then create a user account named “Walt” and give it UID 1000.

Issue Two: No Way to Delete a Non-Admin User
The Web UI does not have any ability to edit, modify or delete non-Admin users. The solution: at the very least, provide a trash-can icon like the Admin users have, so users can be deleted (and later re-created with modifications if needed).

Detailed Explanation
I reset the installation by deleting the /opt/rockstor/.initrock file. This didn’t remove the Admin user accounts but demoted them to “other” users without Admin capability. So when doing initial setup of the Admin user, I was not able to use the usual admin user names, “admin” and “administrator” previously defined but had to give some other name. Once in the web UI there isn’t any way to remove those user names, promote them to Admin users or otherwise edit UIDs and GIDs. Other than to drop out of Rockstor and log in as root.

Issue Three: Samba Admin Users
This one is arguably not a bug, but it caused issues and required hours of debug so I’ll describe it here in the hope that a better way can be found. The root cause of the problem was that if a Samba export designates an Admin User, that user accesses the filesystem as root, and every file it creates is given ownership of root:root. The optimum solution is debatable but I’d argue for deleting the ability to designate an admin user at all.

Detailed Explanation
My initial usage of Rockstor was in a Windows-only environment. Same username and password across all computers. So when I set up Samba I casually threw in my username as the Admin user for each Samba export. I didn’t realize initially, that each share when first created, is given default ownership of root:root (that information is rather hidden on the Shares page, along with the means to edit it). I assumed that the files I was creating from Windows computers had my username as owner. I can read or write all files, so no problem, right?

The problems surfaced when I started migrating to Linux recently. Samba works like crap on Linux, so I set up NFS. But that quickly ran into sharing issues. I did a bunch of experiments and eventually tracked down the issue that Samba was converting my user account to root when accessing the file system. The entire file system was owned by root, not by the user account that I’d set up.

Giving a user unrestricted root access is dangerous. I suppose that in some corporate environments there is a need for a user with root access to snoop into every user’s account, so there’s an argument in favor of having the facility to define a Samba Admin user. But there are limited things that such a user could do. I don’t know of any way that such a user could chown files or release a lock on a file for a user for example. So it doesn’t replace superuser login through a terminal. Since any file that the Samba Admin user writes would have root ownership, this admin account is unsuitable for use for regular file storage.

I’d just get rid of it entirely. But if not, at least put Admin users of Samba (and NFS?) onto a page of their own specifically for designating Admin users, along with enough text to caution that Admin user accounts should only be used for administrative tasks and not for routine file storage. And I’d have it refer the user to a documentation page that explains things in detail.


@Walt Some nice points here:

We dont do this actually. Root is required to access block devices, from there on up, through the kernel etc there are mechanisms to authenticate etc. The Admin user that you setup during Rockstor setup is not root. And network access is via normal users, not root. Once can delegate access via a network layer or a user layer with filesystem priveledges etc, we do a bit of both. But via Samba we use samba to manage that access. And the same for NFS.

But you are still free to set user/group etc on each share to take advantage of filesystem level user restrictions etc. And of course the samba extensions re AD etc. So many levels and I think a confusion here is you thinking that our Admin user setup during Rockstor Web-UI setup is not a normal user. They are. The root user is setup during initial install however as that is obviously required for system stuff.

Yes, there are definitely issues on the client side of things in most Linux desktop setups. We had this surface a few years ago here on the forum. But on the server side (Rockstors bit) it’s as fast as one can expect SMB to be, given our Copy-on-Write underlying filesystem.

Nice report of findings thus far. I’ll leave the Samba admin user feedback to others here that are more knowledgeable than me in this area.

Note that we do provide a Web-UI interface to control ownership of rights of shares:
See for example our Access control doc section:

I’ll leave further comment on your findings for others given my current time constrainst.

Hope that helps and thanks for taking the time to forum your suggestions in this area. Always appreciated to have considered feedback.


To chime in here a bit: I hit upon this fact as well recently since I was (and still am) struggling with NFS permission issues due to a lack of knowledge of Linux.

I noticed this in the documentation:

Rockstor supports local user adds, edits and deletes. All local users added by Rockstor have UIDs starting from 5001.

This seems to not hold true (anymore?). I’ve been meaning to ask if the documentation was outdated or if this was a bug to @phillxnet and @Flox.


I noticed that too. UIDs used to start at 5000 in earlier versions. I’d welcome having it do that again (per my reasons previously given).

AFAIK, Linux/Unix automatic assignment of UIDs works by determining the highest UID currently in use and then incrementing it by one. So if you create a user and assign that user a UID of 17961, the next user that you create will be automatically given a UID of 17962 unless you specify a different one.

1 Like

@Walt, @stitch10925,

My apologies for the delay in getting back to you here… this was an extremely busy time at work and couldn’t get a minute to do any meaningful work on Rockstor.

Good find! This definitely does not hold true anymore so it should be updated. Would you mind creating an issue to update the docs? The entire section on “Users” would benefit from a refresh, actually:

Correct. I just tested as follows in the Rockstor webUI:

  • create a new user testuser1 without specifying UID/GID: gets UID: 1001, GID:100
  • create a new user testuser5000 without specifying UID/GID: gets UID: 5000, GID:100
  • create a new user testuser5001 without specifying UID/GID: gets UID: 5001, GID:100
  • create a new user testuser5002 without specifying UID/GID: gets UID: 5002, GID:100

Inadvertently, this screenshot addresses one of your points below:

As you can see in the screenshot above, we actually do offer the possibility to delete system users that were previously created via Rockstor. That emphasis matters of course, as your detailed explanation (thanks for taking the time to do that, by the way; always helpful!) indicates that your suggestion stems from a manual reset of Rockstor and its database, which explained why that user was not detected as having been created by Rockstor previously (and thus cannot be managed by Rockstor). I would see this as an opportunity to think about a way to offer/document a way to do a proper manual reset of Rockstor. This might interest some users who would not necessarily want to do a reinstall. @phillxnet paid particular attention in simplifying Rockstor install so that such events would be as quick and painless as possible and that is also part of the rationale for our current installer choice (, but I can understand that some users may appreciate the intermediate solution of a reset. If we document/offer such a reset mechanism, we can then clearly address this shortcoming about deleting the previous admin user from the system.

I would of course be reluctant to present the user with an easy way to delete system users as these are users that were created by the various system packages and services and thus required for their proper functioning. It could be perceived as an over-reach from Rockstor if it could delete such users.

At first glance, I don’t really see a problem with using 5000 as first UID but it seems like something that would need to be carefully thought out first, though. I wonder too if your issue with NFS could have a more “proper” solution but I admit that I have limited experience with NFS troubleshooting myself (it has been a while). I know, for instance, that openSUSE offers a way to have name resolution but that seems to be for NFS clients that do not understand UIDs (

That is something we should definitely make a lot more clear in our docs (and also point to these docs from the Samba export creation dialog). Would you mind creating an issue for that? (

1 Like