Auto Creation of Linux Home Directories for SAS Users

In a previous post I’ve described a method for configuring Active Directory Authentication for SAS® on Linux (with realmd). One of the packages that’s installed is oddjob-mkhomedir. This package normally handles any requirement for auto-creating home directories for those AD users on Linux. Unfortunately it doesn’t seem to get used by the SAS Object Spawner. I ran into this issue again today when logging into SAS Studio 4.2 as an AD user on the SAS Viya™ 3.2 platform. I wasn’t able to login because the AD user’s Linux home directory didn’t exist and hadn’t been auto created. After manually creating the home directory the login succeeded. I would rather get auto-creation working so I wouldn’t need to manually create home directories for each SAS user that was likely to use SAS Studio. Thankfully I was able to find a solution that I’ll describe in this post.

This non-auto-creation issue is something I’ve encountered and investigated before. Amusingly, when researching the problem again today, I stumbled over a comment I’d made about it, and since forgotten, on an old SAS Communities thread: SAS 9.4 GRID authentication with PAM. Thank goodness for SAS Communities! In that post I described my findings with respect to the SAS 9.4 platform:

I looked into this further today and did some testing and it seems that pam_oddjob_mkhomedir is not firing from the sasauth PAM config. Whilst I can successfully have home directories auto-created, via pam_oddjob_mkhomedir, when using ssh and su, it is not working for sasauth. Digging into this further it looks like perhaps sasauth as used by the object spawner is not triggering the session initialization where pam_oddjob_mkhomedir does its work (as does pam_mkhomedir). There are 2 things that seem to suggest this: 1) All of the PAM config samples I have seen in the SAS documentation and usage notes only include the auth and account groups (I have session in my config for testing) 2) the sasauth.conf file has a section related to PAM_SETCREDENTIALS and Centrify where it says: “Centrify requires that pam_setcred be called. sasauth traditionally has not done this, since there’s no “session” like an interactive login.” Perhaps it is not using pam_open_session either? Whilst I can understand that there might not be a session when sasauth is used by the SAS Metadata Server, when it is used by the SAS Object Spawner to spawn SAS processes as that user, that sounds like a session to me.

A home directory is required for SAS users on Linux servers where a standard SAS Workspace Server is launched by the SAS Object Spawner using the identity of the requesting SAS user. In addition to the SAS Studio on SAS Viya example mentioned at the beginning of this post, this also happens with the SAS 9 platform when users run projects in SAS Enterprise Guide, run jobs in SAS Data Integration Studio, and run programs in SAS Studio.

If you have the oddjob-mkhomedir package installed you will see the following line in some of the PAM config files in /etc/pam.d:

session    optional    pam_oddjob_mkhomedir.so umask=0077

After a user has been authenticated and an account confirmed, a session may be initialized. At this point the pam_oddjob_mkhomedir.so module will do its work and create a home directory for the user (if it doesn’t already exist). This session doesn’t seem to be triggered by the sasauth module. If you look at the /etc/pam.d/sasauth file you will see it only references auth and account – no session. Simply adding a session line doesn’t help because, as described above, it doesn’t seem to get used by sasauth. You can find out more about sasauth and configuring PAM authentication for SAS in Chapter 3 of the Configuration Guide for SAS 9.4 Foundation for UNIX Environments. I’ve just noticed that the config guide specifically states that “Session and password modules are not supported”. For more info on PAM visit http://www.linux-pam.org/.

The auto-creation of home directories is such a time-saver that I wanted to try and find a solution to this issue. I found inspiration in this Server Fault post: RHEL 6.5 web application PAM AUTH pam_oddjob_mkhomedir. I thought I would piggy-back on the end of the account module-type for sasauth using the pam_exec.so module to call a custom script that sends a DBus message to trigger the pam_oddjob_mkhomedir module.

I created a script /etc/pam.d/sasauth-mkhomedir.sh with the following contents:

#!/bin/sh
dbus-send --system --dest=com.redhat.oddjob_mkhomedir --print-reply / com.redhat.oddjob_mkhomedir.mkhomedirfor string:"$PAM_USER"

… made it executable:

chmod +x /etc/pam.d/sasauth-mkhomedir.sh

… and then added the bold line below to the end of the /etc/pam.d/sasauth file (at the end of the existing account section):

#%PAM-1.0
auth       include  system-auth
account    include  system-auth
account optional pam_exec.so /etc/pam.d/sasauth-mkhomedir.sh
#account optional pam_exec.so debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/sasauth-mkhomedir.sh

The commented line at the end is an alternative form if you need debugging and logging.

I found this worked immediately and nothing needed to be restarted. If you decide to try this out then take care when customizing PAM configuration. Authentication changes can have a significant impact and, of course, should be thoroughly tested in a development or playpen environment.

I have tested with with SAS Studio 4.2 on SAS Viya 3.2 as well as the older SAS 9.2 platform. If authentication succeeds and the home directory doesn’t exist then it will be auto-created. If authentication fails then the script is not called and no attempt is made to create a home directory for the unauthenticated user.

Whilst this solution is not ideal, in the absence of session support in sasauth, it is a method that works in my environment, and might possibly work for you too. If you have any comments, suggestions, or further insights on PAM, sasauth, and the auto-creation of home directories, please leave a comment below.

Update (14Feb2018): If you’ve found this blog post useful in helping to auto-create home directories for SAS users then please consider voting up my SASWare Ballot suggestion on SAS Communities: Make sasauth trigger PAM session handling to allow auto-creation of home directories by PAM modules.

47 thoughts on “Auto Creation of Linux Home Directories for SAS Users”

  2. Very elegant, I like it! I’ve seen a couple of hacky ways of achieving this with Centrify based auths. This is the *correct* way of implementing this.

  3. Thanks for your thoughts Nik. I don’t know about it being ‘correct’ but it does the job :)

    Personally, I would prefer it if the sasauth module triggered PAM session handling, for the SAS Object Spawner client, and then no changes to the PAM config would be required – it would just work. I’ll try to remember to post a SASware Ballot idea for it.

  5. Readers might also be interested in this associated LinkedIn discussion: https://www.linkedin.com/hp/update/6265492763559763968

    In particular Greg shares his thoughts on this topic as part of the wider topic of user provisioning.

    There is also the point that Samba does not, by default, obey PAM’s account and session management directives, and so the use of Samba would not trigger home directory auto-creation with oddjob-mkhomedir. In case that LinkedIn link get broken in future, I’ll leave the smb.conf directive that is supposed to enable that here for future reference:

    obey pam restrictions = yes

    When I get a chance to try it out, I’ll add another comment with findings.

  6. It doesn’t work. My sasauth doesn’t even include this script because no log file appear in tmp file.
    My error contains message: The launch of the server process failed because of an invalid or inaccessible SASUSER library

  7. Ok it’s working

    I was using centrify, I updated sasauth and removed ‘session’ & ‘password’ groups and of course I had to install
    yum install oddjob oddjob-mkhomedir (from: https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ ) but like I said.. it seems that it wasn’t working at all I mean this -> “account optional pam_exec.so debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/sasauth-mkhomedir.sh” wasn’t even included and executed. So I ran into that: https://bugzilla.redhat.com/show_bug.cgi?id=634356 because I thought that something is wrong with oddjob-mkhomedir. And I think you should put those information also:

    Steps to Reproduce:
    1. yum install dbus oddjob oddjob-mkhomedir
    2. service messagebus restart
    3. service oddjobd restart

    After that the service oddjobd started to working and was visible for dbus.
    Adding to oddjobd to startup was only a formality.

    chkconfig oddjobd on

    It would be nice to mention about that you need to start oddjobd after installation. Then I was able to see my log in /tmp/sasauth-mkhomedir.log

    It works.

  8. Thanks for posting your notes Konrad. I did’t need to manually start oddjobd as I assume it was either started post-installation or after a machine restart.

  9. Hi Paul,

    We have a requirement where in access need to be provided to users who reside on mutiple active directories for our SAS 9.4 application.
    My question here is,whether steps mentioned under http://support.sas.com/kb/49/432.html would be sufficient or else third party tools like Metacoda Plugins or Quest Authentication Service need to installed to achieve the requirement.If yes,can you please guide to correct documentation or link.
    Also advise how different would be the steps for Microsoft Active Directory (AD) Domains contained within a single Forest or multiple domains from multiple trusted forests.

  10. Hi Ramakrishna,

    Firstly, Metacoda Plugins and Quest Authentication Service are used for different purposes. Quest will help you with configure the Linux host for authentication against Active Directory (AD). Metacoda Plug-ins will help you populate SAS metadata with the required identity (user and group) information from AD.

    For authentication, in addition to Quest, there are also other software packages you can use, both open source and commercial. In the commercial arena, I have had several people recommend Centrify to me. I haven’t had a chance to use it as yet, but it does seems popular. If you want to find out if Quest or Centrify support multi-domain and cross-forest authentication it would be best to contact the respective vendors. You might also want to investigate RedHat FreeIPA/IdM for its AD integration options.

    In my CentOS 7.3 environment, I have been using realmd (sssd) – see https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ and https://platformadmin.com/blogs/paul/2015/01/iwa-sas-94m2-linux/ In the comments on the second post you will see that I have been able to use this method to authenticate with 2 domains in the same forest but not cross-forest authentication as yet. Additionally, whilst I can get IWA working with the primary domain, I have so far been unable to get IWA to work for users in secondary same-forest domains (I get “The destination buffer size was not sufficient for the requested password” and “Access denied” messages that I need to investigate further). When I get some time I will upgrade to 7.4 and see if I can resolve these issues.

    You might also want to follow a recent discussion in SAS Communities at https://communities.sas.com/t5/Administration-and-Deployment/ObjectSpawner-Authentication-for-Secondary-Domain/td-p/388790 where alexal, a SAS employee, mentioned that the recent RedHat Enterprise Linux 7.4 has a version of sssd that supports multi-domain AD-based login with unqualified userids (short names).

    Once you have authentication configured, for SAS identification, Metacoda Plug-ins can be used to synchronise AD users and groups into SAS metadata, for single domains, multiple domains in the same forest, and multiple domains in multiple forests. You can see an overview of each these scenarios at https://metacoda.github.io/idsync-utils/topics/ad-domains/

    I hope this helps.

    Cheers
    Paul

  11. Thanks alot for detailed explanation. Iam clear with these tools usage now.
    Do you think without tools like above,can we achieve authentication just by PAM when we have multiple multiple Active Directories?

    We would using either Linux 5 or 6 Operating systems.
    Can you please guide me to any documents/URLs for PAM authentication or approach to be followed for such configurations would be very useful.
    Below links I have already referred.But they have verified limited information.

    http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf
    http://support.sas.com/kb/49/432.html

    Thanks in advance

    Ramakrishna

  12. Hi Ramakrishna,

    It depends. For simple single domain environments, probably yes. For multiple domains within the same forest, maybe, depending on skills, versions, requirements for login formats and IWA etc. For multi-domain multi-forest maybe not. If you want more confidence in success and the ability to fall back on vendor support then you would probably want to choose one of the commercial or commercial-support options. RedHat FreeIPA/IdM looks promising and would probably be the first one I would choose now if I was starting from scratch or investigating for a customer.

    In terms of links, I don’t have really have much beyond those already contained in my past blog posts on the topics e.g.
    * https://platformadmin.com/blogs/paul/tag/active-directory/
    * https://platformadmin.com/blogs/paul/tag/iwa/

    A couple of extra interesting resources I saw regarding RedHat FreeIPA/IdM:
    * http://rhelblog.redhat.com/tag/active-directory/
    * https://www.socallinuxexpo.org/sites/default/files/presentations/Integrating%20Linux%20systems%20with%20Active%20Directory%20Using%20Open%20Source%20Tools%20SCALE%2015x%202017.pdf

    Cheers
    Paul

  14. Paul, that note to add “obey pam restrictions = yes” to smb.conf was gold. Thank you!

  16. Woohoo! I was so worried I’d have to put each and every user (1000+) into all 12 servers (meta cluster + grid) on the new platform just to be sure they could work. It seems awfully strange to me that SAS is bringing out applications which don’t properly interact with ldap/pam/sasauth and build /home/.

    Your solution might be a workaround but it’s much neater and more efficient than what I would have worked out in the short time-frame I have to release the new platform (Lev3 goes out today).

    I found this blog entry yesterday, my Linux team implemented it late yesterday, I tested it using a colleague who has never been in SAS nor on “my” servers at all before. All tested ok first time. I am thrilled.

    This is NOT the first time your blogs have made my life significantly better. Thank you so much for sharing your incredible knowledge. I spoke to Michelle about this to give the personal touch to my thanks as I don’t have your number to call direct. Cheers.

  17. Hi David,

    Thanks for posting your feedback. It’s always great to hear when my blog posts have helped other SAS admins!

    By the way, another option I have sometimes considered is to integrate home directory creation into a SAS identity sync process, either using code hooks with the Metacoda Identity Sync plug-in or by updating any existing hand-crafted code that uses the SAS %MDU macros. During the sync process new SAS users are identified and so SSH scripts could potentially be run to created home directories for those users on the target servers. Of course this would required running that script with elevated privileges on those servers. My preference (from both an ease and security perspective) would be to use standard methods for Linux to auto-create the directories but scripting it during identity sync is another possibility if the former is not an available option.

    Thanks also for adding your vote to the SASware ballot suggestion Make sasauth trigger PAM session handling to allow auto-creation of home directories by PAM modules :)

    Cheers
    Paul

  18. Thanks for you blog post, Paul. I found it really useful…

    but!

    I wasn’t able to get the script to be triggered and after a lengthy back and forth with SAS, found that for the script to be triggered (at least with Viya 3.3), the additions need to be added to the /etc/pam.d/sasauth-spre file, rather than /etc/pam.d/sasauth

    Once the changes were made, it all started working for me.

    Cheers,
    Tony

  19. Hi Tony,

    Thanks for your comment and tip about SAS Viya and sasauth-spre – it’s comments like this from you and the others in the SAS community that adds extra value to the posts, making them more useful to others and myself.

    I just checked my SAS Viya 3.3 install /etc/pam.d/sasauth-spre file and found I already had the script specified in there, so I must have had the same problem and come to the same solution (but forgot to update the blog post!). I also have it in /etc/pam.d/sasauth-viya too – I can’t quite remember whether that was in response to another issue which it solved or whether it was just an automatic addition. I’ll have to check my notes and see.

    Cheers
    Paul

  20. Hi Paul,

    first of all, thank you for that great blog post. It already helped me a lot.

    Unfortunately I’m still struggling with the auto-creation of home directories when authenticating through IWA.
    It seems that SAS isnt’t using the PAM Modules when authenticating with IWA. Do you know if there’s a way to fix this?

  21. Hi Andre,

    Thanks for your comment.

    My lab environment is setup for IWA so I will look into this when I get some spare time.

    In discussions with another SAS admin recently, they indicated that they have had success in the past in triggering the oddjob_mkhomedir creation (via dbus-send I assume) in the the SAS Workspace Server launch script (e.g. /opt/sas94m5/config/Lev1/SASApp/WorkspaceServer/WorkspaceServer_usermods.sh). I haven’t tried this myself as yet so cannot confirm whether it works but it may be worth investigating as another option.

    Cheers
    Paul

  22. Hi Paul,

    I’ve looked into your suggestion to use the WorkspaceServer_usermods.sh for triggering oddjob_mkhomedir.

    First of all I faced the problem that only root is allowed to call “dbus-send –system –dest=com.redhat.oddjob_mkhomedir –print-reply / com.redhat.oddjob_mkhomedir.mkhomedirfor string:”””

    I’ve got the following error message if I tried to call it as a regular user: “Error com.redhat.oddjob.Error.ACL: ACL does not allow access”

    While looking through some oddjob documentations (unfortunately they’re not very extensive) I’ve found the “/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf” configuration file and stumbled over a mkmyhomedir method.

    After some research I’ve found the following in the pam_oddkjob_mkhomedir man page (https://linux.die.net/man/8/pam_oddjob_mkhomedir):

    “The pam_oddjob_mkhomedir.so module checks if the user’s home directory exists, and if it does not, it invokes the mkhomedirfor method of the com.redhat.oddjob_mkhomedir service for the PAM_USER if the module is running with superuser privileges. Otherwise, it invokes the mkmyhomedir method.”

    which made me believe that this method does indeed what it sounds like. Unfortunately calling
    “dbus-send –system –dest=com.redhat.oddjob_mkhomedir –print-reply / com.redhat.oddjob_mkhomedir.mkmyhomedir”
    still ended in an authorisation error.

    After adding the line
    ” ”
    in “/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf” to

    <!– no acl entries -> not allowed for anyone –>

    I finally could call mkmyhomedir as a regular user and create a home directory for myself.

    After adding the “dbus-send –system –dest=com.redhat.oddjob_mkhomedir –print-reply / com.redhat.oddjob_mkhomedir.mkmyhomedir” to the WorkspaceServer_usermods.sh the auto-creation of home directories worked like a charm.

    Thank you very much for the suggestion that made me look deeper into oddjob_mkhomedir in connection with WorkspaceServer_usermods.sh!

    Cheers
    Andre

  23. No problem Andre. It was another SAS admin that provided the idea to create the home dir during SAS Workspace Server launch so I’m glad to hear it worked for you. Thank you too for posting back your findings on how you got it to work. I’m sure your notes will be very useful to other SAS admins too. I hadn’t noticed mkmyhomedir myself so it’s good to hear about that.

  25. Hi Carlos,

    Sorry, I don’t use SUSE Linux, only RHEL, Debian and derivatives. I expect the PAM config to be similar but am unsure about the availability of oddjobd packages for SUSE. Perhaps another reader who uses SUSE can provide some input on this?

    Cheers
    Paul

  26. Hi,

    Thanks for the tip. In case it can help someone, it wasn’t working for us on Red Hat 7 + SAS 9.4 until we change the line :
    account optional pam_exec.so /etc/pam.d/sasauth-mkhomedir.sh
    by
    auth required pam_exec.so /etc/pam.d/sasauth-mkhomedir.sh
    in the file /etc/pam.d/sasauth

    Regards,
    Yann

  27. Hi Yann,

    That’s odd. You should be able to get it working on RHEL7 with the account module. I would be hesitant about pushing it forward to the auth module. Have you tested to see what happens with invalid user ids and incorrect passwords with that setup? Does it still try to create home directories in those instances? If you can’t get it working using account then perhaps look into the other method discussed in the comments, where the home directory creation is done in WorkspaceServer_usermods.sh

    Cheers
    Paul

  28. Hi,

    The home of invalid user ids are not created, in the PAM log there is :
    20191001-15:04:32 PAM wanted to tell us about an error: /etc/pam.d/sasauth-mkhomedir.sh failed: exit code 8
    Nevertheless, if a AD user try to authentificate, his home is created even if the user has not SAS rights in the metadata server.

    Regards,
    Yann

  30. Hi Paul,

    Thanks for this article. we implemented the same in our SAS Grid environment, directories for the user was created, but when we tried run the program on SAS EG the grid launched workspace server is throwing an error.
    like the grid provider has exceeded the time wait

    Thanks,
    Anguraj S

  31. Hi Anguraj,

    I’m glad you found the article useful. It sounds like you still have issues with the workspace server launch however. What error messages you are seeing in EG and the server logs? You could also try posting the errors on communities.sas.com as there are some very knowledgeable SAS grid admins that post there and may also be able to help.

    Cheers
    Paul

  32. Hi Paul,

    Please find the object spawner error message:
    2020-06-17T13:28:29,525 ERROR [00008418] :azsj – The specified uuid DA816073-34D2-5F4E-B85A-EFDD03AC30F6 did not match any process managed by this spawner.
    2020-06-17T13:28:29,526 ERROR [00008418] :azsj – Objspawn was unable to launch the server SASApp – Workspace Server (A5NYPY3W.AY00000C) because the Grid provider has exceeded the specified wait time.
    Note: Other users who logged in the server directly not thru PAM Automatic home directory is not facing any issue.
    Thanks,
    Anguraj S

  34. Hi Paul,

    I have applied the modification to the sasauth. Needless to say coming from your tips : it works like a charm :) . This is a RHEL 7 Office Analytics M6 installation with pam enabled. As mentioned in the discussion above, the ‘oddjob-mkhomedir’ can be configured in order to order non root users to create $HOME directories. The home creation then could be initiated by the workspace launcher. I preferred your solution, more secure since opening this creation to non privileged decreases the security level.I remember some time ago I had to argue with security teams in order to justify onboarding linux accounts with $HOME enabled on the SAS Compute server… In theory, enabling access to a server for an account does not imply allowing its /home directory; hardened configurations have sometimes this requirement.

    A million thanks,

    Cheers
    Ronan

  35. Hi Ronan,

    Thanks for your feedback. It’s always nice to hear back from people who find these tips helpful in their work.

    Another possibility, to remove the requirement for individual user home directories on SAS 9 compute servers, is to use SAS Token Authentication. The downside is the loss of the ability to use fine-grained file system permissions but if they are not being utilized then SAS Token Authentication makes things simple.

    Cheers
    Paul

  36. Hello All,
    Thanks for sharing all these informations , also I’m still struggling with the auto-creation of home directories when authenticating through IWA using Enterprise Guide.
    I followed the steps explained by Andre Zieher but still getting an error message.

    Thanks for you help.

  38. Hi Paul,

    Thanks for your response ,
    First when i log in sas studio with my credentials (IWA not implemented in our middle tier ) the home directory is created without any issue.
    Second let me share the content of both files (WorkspaceServer_usermods.sh + oddjobd-mkhomedir.conf)
    Honestly I’m confused about adding the line ” ” in “/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf” to not allowed for anyone –> that Andre Zieher suggested please advice .
    please take a look at the below configurations.

    /*****************************WorkspaceServer_usermods.sh*****************************/
    #!/bin/sh -p
    #
    # WorkspaceServer_usermods.sh
    #
    # This script extends WorkspaceServer.sh. Add local environment variables
    # to this file so they will be preserved.
    #

    USERMODS_OPTIONS=
    dbus-send –-system –-dest=com.redhat.oddjob_mkhomedir –-print-reply / com.redhat.oddjob_mkhomedir.mkmyhomedir

    /********************************oddjobd-mkhomedir.conf********************************************************/

    <!– –>

    /*****************************************************************************************************************/
    The error message that I’m getting from Enterprise Guide is:

    The connection could not be established to a SAS Worksapce Server named ‘SASApp’ running on port 8594 on host *****
    Server response :The launch of the server process failed with an unknown status code.

  39. Hi Paul,

    The message that I’m getting from Enterprise Guide is :
    The connection could not be established to a SAS Worksapce Server named ‘SASApp’
    running on port 8594 on host ‘xxxxxxx’
    Server response : The launch of the server process failed with an unknown status code.

    Honestrly I’m confused about adding the line ” ” in “/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf” to
    not allowed for anyone –> that Andre Zieher suggested, any advice on this.
    /*******************************************************/

    /******************************************************/
    Also below the content of my WorkspaceServer_usermods.sh after made the modification that Andre Zieher suggested.
    /************************************************************************/
    #!/bin/sh -p
    #
    # WorkspaceServer_usermods.sh
    #
    # This script extends WorkspaceServer.sh. Add local environment variables
    # to this file so they will be preserved.
    #

    USERMODS_OPTIONS=
    dbus-send –-system –-dest=com.redhat.oddjob_mkhomedir –-print-reply / com.redhat.oddjob_mkhomedir.mkmyhomedir

    /*************************************************************************/

    What am I doing wrong?

    Thanks

  40. That error for EG is just that the workspace server process could not be started (most likely because of the lack of a home dir).
    You will get more useful info about the source of that problem by looking in the SAS Object Spawner, system and debug logs.
    Take a look at the PAM config above for more info on debug logging.

    Unfortunately, when Andre posted his comment the XML tags got eaten by the blog software so I don’t know specifically what was on that missing line. This is the line from one of my systems in case it helps:

    <helper exec="/usr/libexec/oddjob/mkhomedir"
                  arguments="0"
                  prepend_user_name="yes"/>

    If you look on the web you’ll see that some people add a -u 0027 or -u 0007 or -u 0077 umask parameter to the end of the exec command to fine tune the permissions on the newly created home dir.

    BTW I noticed that the double hyphens in your comment look a bit odd – one long and one short – not sure if that is an issue in your command in the file or if it was just how it was pasted into the comment.

  41. Hi Paul,

    Thanks for your help, you were right about the the double hyphens in
    dbus-send –system –dest=com.redhat.oddjob_mkhomedir –print-reply / com.redhat.oddjob_mkhomedir.mkmyhomedir
    also for the mkhomedir I simply use what you were suggesting .

    Now that works, thanks again.
    Mouatez

  42. Hi Mouatez,
    It’s good to hear that it’s working now.
    Cheers
    Paul

  43. hi
    Almost working smooth, added “-u 0077” in file/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf (RHEL 7), like this:

    the home directory with profile files creates nicely, but the rights does’nt updates, look like this:
    -rw——- 1 g015170 gs-res_sas_linux_access 18 Oct 12 14:44 .bash_logout
    -rw——- 1 g015170 gs-res_sas_linux_access 193 Oct 12 14:44 .bash_profile
    -rw——- 1 g015170 gs-res_sas_linux_access 231 Oct 12 14:44 .bashrc
    -rw——- 1 g015170 gs-res_sas_linux_access 334 Oct 12 14:44 .emacs
    -rw——- 1 g015170 gs-res_sas_linux_access 185 Oct 12 14:44 krb5cc_10000_FG3bEP
    -rw——- 1 g015170 gs-res_sas_linux_access 172 Oct 12 14:44 .kshrc

    any tip anyone ?

  44. Hi Dagfinn,

    Would you not expect “-rw — —” with a umask of 0077 where you are masking all group and other permissions?
    Unless I am mistaken, those permissions look like they result from that umask. What were you expecting to see?

    Cheers
    Paul

  45. problem is that i can not spawn a SAS workspace server session, umask 0077 setting rwx on users home dir. and rw on files inside, should be ok with this perm.

  47. Thanks for your post. That sounds good and will be much easier for admins to setup. I’ll be sure to try it out soon.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.