[b_caceres]

The process for setting a persistent client view option for a server volume is laid out at this Apple KB note:

http://docs.info.apple.com/article.html?artnum=107482

On our servers, the owner of the volumes and directories was an administrator account. I created a dummy standard user named “view,” made it the owner of the folders I wanted to set up, then logged in remotely as “view” and cleaned up the views. Now all the remote clients see a tidy initial list view.

[b_caceres]

Has anyone ever commented on how opaque it is to call these kinds of accounts “mobile”? I’m managing desktops, not laptops; the computers aren’t going anywhere, nor for that matter are the users. For our needs, all the files a user works on should remain on their local drives.

I found the above-linked article far more illuminating than the pounds of documentation I’ve gathered so far. You guys are invaluable.

I just have two further “how does it work” questions to help me make sense of all this:

(1) Once the switch is accomplished, what happens to the user if the server is offline for whatever reason? Can users authenticate locally again to access their local files, or are their desktop machines invalided?

(2) Suppose a user tries to log in from a different computer on the network using a valid login and password. Is authentication tied to the local machine solely?

[b_caceres]

Here’s how aliases behave.

1. I connected to the two “sister” share points through Command-K. Both share points appear and act normally.

2. I select both shares and make aliases, then Get Info on each while the shares are still mounted. The “Original” is indicated as XXX and YYY for each. Everything is still OK. I leave the Get Info windows open.

3. Next I unmount both share points. The “Original” info disappears and only the “Select New Original” button is available.

4. I doubleclick on the aliases. Though the alias names retain their original file names (“XXX alias” and “YYY alias”), the “Original” info for both has changed to just one of the two sister share points (“XXX”). Both aliases now point to the one same share point and are for all intents and purposes two aliases to one share point.

This is similar to the Dock behavior. When first installed, the Dock icons work properly. Once the share points are unmounted and then remounted, both Dock icons take on one of the share points names and act as though they were the same file.

This is just baffling.

[b_caceres]

Are you certain about nested AFP shares in Panther server? I found the following on page 162 of Schoun Regan’s “Mac OS X Server Panther”:

[QUOTE] Mac OS X Server can host many share points simultaneously, including share points inside other share points. Using share points inside other share points is a great way to allow graduated access for complex file structures.[/QUOTE]

Even so, the problem also extends to the server that consists of a single volume divided into two folders (each folder being a share point).

In considering the variables, one thing we thought was that somehow users with 10.3.9 are affecting the servers, which then affect the other non-10.3.9 users. Is this plausible?

[b_caceres]

Thank you all for your help. Using changeip to change the hostname did the trick.

[b_caceres]

When I use “dig -x” alone I get an “invalid option” error from the application and a list of permitted options.

When I try “dig -x 192.168.2.199” (the server’s IP) I get:

; <<>> DiG 9.2.2 <<>> -x 192.168.2.199
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42200
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;199.2.168.192.in-addr.arpa.    IN      PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   86400   IN      SOA     nsdc.ba-dsg.net. dnsadmin.ba-dsg.net. 2003070101 86400 3600 604800 86400

;; Query time: 798 msec
;; SERVER: 151.203.0.84#53(151.203.0.84)

When I try “dig -x” and the domain name I get “invalid IP address.” Same for the expected qualified domain name.

Plain old “dig” gets me:

; <<>> DiG 9.2.2 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1769
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 9

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       441157  IN      NS      K.ROOT-SERVERS.NET.
.                       441157  IN      NS      L.ROOT-SERVERS.NET.
.                       441157  IN      NS      M.ROOT-SERVERS.NET.
.                       441157  IN      NS      A.ROOT-SERVERS.NET.
.                       441157  IN      NS      B.ROOT-SERVERS.NET.
.                       441157  IN      NS      C.ROOT-SERVERS.NET.
.                       441157  IN      NS      D.ROOT-SERVERS.NET.
.                       441157  IN      NS      E.ROOT-SERVERS.NET.
.                       441157  IN      NS      F.ROOT-SERVERS.NET.
.                       441157  IN      NS      G.ROOT-SERVERS.NET.
.                       441157  IN      NS      H.ROOT-SERVERS.NET.
.                       441157  IN      NS      I.ROOT-SERVERS.NET.
.                       441157  IN      NS      J.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
B.ROOT-SERVERS.NET.     604696  IN      A       192.228.79.201
C.ROOT-SERVERS.NET.     576626  IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     576626  IN      A       128.8.10.90
F.ROOT-SERVERS.NET.     576627  IN      A       192.5.5.241
I.ROOT-SERVERS.NET.     576627  IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     528233  IN      A       192.58.128.30
K.ROOT-SERVERS.NET.     576626  IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     576542  IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     576626  IN      A       202.12.27.33

;; Query time: 454 msec
;; SERVER: 151.203.0.85#53(151.203.0.85)

[Author]

Posts