10.6.4 AFP - ACLs - Workgroup Manager :: changes need reboot to take affect

hello community
still new to OSX Server I am a bit confused regarding changes made to
AFP - ACLs - Workgroup Manager
do changes really need a server reboot to take affect?
scenario:
*Workgroup Manager ...*
User1
User2
User3
GroupFolder1 :: Members -> GroupSubFolder1.1 + GroupSubFolder1.2
GroupSubFolder1.1 :: Members -> User1
GroupSubFolder1.2 :: Members -> User2
*AFP shares & folders with ACLs ...*
Folder1 :: ACL read for GroupFolder1
SubFolder1.1 :: ACL read for GroupSubFolder1.1
SubFolder1.2 :: ACL read for GroupSubFolder1.2
(SubFolder1.1 + SubFolder1.2 are nested into Folder1
to make it clear)
this workz perfect!
if I now switch in Workgroup Manager the memberships to eg.
*Workgroup Manager ...*
User1
User2
User3
GroupFolder1 :: Members -> GroupSubFolder1.1 + GroupSubFolder1.2
GroupSubFolder1.1 :: Members -> User2 + User3
GroupSubFolder1.2 :: Members -> User1
this will only take effect when rebooting the server.
I tried to ...
start/stop AFP
restart ldap, by deselectingsaving/selectingsaving the SSL cert for OpenDirectoryService
restart the clients
nothing helped but restarting the MacMiniServer
server and all clients are running 10.6.4
cannot be that one has to reboot the whole machine to make AFP - ACLs - Workgroup Manager changes take effect?
ok I am running a rather small setup, but what if ya want to integrate a new user into a bigger environment? this will lead to a disconnect for all users connected or an "over-night-wait-time" for the new user, whilest scheduleing a reboot somewhere in the night? but even then what if people are connected in different timezones overseas via vpn?
where is the hook to make the settings take effect immediately after saving the changes?
any other info I can provide to reproduce/solve the issue?
rgds,
g.
Message was edited:
tried to correct my spelling, please bare with me I am no english native

Well that suggestion from the site referenced above about tearing the OD down, deleting the slapd.conf files and bringing it back up didn't work. 10.5 servers still see changes in OD as they happen and 10.6 servers don't see the change until around 10 minutes later.
Anyone run across this and fixed it?

Similar Messages

  • RDS Gateway - Why are RAP changes requiring reboot to take effect?

    I have Win2k8R2 with RDS Gateway. I am using AD groups in a RAP to define which network resources can be accessed by users. For the most part, it's working as expected, but I am finding that changes to the AD group (e.g. remove a server) are not taking effect
    immediately. Users are still able to establish a new connection to a server that has been removed from the AD group. If I reboot the RDS GW, the change seems to take effect, and the users can no longer access the removed server.
    While I haven't tested it extensively yet, the change may also take effect after a period of time, without requiring a reboot ... but this doesn't help me either. I need to have such changes take immediate effect.
    I've searched the web without luck, this is an awkward topic to get meaningful results on. Can someone tell me definitively when changes to AD groups take effect in the RAP ... and how I can force it to take immediate effect (without a reboot)?
    Thanks,
    Rob

    Hi Dharmesh,
    Yes I tried that suggestion, but it made no difference. I don't believe it has anything to do with the Domain Users group, because the problem does resolve itself - after a reboot (without having to change any group membership).
    I've just confirmed this situation again yesterday ... on 2 occasions I made changes to AD group memberships that are referenced in RAPs. I added a user to the group to enable them access. Both times I waited at least 5 minutes after making
    the changes, but the users still couldn't connect. I ensured all domain controllers had the AD group changes replicated ... users still couldn't connect. I rebooted the RDGW server (I am using a single server, not RD Session Host farm), and that immediately
    fixed it. So the problem is still present. It feels as if RDGS is caching AD group membership.
    Rob

  • Workgroup Manager - AFP Login Items no longer mount

    A wierd problem.
    I have the same URL in my Login Items for all of my groups in Workgroup Manager. It is to mount a folder share. After logging in as any network user, the share will not mount, and I do not even receive an error saying that it couldn't be mounted. Also, while still logged in as a network user, even as an admin network user, and I click "Go...Connect to Server" I can connect to the server, but the share doesn't even show up, though all the other shares do. Also, when I log in locally as an administrator, or from any other computer not going through OD, I can browse to the server and hit the share.
    In my attempts to trouble shoot, I have changed the URL for the share in Login Items to mount the share with SMB, and it does work.
    Seems as though the problem is taht the share is being blocked to all network users when logged in through OD.
    What do you suggest?

    In Server Admin, under file sharing. Select your sharepoint.
    Click the "Share Point" button below the file browser.
    Check to make sure that all the settings are correct.
    ie, if it's not a home folder location don't have auto mount checked. Also in the protocol options, check to make sure that you have the right protocols selected. AFP and SMB are probably all you need.
    -Graham

  • Can no longer change or Edit in Workgroup Manager

    I just moved and I was migrating my files to another computer and domain. No I can no longer authenticate to my workgroup manager to change anything.
    Here is what I did.
    Moved across the country
    Carbon Copied my 10.4 Server from my G5 tower to a G5 XSERVE
    Upgraded to 10.5.
    When I thought everything was OK changed my Cable modem IP to me.
    Now I cannot change or add anyone in Workgroup Manager.
    Help

    Exactly the same thing happened to me with two sites I managed after having upgraded the server to 10.5. One site I know the root password and can authenticate to Workgroup Manager using that, all other admin accounts don't work. The other nearly all accounts were broken so I had to use passwd and get the users to change their password before they could log into client machines. I can't get administrative access to Workgroup Manager.
    The interesting thing in both these cases is that the password server logs show the authentication as having succeeded, however Workgroup Manager says the authentication has failed.
    Jan 23 2008 10:22:35 AUTH2: {0x00000000000000000000000000000001, diradmin} DHX authentication succeeded.
    Here's hoping that 10.5.2 fixes these problems.

  • Cannot change short name of computer in Workgroup Manager

    When a computer is bound to Open Directory on the client side I cannot change the short name of the computer. If the computer is added through Workgroup Manager I do not have this problem. When I try to change the name it reverts back to the old name and sometimes adds a .local at the end of it, but the new name I choose is displayed on the left side. When I log out and log back in the name on the left side reverts back to the old name.
    Could it be the way I am naming the computers? I am using dept-username.location as a way to name all computers. Why does this problem only occur on computers that have been bound through the LDAPv3 service on the workstation?

    I can't comment for sure on this one; but my educated guess may be that you're causing problems with your DNS (or DHCP) by specifying an extra dot in the name - Although I can't say for certain as my OD doesn't run my DNS.
    Try using dept-username-location.domain.local instead of dept-username.location.domain.local.
    Have you checked the console output to see if any errors are being returned?
    -Kogen

  • Any changes in workgroup manager I make are not working!

    First off I know this isn't the place to vent, but I am so sick of all the bugs loaded in the directory system of mac. I think Apple has produced a horrible product and it is always one problem after another. I am experienced with all the other directory systems and I firmly believe Open Directory is the worst!
    Ok, now on to my problem. Our set up includes 6 Mac OS X 10.6 servers. 1 is the Master OD and the others are all replicas. We recently upgrades the servers from 10.5 and ever since I have been having problems with OD. During the upgrades I took an archive of the system, decommissioned the Master and all replicas, then after the upgrade I restored the archive and replicated all the others. Things worked fine for a couple of days. Everyone can login and I could create new users and make changes in workgroup manager. After a couple of days I could no longer make any changes in workgroup manager. I can physically make the changes and create new users and save with no errors, but when I try to log into the file server with the new user or use the changed password, it doesn't work. No errors in the logs that I looked in.
    Here is something weird: When I log into workgroup manager using the local administrator account, I do not see the changes I made in workgroup manager. When I click the unlock button and log in as the diradmin I can see the changes.
    Any, ANY, help would be greatly appreciated. I've been working on this for weeks now. Please don't advise to decommission the Master and rebuild the directory. I already tried that about 10 times with the same result.
    Thanks!

    5 days should be plenty, unless you have a really slow link. Here are a few diagnostics that come to mind to figure out more about what's going on:
    To test to figure out of I'm right about replication being the source of the problem, and if so which replicas aren't up to date, use the "ldapsearch" command to compare the data in the master vs. the various replicas. For instance, to check whether a new user named "fred" has shown up in the server at serverIP, run the command: ldapsearch –LLL –x –h serverIP –b cn=users,dc=masterserver,dc=example,dc=com “(uid=fred)”
    (replace serverIP with your server's address, "dc=masterserver,dc=example,dc=com" with your search base, and fred with the actual account name). Try this on the master and the various replicas, and see which (if any) of the replicas are out of sync.
    If some/all of the replicas are out of sync, check /var/log/slapd.log on the problematic replica(s). It's visible in Server Admin -> servername > Open Directory in sidebar -> Logs in toolbar -> LDAP Log in the View pop-up at the bottom of the window.
    Also, check the replica status in Server Admin -> Open Directory -> Settings -> General.
    Also, on the problematic replica(s), check the replication connections: "sudo lsof -i | grep ldap" should show an entry starting with "slapd" and ending "->masterserver.example.com:ldap (ESTABLISHED)". If it doesn't, you may have some sort of network connectivity/firewall issue.
    If you want to get even more detailed, running "sudo tcpdump host masterserver.example.com and port ldap" on the replica will let you spy on the content of the replication connection.

  • Unable to authenticate with diradmin in Workgroup Manager

    This has happened before, and I have no idea how it got fixed - too many independent variables...
    Anyway, I cannot authenticate the OD with diradmin even while using Workgroup Manager directly on the server.
    The setup:
    SLS 10.6.8
    Split-brained DNS
         Both public and private FQDNs are the same (myserver.mydomain.com). External DNS maps machine record to my static public IP address. Using an AirPort Extreme router, port fowarding services that I want open to the server. The router provides DHCP via NAT to the local network, with a fixed private IP assigned to the server. The server is running DNS with the same zones, machine records, services and aliases that the public IP DNS has, except mapped to the fixed private IP. DNS checks out with changeip, etc.
         The server is an OD master. Yesterday I exported it, demoted it, and restored it. All services (mail, web, etc.) seem to work fine (although I admit to not using Kerberos on AFP due to another issue).
         I have a wildcard certificate that is generated by GoDaddy (*.<mydomain>.com) which seems to work fine with the hosted websites.
    This is what the password service error log says when I try to log in with diradmin in Workgroup Manager:
    Jan 10 2012 14:01:32    AUTH2: {0x4bbe71ca6b8b45670000000200000002, diradmin} DHX authentication succeeded.
    Jan 10 2012 14:01:32    KERBEROS-LOGIN-CHECK: user {0x4bbe71ca6b8b45670000000200000002, diradmin} is in good standing.
    Jan 10 2012 14:01:32    KERBEROS-LOGIN-CHECK: user {0x4bbe71ca6b8b45670000000200000002, diradmin} authentication succeeded.
    Looks good to me. But I still get the "Information Not Valid for This Server" followed by stuff about invalid login ID or password.
    I did notice in the LDAP log:
    Jan 10 14:13:12 <myserver> slapd[52283]: SASL [conn=18] Failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Key table entry not found)
    And at the last bootup in the directory service error log:
    2012-01-10 08:52:03 EST - T[0x00007FFF7027ACC0] - DNSServiceProcessResult returned -65563
    The other thing I notice when I log into the library in Workgroup Manager FROM THE SERVER, even if I use the FQDN <myserver>.<mydomain>.com that Workgroup Manager says (in the title bar of the window) <myserver>.local.
    I have googled the various errors and messages, and I get folks with all sorts of variations ("change the binding options", etc.) none of which either applied or worked.
    Help?

    Continuing on my quest... I found this Technical note from Apple about re-kerberizing:
    http://support.apple.com/kb/HT3655
    Interestingly, in step 3 where it says to remove realm information from kdc.conf, there wasn't any of my realm information. Argh!
    So I completed all of the steps and executed the slapconfig command. This resulted in:
    bash-3.2# slapconfig -kerberize -f --allow_local_realm diradmin <MYREALM>
    diradmin's Password:
    Could not resolve hostname <MYDOMAIN>
    Skipping Kerberos configuration
    Sounds like a dreaded DNS problem. It had been working correctly, but changeip -checkhostname confirmed a problem. Turns out that there were EXTERNAL DNS servers in the Network preferences in System Preferences as well as on the router. With my Split-brained DNS this caused problems (thank you again MrHoffman). So I changed them both to my DNS server INTERNAL IP address and added the external ones to the Forwarder IP Address in DNS. Now checkhostname -changeip returns a favorable result.
    So after rebooting ran the slapconfig command again and got the same result. Argh. Cleared DNS caches. Still nothing.
    So I tried nslookup.
    nslookup <mydomain>
    Server:                    10.0.8.2
    Address:          10.0.8.2#53
    ** server can't find <mydomain>: SERVFAIL
    Where 10.0.8.2 is the fixed INTERNAL IP address.
    However, nslookup on using the fixed IP address yields:
    bash-3.2# nslookup 10.0.8.2
    Server:                    10.0.8.2
    Address:          10.0.8.2#53
    2.8.0.10.in-addr.arpa          name = <mydomain>.
    Scratching head here... changeip -checkhostname works, nslookup on the IP address works, but nslookup on the host name fails.

  • Odd Workgroup Manager behavior

    I did a search but didn't have any luck finding info... I work in an academic environment and run a couple of Mac servers. On one, we have multiple port/IPs set up... The IPs are in ascending order. (Note that the school's central computing group maintains all DNS configs and assigns IPs; I am not running my own DNS setup.)
    server.school.edu
    www.server.school.edu
    service1.server.school.edu
    service2.server.school.edu
    When I bring up workgroup manager, I log in as diradmin at server.school.edu, but Workgroup Manager instantly changes the directory display to service1.server.school.edu. And it forces me to create all home directories at afp://service1.server.school.edu.
    Any idea why? Is there a file somewhere I can edit to fix this?
    Thanks in advance to anybody with wisdom to share here.

    You could try to add server.school.edu to your /etc/hosts file. Another alternative is to change the order of the A-records in the DNS so that server.school.edu is listed before the others. If these options don't work, you can always change the url for the home directory manually in WGM.

  • Workgroup Manager doesn't create home directories for OD accounts

    I'm having an issue where home directories aren't created for OD accounts. My setup is as follows, the home directories are stored on the OD Master (the only Apple/OD/AD server on the network), and the home directory paths are filled as afp://192.168.1.254/Customers, fakeuser, /Users/Customers/fakeuser
    This same pathing scheme works fine for local accounts, however for OD, clicking Create Home Directory and saving the account does nothing (no errors, nor folders created). If I ftp into said account, I wind up being directed to /Users (definitely not the expected behaviour)
    I am deploying a web based upload system that I want to authenticate against OD users so as to share home folders and permissions with the ftp server, once I have this figured out I will be migrating a bunch of accounts to OD from local.

    In addition to potential DNS issues, it sounds like you may be using the wrong procedure to define the users' home directories. You should never have to specify the paths manually; instead, define the share point ("Customers" in your case) to be automounted, and then it should automatically show up in the list of available home folder locations, with all the necessary paths predefined. Here's the full procedure:
    1. Run Server Admin, and select: the server name in the sidebar -> File Sharing in the toolbar -> Volumes & Browse under that -> navigate to the /Customers folder in the column view.
    2. Make sure the folder is being shared (with it selected, you should see an "Unshare" button near the top right of the window); if not share it with the Share Button (then Save the change).
    3. Select the Share Point tab under the file browser (NOT the one above it), and select the Enable Automount checkbox. A dialog will open asking for the automount details; make sure the Directory is set to /LADPv3/127.0.0.1, Protocol to AFP, and Use for is User home folders and group folders. OK the dialog, and be sure to click Save to make the change take effect.
    4. Run Workgroup Manager, and select Accounts in the toolbar -> Users (single person icon) tab under that -> some user account(s) you want to configure under that -> Home tab on the right.
    5. Select (None) from the location list and click Save (this wipes out any current setting, so we can rebuild it correctly).
    6. The Customers share point should be in the list of available locations (due to being configured for automount); select it, then click Create Home Now, and finally Save.

  • AD Users not showing up in Workgroup Manager

    Hi, I'm configuring a new installation of 10.4 server on an Intel Xserve to integrate with an already existing AD domain and provide group policies to Mac users via OD.
    So far, the install has been so smooth, fast, and simple. The Xserve has been joined to the AD domain, Kerberos is running, and I have an active OpenDirectory Master.
    Now, when I go to Workgroup Manager, the users in the AD domain do not show up and if I try to authenticate with the same username and password I used to bind to the domain I get the error "The login information is not valid for this server". Also, if I use dscl I can navigate to "/Active Directory/All Domains/Users" but if I try to run ls I get "ls: DS error: eDSCannotAccessSession".

    Hi Tim
    You are almost there but not quite.
    Firstly its not important if the AD Server does not have a reverse pointer. As long as the OD Master does that should be enough. Ultimately it would be better if there was one configured but there is not much you can do about that is there? I doubt very much if the AD Admin is going to want to fiddle with a 'live' DC's DNS Service if its likely to affect his domain?
    What I generally do is this:
    Make sure SMB Digital Signing is Not Enabled on the AD Server. There should be at least two places where this has to be disabled. If the 'powers that be' have defined SMB Digital Signing then SFM (Services For Macintosh) must be installed. If its 'nada' to both then you will be severely limited in integrating OSX Server and mac clients with AD. Yes of course make sure there is an (A) and Reverse PTR for the mac server. Next bind all mac clients to the AD Server and make sure the AD Server is listed first for Authentication and Contacts, also make sure mac clients are using the AD for authentication. Test and verify a mac client to see if (a) home folders are created and accessed and that mac clients successfully log in. You sometimes don't get the two.
    Now turn your attention to OSX Server. Make sure you have (a) reserved a fixed IP address for it in the AD's DHCP Service and you have placed the AD's IP address as the primary IP address in the DNS Server's field in the Network Preferences Pane (b) tested DNS fully and that OS X Server resolves correctly on the forward and reverse pointers for itself. Now bind OSX Server to the AD using the Active Directory plug in in Directory Access and an AD admin account that has authority for the Domain. Launch Workgroup Manager and you should see AD Users and Groups have 'flowed' into the /Active Directory/All Domains node. Quit out of WGM and launch Server Admin. Enable the AFP Service and set the authentication method to Any Method. Select Open Directory and change the Role from Standalone to Open Directory Master. You will be prompted to create the default Directory Administrator account diradmin (UID 1000). You should see the Kerberos Realm and search base fields autofill with the fqdn of the Server. Change both of these to reflect the fqdn of the AD Server. For example if the fqdn of your mac server is osxserver.addomain.com and the windows server is adserver.addomain.com then change the information presented in thos fields to ADSERVER.ADDOMAIN.COM and dc=adserver,dc=addomain,dc=com. As you can see you should only need to change the first part. Click OK or Continue and you should now have an OD Master that is not the KDC (Kerberos has been stopped). This is the state you want it be in before going any further. You can now 'kerberize' the AFP Service you started previously by selecting the kerberize button and using the same AD admin account you used to previously bind the server to the AD. To doublecheck if the AFP Service has been kerberized launch terminal and issue:
    sudo kadmin.local -q list_principals
    You should see an entry for [email protected] amongst others.
    Now launch Directory Access and make sure the server's loopback address is listed in the LDAPv3 plug in. Make sure that the server is listed first in the Authentication and Contacts fields. Quit out of Server Admin and launch WGM. Navigate to the /LDAPv3/127.0.0.1 node and you should see diradmin waiting for you. Open another connection window in WGM and navigate to the /Active Directory/All Domains node. When you authenticate the /LDAPv3 node you use diradmin, when you authenticate the /Active Directory node you use the AD admin account. Create a Group in the /LDAPv3 node select the + icon and toggle between the two nodes as you select users or groups and add them to your /LDAPv3 node. Once you are happy select a preference to manage, apply desired changes and save the changes. This is better done on a client machine with the Server applications installed.
    Back to your mac clients. Begin to join these to the LDAP node using the LDAPv3 plug in in Directory Access. Use the Server's IP Address or its FQDN if the DHCP Server is also doling out DNS information to networked clients. Its IP address should be good enough. Don't bother with authenticated binding and make sure clients are not using the OD master for authentication and contacts. Lastly make sure the Active Directory/All Domains and the /LDAPv3/OD Master IP address or fqdn are in that order for browsed directories.
    Its best if you have a secure local admin account on all your mac clients and that each mac is named differently. Set this in the Sharing Preferences Pane.
    Begin to test. If everything is OK you should now have mac clients logging into home directories controlled by AD as well as OD Managed Preferences being applied.
    One final thing. Avoid using .local as the basis for the DNS Service. I realise in your environment you have no control over that. In which case make sure all mac clients have the AD's .local domain name in the Search Domains field in the Network Preferences Pane. If your clients have Leopard installed you should not have to bother as Leopard copes with .local name resolution better than previous versions of the OS.
    As ever how successful you are and how long it takes will depend mostly on how well the AD is configured. There is no magic bullet that can be used on the mac side to fix a poorly configured AD environment. If everything is as it should be regarding the AD Server it should not take you longer than 10-20 minutes (after server installation) for the server and possibly 2-3 minutes for each client. It really should not take that long.
    Does this help?
    Tony

  • Server admin not seeing directory users from workgroup manager

    I am setting up a new Xserve with Snow Leopard (get 'em while we can). We have eight other XServes running Leopard or Snow Leopard server. On those machines we have set up file sharing over AFP. The machines are connected to our Active Directory server and our users authenticate using their domain passwords. All of our other servers were setup in Leopard and were upgraded to Snow Leopard. We have not had any issues authenticating to those boxes.
    This is the first one that we have actually setup new-out-of-the-box in Snow Leopard. I can set Workgroup Manager up to connect to our AD, and can see and search my domain users and groups in Workgroup Manager. When I try to set up my File Shares in Server Admin, none of my domain users show up-only local accounts.
    What have I missed? In Leopard, when I connected to the domain, the users immediately became available in Server Admin. Not so in SL, at least on this box.
    Help?

    Hi
    The first thing to check is if you've bound the Server to the AD Domain. The second thing is if the /Active Directory/All Domains is in the Search Policy. If you don't do either of these WorkGroup Manager won't display anything coming from the AD Schema.
    In 10.6 Apple moved the Directory Utility from where it used to be in /Applications/Utilities and made it part of the Accounts Preferences Pane. Perhaps it's this change that's confusing you? I would not advise doing this but it's also possible you used the Server Setup Assistant to do most of the configuration? If you did maybe something went wrong at that stage (won't be the first time) and you need to manually bind the Server instead?
    As ever make sure this server is using the same NTP Server as the others.
    Tony

  • Workgroup Manager: Sharing is Greyed Out

    Having re-built a 10.4.11 Server OS, migrated data from the old drives onto the new ones, installed users, got it up and running, I now find I have a problem where the Sharing icon on the Workgroup Manager is greyed out, and thus I can't get into it to adjust sharing settings, add things, etc.
    Currently, users seem to be able to mount all the shared volumes, because they were setup before this issue started, and I turned up the ACL's as well. However, I'm concerned I won't be able to make changes or updates. Is there something I've done or missed that's caused the Sharing to suddenly become greyed out and inaccessaible from Workgroup Manager? And more importantly, is there a way to correct the issue?
    Thanks in advance for your insight!

    I found the answer to my own question from another discussion:
    http://discussions.apple.com/thread.jspa?threadID=1970581&tstart=0
    When opening the Workgroup Manager, type in 'localhost' for the address.

  • Server Admin and Workgroup Manager is sloooow

    When running Server Admin or Workgroup Manager directly from my client macbook, connected to one of our leopard servers, it is painfully slow. I mean painfully.
    It takes a minute to connect while I stare at this spinning wheel, some actions never stop spinning the wheel. Sometimes it just stops and everything is working great.
    If I run the admin tools locally, connected through remote desktop its working much better, but can still be quite slow when connecting sometimes.
    Any ideas?

    I had a similar problem with a new xserve, setup with the factory pre-install leopard 10.5.2 it defaults to the server FQDN (myservername.com) for server admin with no DNS setup it takes ages to finaly get SA to open because it can't resolve itself.
    deleting server.myservername.com once SA fianaly responds it reverts to server.local and responds
    once DNS is configured correctly, no more issues.
    this particular server went on to develope regular OD crashes and AFP problems with OD crashing and when users logged in/out nd AFP having to be restarted when OD crashed and I decided to rebuild it.
    the DVD was 10.5.1, on bootup it was far worse than the factory pre-install when opening SA
    I upgraded to 10.5.2 combo before turning on any services , even when I got DNS working it was slow to respond nothing like as bad as without DNS but still slow. DNS checked out fine. The only way I could get it to respond normally was to add the domain name to Search domains in network preferences.
    something I did notice with the DVD install in server setup the local address defaulted to .private SA expects .local and the server name wasn't automatically filled out when I entered the server FQDN. the factory pre-install automaticly filled out the server name and used .local
    there is an edit button near the server name once you click on that it changes the name from .private to .local
    I didn't notice the .private the 1st time around and with the .private things where far worse. SA wouldn't respond at all even with 127.0.0.1

  • Problems with Workgroup Manager

    I just took over computer support for a local school.  They have a Mac 10.5.6 server that I log in as <admin>.  Unfortunately, when I go to Workgroup Manager.  I can't add or change any accounts.  Obviously, the <admin> user doesn't have permission to make these changes.  How do I give admin user the right permission to work in workgroup manager?  The guy that set this up is now with a different company, and he is nearly impossible to contact. 

    The Apple manual is correct regarding how ACLs interact with POSIX permissions. If you haven't already, please see my ACL Tips post, which gives you some more detail: http://discussions.apple.com/thread.jspa?messageID=1696702.
    And, here's my answer to a question regarding how permissions for new/copied/moved files are assigned: http://discussions.apple.com/thread.jspa?messageID=3188259&#3188259.
    According to your post, I see two possibilites: One, you've recently enabled ACLs without restarting your server. If that's the case, a restart will work.
    Or:
    I fire up the Effective Permissions Inspector, drag over a production member and find all the write attributes are off except for delete.So the everyone posix field definitley overrides my ACL settings. Now I can set the Posix everyone field to read and write but I don't want everyone to have access.
    Do you mean that all write attributes are ON except for delete? If so, then there's the second possibility:
    The Finder and some other applications are not yet fully ACL-aware. For example, if all write permissions are granted except for delete_child and delete, then the Finder will treat the folder/file as read-only. This is also a problem for applications that employ saving routines like TextEdit. Basically, this situation cannot presently be resolved without further application improvements. Yes, the filesystem and core OS are ACL-aware, and effective permissions are being calculated correctly, but Finder/TextEdit represent a set of applications that depend on POSIX-like ACL mixdowns. This means that, even though ACLs offer fine-grained read and write permissions, some applications don't respect them when they're told.
    So why even have ACLs? Well, right now they fix several problems with POSIX-only: (1) nesting groups, (2) defining new/copied file/folder inheritance, and (3) the ability to define permissions for more than just one group (POSIX group) or user (POSIX owner) at a time.
    Hope this helps.
    --Gerrit

  • Can not locate Workgroup Manager; possibly not installed?

    Here's the story:
    I'm trying to get my new camera software installed and one of the steps is to launch Image capture.
    Image capture gives me an error saying: "No Image Capture Device connected."
    Apple says to fix this I need to open Workgroup Manager (in /Applications/Server/) and change some preferences.
    But, I can not find Workgroup Manager for the life of me. I used spotlight with no luck. I also don't have a folder in Applications titled Server. This worries me and makes me wonder if the program could have been deleted or not installed at all?
    Any suggestions on how to find WgM would be welcome.

    Whoa... somebody got confused someplace... I wouldn't guess you are running OSX Server on a MacBook, but the oSX CXlient instead, so no idea how Apple came up wih that solution.
    You likely should not have a Server folder there, nor the APP they speak of.
    What kind of Camera exactly, and how does it connect?

Maybe you are looking for