LDAP Service breaks Users and Shares interface

Troubleshooting
1

Hi All,

I’m encountering similar issues as expressed toward the end of this message: Migrating from CentOS to OpenSUSE error with Users

I’m setting up a proof of concept/testing server (version 4.5.8-0 and fully zypper updated) and I’m encountering the following error when I enable the LDAP Service, connecting to an OpenLDAP server:

Unknown internal error doing a GET to /api/users?page=1&format=json&page_size=32000&count=

when I try to go to the Users page. Note: The Groups page works fine. Additionally, I get the same error when trying to edit a Share (clicking on the Share name in the list of Shares), or when trying to edit a Samba Share.

I believe I have the LDAP GUI settings correct. I can see all 14 of the LDAP users using getent passwd and the groups using getent group. I notice that LDAP based users/groups have an * rather than an x (like local users/groups) in the password space. But from what I read, that may just be because there isn’t any password information associated with them, yet.

I get the following information from the domain-status check:

sssctl domain-status ldap.mydomain.net
Online status: Online

Active servers:
LDAP: ldap.mydomain.net

Discovered LDAP servers:
- ldap.mydomain.net

While the connection seems active, I can’t login to the web interface with any LDAP user. I just receive “Login incorrect!”. (I’m not sure if an LDAP user is supposed to be able to login to the GUI or not.) There’s not a GUI based way for me to try and setup a share to be owned by an LDAP user, so I can’t test SMB access. In a shell session, I am able to “su” to the ldap users and get the correct response to “whoami”.

If I disable the LDAP Service, then the User page and Share pages work fine. It seems like there is some sort of problem with any page that needs to display a list of Users, whether it’s just a list, like the Users page, or a selection list, like in the Share-Access control tab.

I am happy to provide more information if needed, test possible solutions, or open a github issue on this, but wanted to check here first in case I’m just missing something that’s obvious to others.
Thanks!

3 Likes
2

Hi @bhotrock,

Welcome! Sorry to read you’re having an issue.

That’s definitely the way to go so thank you for taking the time to detail as much as you did here.

This one is indeed rather tricky to debug as it’s not something for which we have a reproducer at the moment. Let’s try to look at a couple of things nonetheless.

I agree with you that it seems to happen when trying to fetch users so let’s see if we can find what part of that is failing.
First, can we get the system users?

cd /opt/rockstor
poetry run python3 -c "from system.users import get_users;sys_users = get_users();print(sys_users)"

Does this properly list the LDAP users as well?

Also, would you happen to have some usernames that are on BOTH the local system (Rockstor) and the LDAP directory?

Let’s also try to see what the list of users returned should be:

  1. cd /opt/rockstor
  2. nano run_combined_users.py and paste the following:
import django

django.setup()


from storageadmin.views.ug_helpers import combined_users

users = combined_users()
#print(users)

for user in users:
    print(user.username)
  1. run with: poetry run python3 run_combined_users.py

On a side note, would you be able to paste the output of the following? This would check what SSSD is seeing.

cd /opt/rockstor
poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*" uint32:"0"
poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*@<your.fulldomain.com>" uint32:"0"
2 Likes
3

@Flox Just chipping in a little here.

Do your investigatory instructions not pertain to our testing channel only currently - where we are now on a Python 3 run. @bhotrock looks to be on a RC5 of 4.5.8-0 Release Candidate (RC5), i.e. just a few versions sort of our current last stable of 4.6.1-0 (Py2.7 based). But we of course have now moved (in part down to your own efforts), in testing channel updates only, to a progressively newer Python 3 base. I.e. your instructions specifying python3.

Hope I’ve not confused this thread via this interjection.

2 Likes
4

Thanks so much for the reply! Here are the results:

Here’s the output from that command. This response is the same whether the LDAP Service is running or not.

shares:/opt/rockstor # poetry run python3 -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'system'

I do not have any usernames on BOTH systems. I only have one local user and they are not in LDAP.

The output was:

shares:/opt/rockstor # poetry run python3 run_combined_users.py
Traceback (most recent call last):
  File "run_combined_users.py", line 1, in <module>
    import django
ModuleNotFoundError: No module named 'django'

Here are the results:

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*" uint32:"0"
method return time=1694523856.668428 sender=:1.23 -> destination=:1.28 serial=6 reply_serial=2
   array [
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1061"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1236"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/14181"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1238"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1240"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1234"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/9523"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1233"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/2858"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/13760"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1229"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1232"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1237"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1235"
   ]

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*@<your.fulldomain.com>" uint32:"0"
Error sbus.Error.Errno: 1432158243: Cannot parse input

Hopefully this will provide something useful. Thanks for the help!

1 Like
5

Hi Philip!

Thanks for jumping in on this! I would be happy to update to 4.6.1-0. I THOUGHT I was installing a stable version, but obviously didn’t get that right. I read a lot, and while I understand how the final testing build becomes the next stable release, it wasn’t completely clear to me how to tell what is considered a stable version.

Do I need to just start from scratch with 4.6.1-0, or is there a way to update to that from 4.5.8-0? If this all works out, I’m planning on getting the subscription, but haven’t done that yet since this is still a Proof-Of-Concept.

Thanks again!

6

Thanks @phillxnet for the correction here… I was a bit too focused on the SSSD bit here, unfortunately.

@bhotrock , my apologies for the inaccurate instructions. You can run the same instructions but make sure to replace python3 with python.
Also, good idea with running them with and without the LDAP service turned ON; it can be helpful in case they return an error when LDAP is ON.

Sorry again for my confusion earlier.

7

Just to keep you updated, I did figure out how to update to 4.6.1-0. So I’ll run through the troubleshooting listed by @Flox based on 4.6.1-0.

3 Likes
8

Thanks @Flox
Here are the results using “python”

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/rockstor/src/rockstor/system/users.py", line 38, in <module>
    from osi import run_command
  File "/opt/rockstor/src/rockstor/system/osi.py", line 55, in <module>
    SHUTDOWN = settings.SHUTDOWN
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 56, in __getattr__
    self._setup(name)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 39, in _setup
    % (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting SHUTDOWN, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

I get this same result both with and without LDAP running.

shares:/opt/rockstor # poetry run python run_combined_users.py
Traceback (most recent call last):
  File "run_combined_users.py", line 3, in <module>
    django.setup()
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/__init__.py", line 22, in setup
    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 56, in __getattr__
    self._setup(name)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 39, in _setup
    % (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting LOGGING_CONFIG, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

And lastly, I discovered that I hadn’t properly formatted the domain information in:

The result from that is:

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*@ldap.mydomain.net" uint32:"0"
method return time=1694535029.103214 sender=:1.74 -> destination=:1.97 serial=30 reply_serial=2
   array [
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1061"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1236"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/14181"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1238"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1240"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1234"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/9523"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1233"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/2858"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/13760"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1229"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1232"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1237"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1235"
   ]

I appreciate the help!

3 Likes
9

My bad… I forgot yet another crucial bit: you need to define the DJANGO_SETTINGS_MODULE first. This would thus be:

cd /opt/rockstor
export DJANGO_SETTINGS_MODULE=settings
poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"

My sincere apologies for all these errors on my end… I’m obviously not really focused lately.

2 Likes
10

No problem at all. I’m just really impressed by the team’s responsiveness!!
So here’s the output with LDAP running:

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
{u'mdavis': (1229, 1229, ''), u'dherr': (1234, 1234, ''), u'rpc': (492, 65534, '/sbin/nologin'), u'bmage': (13760, 13760, ''), u'at': (25, 25, '/usr/sbin/nologin'), u'dockremap': (489, 477, '/bin/false'), u'upsd': (493, 480, '/usr/sbin/nologin'), u'polkitd': (485, 472, '/sbin/nologin'), u'jlebman': (1232, 1232, ''), u'statd': (491, 65533, '/sbin/nologin'), u'shellinabox': (482, 468, '/bin/false'), u'lp': (495, 487, '/usr/sbin/nologin'), u'mail': (494, 481, '/usr/sbin/nologin'), u'rkirk': (1240, 1240, ''), u'jforman': (9523, 9523, ''), u'postgres': (490, 479, '/bin/bash'), u'messagebus': (499, 499, '/usr/bin/false'), u'pesign': (488, 476, '/bin/false'), u'ntp': (74, 474, '/bin/false'), u'sbillings': (2858, 2858, ''), u'nobody': (65534, 65534, '/bin/bash'), u'sshd': (484, 471, '/usr/sbin/nologin'), u'nginx': (483, 470, '/usr/sbin/nologin'), u'ouradmin': (14181, 14181, ''), u'systemd-timesync': (496, 496, '/usr/sbin/nologin'), u'mhoffman': (1235, 1235, ''), u'bradf': (1000, 100, '/bin/bash'), u'rjennings': (1233, 1233, ''), u'daemon': (2, 2, '/usr/sbin/nologin'), u'systemd-network': (497, 497, '/usr/sbin/nologin'), u'slolly': (1237, 1237, ''), u'postfix': (51, 51, '/usr/sbin/nologin'), u'chrony': (486, 473, '/usr/sbin/nologin'), u'asanderson': (1238, 1238, ''), u'bfindley': (1061, 1061, ''), u'avahi': (487, 475, '/usr/sbin/nologin'), u'bhannson': (1236, 1236, ''), u'root': (0, 0, '/bin/bash')}

bradf is the local user.
Without LDAP running:

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
{u'rpc': (492, 65534, '/sbin/nologin'), u'at': (25, 25, '/usr/sbin/nologin'), u'dockremap': (489, 477, '/bin/false'), u'upsd': (493, 480, '/usr/sbin/nologin'), u'polkitd': (485, 472, '/sbin/nologin'), u'statd': (491, 65533, '/sbin/nologin'), u'shellinabox': (482, 468, '/bin/false'), u'lp': (495, 487, '/usr/sbin/nologin'), u'mail': (494, 481, '/usr/sbin/nologin'), u'postgres': (490, 479, '/bin/bash'), u'messagebus': (499, 499, '/usr/bin/false'), u'pesign': (488, 476, '/bin/false'), u'ntp': (74, 474, '/bin/false'), u'nobody': (65534, 65534, '/bin/bash'), u'sshd': (484, 471, '/usr/sbin/nologin'), u'nginx': (483, 470, '/usr/sbin/nologin'), u'systemd-timesync': (496, 496, '/usr/sbin/nologin'), u'bradf': (1000, 100, '/bin/bash'), u'daemon': (2, 2, '/usr/sbin/nologin'), u'systemd-network': (497, 497, '/usr/sbin/nologin'), u'postfix': (51, 51, '/usr/sbin/nologin'), u'chrony': (486, 473, '/usr/sbin/nologin'), u'avahi': (487, 475, '/usr/sbin/nologin'), u'root': (0, 0, '/bin/bash')}

With LDAP running, here are the combined_users:

shares:/opt/rockstor # poetry run python run_combined_users.py
asanderson
at
avahi
bfindley
bhannson
rkirk
bmage
bradf
mdavis
chrony
daemon
dherr
jlebman
dockremap
ouradmin
jforman
slolly
lp
mail
messagebus
mhoffman
nginx
nobody
ntp
pesign
polkitd
postfix
postgres
rjennings
root
rpc
sbillings
shellinabox
sshd
statd
systemd-network
systemd-timesync
upsd

I’ve mangled the usernames since this is a public forum. combined_users originally displayed in alphabetical order.

And without LDAP running:

shares:/opt/rockstor # poetry run python run_combined_users.py
at
avahi
bradf
chrony
daemon
dockremap
lp
mail
messagebus
nginx
nobody
ntp
pesign
polkitd
postfix
postgres
root
rpc
shellinabox
sshd
statd
systemd-network
systemd-timesync
upsd

Let me know what’s next. Thanks!

3 Likes
11

Thanks a lot, @bhotrock …

So everything looks OK so far, which is both good and puzzling.

That being said… I’ve “played” a lot more with that, tried a few things, and I am now in a situation where I do get the same error as you do. BUT, given this may very well result from different causes, let’s see if it is actually the same as you.
Could you please do the following?

  1. enable debug mode:
cd /opt/rockstor
export DJANGO_SETTINGS_MODULE=settings
poetry run debug-mode ON
  1. Open your browser developer tools (usually with Ctrl + Shift + I). The lines below may differ slightly depending on the browser but I think they should be fairly similar; below is what I have in Firefox.
  2. Go to the “Network” tab.
  3. In your browser, navigate to the “Users” page in Rockstor. You should see a single line in the Developer tools window (“Network” tab) with a 500 return code. It should be the GET call to users?page=...
  4. Click on this error, and you should now be able to see more details about that request.
  5. These details should be organized in multiple tabs, click on the “Response” tab. Do the first few lines look as what I have (see below)?
    image
    image1459×661 106 KB

Let me know if you cannot find this information due differences in browser and I’ll try to walk you through it better.

2 Likes
12

Thanks for your work on this. Glad you were able to duplicate it. Yes, they look the same. See attached screenshot.

Screen Shot 2023-09-12 at 4.57.52 PM
Screen Shot 2023-09-12 at 4.57.52 PM1595×595 95.3 KB

1 Like
13

Thanks a lot for looking at it and confirming!

So, it seems we have some issue with LDAP users that belong to a group with a gid that does not exist on the Rockstor machine. I still don’t know exactly at what steps we fail here but at least we now seem to have a reproducer so I can dig deeper into it.
I’ve had to dig quite a bit into SSSD and AD in the past few days so I’ll keep looking into this LDAP issue; hopefully I’ll figure out how exactly we are failing here.

Thanks for your help and patience, that is extremely helpful!

1 Like
14

I wanted to mention: The users in LDAP don’t currently have any LDAP group memberships. The memberOf infrastructure exists and I have one group in the tree, just for testing purposes, but no users are a member of that group.

I believe we’re just setting the posixAccount gidNumber to be the same as the uidNumber. I THINK this would be the user’s “primary” group. If it would make more sense to set that to a specific group, that would exist in Rockstor, I could do that. I’d probably just create a “staff” or “users” group. (Not sure if “users” already exists or not.)

I’m not really interested in creating/populating groups and their memberships from LDAP, and have planned to manage group membership directly on the Rockstor server. I’m really only looking for Rockstor to be able to authenticate using the LDAP provided username/password.

Just wanted to make sure you had a clear picture of what’s happening on my side of things. Thanks again for all the help!!

3 Likes
15

@Flox I just wanted to confirm the following:
I changed each user’s gidNumber in OpenLDAP to 100, for the “user” group, which matches my local Rockstor account. I then disabled the LDAP Service, cleared the sssd cache, re-enabled the LDAP Service and verified that each user was showing as gid 100 using getent passwd. At that point, the error on the Users page went away and the LDAP users were listed on the Users page, under Other system users.

So I think you’re on the right path with the issue relating to nonexistent gids. However, it’s interesting that LDAP groups don’t have this same issue. My one LDAP group has a gidNumber of 2000 and that shows up without issue.

While I could move forward with this work around, I’m wondering if you could confirm something for me: Will this impact the use/security/permissions of private user home directories within Rockstor?

Also, is there a way to “promote” an LDAP user so they can login to the Rockstor Web UI (like checking the box when manually setting up a new user?

Thanks again for your help!

3 Likes
16

Hi @bhotrock,

Thanks a lot for going through all that trouble; that is an excellent confirmation indeed!

The TL;DR is that we are wrongly assuming that a LDAP user belongs to a LDAP PosixGroup and we thus fail to get a groupname when querying the associated gidNumber. This is why we get the error you saw.

This is not intentional but a result of a “particularity” for LDAP users that we did not account for. This was tested with Active Directory users (which do have associated groupnames, and thus the process worked) but not with LDAP. This was entirely my doing, though, so thank you so much for bringing this to light.

Now, for the details:
You were on point when you noticed that this error appears in all pages where we fetch users. This is usually done from our front-end where we fetch a UserCollection. For instance:

When we fetch this UserCollection, we “collect” all entries from our User model through the /api/users API endpoint:

This in turn trigger our back-end:

There, you can see that we return all entries of our storageadmin.models.user model via combined_users(); this is why I originally wanted to see what it returned for you.

Now, when we fetch our User model entries, we also trigger the following that we use to get the groupname:

The first part of this tries to use the grp python library to get the groupname but fails as expected for an LDAP/AD user. We catch this error and then try again using InfoPipe which uses SSSD to get that information from the LDAP/AD user. This works for an AD user. For an LDAP user, however, we fail because the gidNumber will not correspond to a posix group that SSSD can see unless it is set as a objectClass: posixGroup in the LDAP server. When no group is found for that gidNumber, InfoPipe returns the file not found error that you saw above.

To resolve this, I can think of (at first):

  • catching that infopipe error and return the gidNumber as groupname. This might be problematic down the line if Rockstor expects a true name here. I’m unsure of that, however, so it would need more investigation here.
  • catching that infopipe error and do nothing. Groupname would be empty; we would need to verify it does not cause more problems, though, as for the first option.

Interesting indeed… would this group be a objectClass: posixGroup group? Does it show in getent group and getent group -s sss?
Note that we fetch groups a bit differently than we fetch users, though, so that’s probably why you see it without a problem in the Groups page UI.

Not that I can think of, no. This would need to be verified though. Being able to log in to Rockstor’s webUI is only intended for “administrator” users, but it is true that these users being from LDAP could be a possibility.

With this workaround, my understanding is that your LDAP users would belong to the gid 100 (users) primary group. As a result, you can use that group to control permissions in the Shares UI (Shares — Rockstor documentation). Let me know if that answers your question.

I’m more than open to integrate your needs, though. I’m personally not an LDAP “user” so feel free to describe as much as you’d like what you would need or how you would envision using LDAP in Rockstor. We’re always seeking user feedback on what is really needed and this kind of feedback is particularly needed for AD/LDAP; this thread and participation is thus particularly appreciated.

2 Likes
17

Thanks @Flox !!

Yes, this is a posixGroup. And it does show up in getent group and in getent group -s sss.

I’m not sure if it’s “standard” for the uid (uidNumber) and gid (gidNumber) to match or not. I have seen some systems that are setup that way, and others that are not. I THINK that some systems may use a user’s “private” GID (the one that matches their UID) as a way to provide access to and security for a user’s “home” directory. However, I’m not CERTAIN of any of this. :grin: I’m not sure how Rockstor works with home directories, since I haven’t been able to work with these LDAP users until now. I was mainly just wanting to verify that if every LDAP user’s primary group is 100, that they will still be able to have a private home directory share, with access controlled by UID rather than GID. I hope that makes sense. I’m pretty sure that will work, but haven’t had time to test it out yet.

Thank you again for all your work on this! Assuming this Rockstor “proof of concept” ends up working for us, I’ll be happy to help with any LDAP based testing in the future. Again, I’m just very impressed with the responsiveness of your team!! Great job!!

3 Likes
18

Good, that makes sense, then!

As you said, it is dependent on the distribution–to the best of my knowledge. For instance, in our CentOS days, the default when creating a new user account was to have a new uid and gid created, and thus identical. In openSUSE, the default is to create a new uid and set the default gid to the users group (gid: 100). That being said, it feels like there may be some standardization towards the former as I’ve seen, for instance, talks from the openSUSE folks to move away from the default gid:100 to a dedicated uid/gid for each new user (might be related to the security aspect you mentioned, for instance). Not sure if/when that would happen, though. All of this to say that it really depends.

You should be able to set the LDAP user as owner of a Share and then limit permissions for that Share as you wish at the owner level (Shares — Rockstor documentation). If you remove any permission to the Group or Other, then the Share should remain accessible to the owner only.

Note that there also are more options available to you with access control lists (Access control lists in Linux | Security and Hardening Guide | openSUSE Leap 15.5). While we do not offer a GUI for these yet, this is something that has been brought up already (ACLs on shares request · Issue #981 · rockstor/rockstor-core · GitHub) and I recently had to get myself a bit more acquainted with those (Access control with Active Directory and group based permissions - #9 by Flox) so personally, my interest in seeing these integrated has grown quite a bit.

By the way, what would be the workflow about which you are thinking with regards to home directories of your LDAP users? You would like to have their home dir created on their workstation(s) when they log into them, but have the data stored in Rockstor? Something else?

1 Like
19

A corresponding issue has been created in our rockstor-core repo:

2 Likes
20

A pull request with a fix has now been submitted:

1 Like