While looking at a server share point I admin, I learned an interesting anomaly that I hadn't been aware of before. When I login to the server remotely, I login as jmserver. Say I create a folder on the mounted sharepoint. That is, I don't drag it from the client machine to the server, but rather create a folder directly in the folder of the sharepoint.
When I look at that folder with the Finder of the client machine (ie I'm not working on the server directly), "Get Info" tells me that the owner of that file is "blank." Why doesn't the Finder know that jmserver is the owner?
MacManager tells me that the UID for the user jmserver on the server is 1035. New folders created on that share point then are owned by jmserver with UID 1035 (you can see the UIDs of a given file with ls -n).
NetInfo is the tool that associates the UIDs of files with the names of the owners. In this case, there are two NetInfo Databases -- one on the client machine, and one on the server. NetInfo on my client machine doesn't have an entry for a UID of 1035, so when the (client) Finder asks NetInfo who is associated with 1035, it reports back with a "blank." I tested this by creating a new user on the local machine with a UID of 1035 -- and, bob's your uncle, the Finder began reporting that the owner was the new user.
The bottom line is that the Get Info view of permissions is not be trusted when looking at a server share; you can only believe the terminal. And, if you need to change permission settings, you will only be able to do this in the terminal, not with the Get Info view, since it only allows owners to make those changes, and it doesn't recognize you as an owner.
I have a Server with Mac OS X Server 10.2 on it. And I wanted to restrict what kind of applications some of my users could use. With all built-in Apple apps, and most everyone else's programs, it's no problem. Just restrict access to everything, then allow the apps you want them to use.
But with some apps, like CoooL and R-Name, when I add these applications, this shows up in my allow list: com.apple.creatorcode.????. Then I can't separate those two apps from each other, or other apps with the same behavior.
The fix for this is to show the contents of the application (control-click on the application, then select Show Package Contents), then edit the /Contents -> Info.plist file using Property List Editor, or the text editor of your choice. In Property List Editor, create a new child. Call the Property CFBundleIdentifier, the Class is String, and the Value is the name of the application. Save it, then try to re-add the app to Workgroup Manager, and look at that beauty! It should work as expected now.
Found out your built-in FTP server isn't running as it did, after you activated the Firewall and even opened up the 20 and 21 IP ports, too? The built-in FTP server in 10.2, when using passive mode file transfers, opens an IP port which can be any one number between 1024 and 65534; the IANA registered ports for passive FTP are 49152 to 65534.
If you don't use an IP firewall (IPFW), you wouldn't notice this, but when the IPFW is switched on (specially on the server version), you find out that the whole FTP server does it's work only halfway. You can connect and get the first directory listing, but not any other listing, and starting a file transfer fails. Why, because in the IPFW we normally add only the two standard FTP ports 20 (listing) and 21(active file transfer) to open up holes to allow connections to the FTP Server.
In the Server Admin Tools, only these two IP ports are mentioned. With the Tool, you can't even set up the needed IP port range. This means without using the terminal and configuring the IPFW directly, you can't use the the FTP Server and IPFW together. It's one or the other "out-of-the-box!" After a lot of trial and error, and google'ing on the net, I found the following solution.
The first thing I found out was that the Mac OS X built-in FTP Server is not Apple's own design, it's actually an adapted WU-FTPD source to integrate it better with MacOS X. Second thing, after finding it's a WU-FTPD version, in the user manual (man files) on their website, there's an option to lock down the IP port range for passive FTP file transfers with the command passive ports cidr min max, which needs to be added to the /Library -> FTPServer -> Configuration -> ftpaccess config file. The third thing I found is that opening the firewall for the IANA registered ports for passive FTP mentioned above.
This was the short version of what needs to be done to get the FTP Server working correctly again.
A full version How-To, with all the command line entries, can be found here. Hope this post is some help to other Server Admins whose FTP server isn't working correctly.
Because of a incomptability between the boot ROM on the shipping OS X Server 10.2.0, and the latest G4 FW800, I was facing serious problems trying to install or even boot from the install CD. The following information is a combination of two Apple KBase articles: 107496 and 107124.
First install an OS X Client (minimum version 10.2.3). Be careful to choose a login name no longer than eight characters, because that is the maximum OS X Server allows. Then follow these steps to enable an install of an older OS X Server over a newer OS X Client. Start up normally from the target computer's Mac OS X startup disk, and log in as an Admin user. Then open Terminal (in /Applications/Utilities/) and type:
Just setting up a new Xserve with four 180GB drives headlessly (no monitor or keyboard attached). All the drives (other than the boot volume) were named the same from apple (ServerHD). In WGM, the drives would just show up as one drive. Also, if I tried to connect via AFP, only one drive would show up. I called Apple and they offered little help to configure it headless, since they don't support CLI tools.
The only work around is to attach a monitor and keyboard and rename the drives the old fashion way.
Just a heads up for anyone who wants to configure a headless Xserve with more than two factory installed drives.
The permissions on OS X Server home directories can get screwed up during reinstalls, hard drive swapping, or by users who know enough to be dangerous. This shell script goes through and corrects the permissions and owners on all user folders so you don't have to do it manually. Just put this in a text file (without any extension), name it something like "resetusers," and drop it in a command folder like /sbin. Then type sudo resetusers to run it.
set full=`nireport -t my_server/network /users name | egrep -v '(root|user1|user2)'`
chmod -R 700 $full
foreach current ($full)
chmod 755 $current
chmod -R 755 $current/Public
chmod -R 755 $current/Sites
chown -R $current $current
The way this works is:
Switch to the Users folder.
Use nireport -t my_server/network /users name to get a list of the users on the server. If you are not running a NetInfo domain, use nireport . /users name instead.
Use egrep to subtract any users who either have home directories in a different location (like root) or don't have home directories at all.
Make every folder of every user private.
For each user, allow public access to the Public and Sites folders and the top-level user folder.
Make sure the user is the owner of all files in their folder.
If you run into "Operation not permitted" errors on certain files, those files are probably locked. If you want to unlock them, run sudo chflags nouchg filename or sudo chflags -R nouchg foldername.
Ever tried to remotely restart your Server when there is no monitor attached? OS X automatically defaults to 800x600 on restart, and if you're running OS X Server on a G4 tower, it can be a royal pain in the butt - especially because once it's restarted, you don't get any choices for different resolutions ... and Workgroup Manager requires 1024x768 to run!
Here's a simple solution ... with your display attached, set your preffered resolution using the System Preferences pane. Once that's done, open the Terminal and lock the preference file (com.apple.windowserver.plist file) by typing:
When installing an OSX Server at client locations that required serving to PC's as well as Macs, I ran into problems with PC's winning the browser election instead of the server. Now traditional SAMBA expertise would say that setting the OS level high (like 65 or so) would cause the machine to win the election. But this is no longer true with Win2000 and XP. A Win2000 machine will trump Samba or Win98 regardless of OS level. An XP machine will trump everything else too.
So to solve this you need to edit the registry on the PC's. Here is how I solved it.
My OS X Server 10.2.3 system went through a power outage a few days ago. I rebooted it this morning and it dumped me into the console login just before showing the normal login screen. A look at system.log shows the following:
loginwindow: AuthorizationRef doesn't have a userID
loginwindow: exiting to console
WindowServer: loginwindow connection closed; closing server.
I tried a couple of things (fsck, diskutil repairPermissions) before looking at the system log. After that I tried deleting these two files: