Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 55

Thread: File Sharing

  1. #21
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Yep, if you've got it acquiring its IP address from a DHCP server, users won't know from day to day where it is.

    If you've got corporate DNS running, it'd help you a lot to assign a static IP address within its subnet but outside the range used by the DHCP server and have it listed in DNS. Configure its ethernet interface manually in Network prefs, and remember to clone in the netmask, default router, and name resolver values as fed from the DHCP server on the same subnet.

    Then users can find the machine by name over IP.

    Even without a DNS name, static assignment of an otherwise unused address outside the DHCP server's range will allow your users to nail it using the same IP address every time.

    Jazzbo

    [This message has been edited by Jazzbo (edited 10 February 2003).]

  2. #22
    Join Date
    Apr 2000
    Posts
    693

    Default

    Or you could try this.

    Dynamic DNS service. The bomb-diggety.

  3. #23
    Join Date
    Jan 2001
    Location
    Austin, TX, Los Estados Unidos de Mac
    Posts
    672

    Default

    I actually have bigger problems now. I got everything set up the way I wanted it on the iMac, and then went around to the other Macs to test their connections and set up aliases in their Apple Menus to make connecting quick.

    The mysterious thing is that I was able to connect to the iMac with the other four Macs the first time I tried last night, but when I tried again a little later, all but one got an error message, "The connection to this server has been unexpectedly broken". When I double-clicked on the iMac's name in the Chooser, then clicked "OK" to connect with the default username, the error message came up. The error also came up if I tried connecting as a guest, or as a user whose home is still in the Users directory of the OSX volume. After the error message, the iMac continues to be listed in the Chooser. This error came on two systems running OS7 and one running 8.5. The fourth, running 8.6, continues to be able to make a connection to the iMac. The situation was not improved by rebooting all of the Macs.

    I only tried one kinda wonky thing. I wanted to be able to connect via AppleTalk to the iMac from another Mac without using a password, so I left that field blank for the graphics account (the "NP" trick in NetInfo didn't work- I was unable to connect no matter what was in the password field). However, if you try to log into the same account via FTP, it won't work because you have to have a password. So I tried setting up a second graphics account with a password just for FTP access, and set its home to the same graphics volume as the first graphics account, and its shared directory to the same Public directory on that volume. This must've caused some confusion in the accounts because different directories were coming up on different logins, so I changed the second account back to its original settings.

    Another interesting thing is that when I connect to the iMac from the one machine running 8.6 that doesn't get the broken connection error, I am able to mount the Public directory for the graphics account, as well as the volume that contains it, itself. This happens in FTP as well- in fact, if I navigate up to the root in FTP, I can also get into the directory for the OS9 volume on the internal drive. Plus, if I try to use FTP to upload into the Public directory of the graphics account, it gives me a permission error- but it will let me upload to root of the volume that contains the Public directory.

  4. #24
    Join Date
    Aug 2000
    Location
    arlington,vermont
    Posts
    826

    Default

    Can i sneak in here and ask a question without trying derail the whole thread? I have been glued to my computer for hours trying to find a solution and it seems that at least 2 of you are osX/permisions gurus. I have a major migrane so i will be brief: (rubbing throbbing temple)....here goes:

    Is it possible in os10.2.3 to save a file across a network in such a way that it land's with a R/W permision rather than the INFURIATING R/O. I am doing kind of what the_anarch is doing, and have been trying to solve this "simple' problem for month's. My life would be so much less complicated if i could find a way to do this. if you want me to start a seperate thread for this i will, but it seems to sort of go hand in hand with whats being discussed. I just want to be able to have someone who creates a file and saves it on our print server, then to have another person be able to open the file and have R/W access to it without needing to have person A go back and switch the preferences manually because she forgot to do after she saved the file.

    *sigh* thanks for listening..i may now go back to searching out this answer and rubbing my head.

  5. #25
    Join Date
    Jan 2001
    Location
    Austin, TX, Los Estados Unidos de Mac
    Posts
    672

    Default

    Makes me wish Apple had made an option for installing OSX in some kind of "single user" mode. This permissions crap is mind-boggling. I'm wondering what percentage of OSX users need that kind of security- my guess, admittedly uneducated, would be less than 20%.

    Actually... wouldn't a single-user mode in OSX simply be running OSX and not creating any other accounts? If the same user created all the files on an OSX machine, then wouldn't that user have complete permissions to do what they wanted, whether or not they were physically at that computer or logged in remotely?

    And I still can't figure out why all but one of our Macs can't connect to the OSX machine at all...

  6. #26
    Join Date
    Aug 2000
    Location
    arlington,vermont
    Posts
    826

    Default

    Connecting to NON-asX machines from an osX machine requires appletalk to be turned on in the osX network preference pane. I have had the same problem you speak of trying to connect to an osX machine and getting the msg refering to broken connections...it required a restart of the machine i couldn't connect to and seemed to be caused by "trying' to connect to that machien while it was sleeping. And i agree 100% with your take on why can't apple make osX less secure if we choose to do so.

  7. #27
    Join Date
    Jan 2001
    Location
    Austin, TX, Los Estados Unidos de Mac
    Posts
    672

    Default

    Well, I tried a whole bunch of things... restarting the OSX Mac, restarting the other Macs, making sure the OSX Mac ain't asleep... still the same problem: our System 7 Macs (both 7100s) and OS 8.5 Mac (a beige G3) cannot connect to the OSX Mac, while the OS 8.6 Mac (a 6100 w/G3) can.

    I'm really not sure what's going on; I guess if Jazzbo doesn't have any more suggestions for me, I'll have to consider reinstalling OSX. Or, if this is possible, some kind of low-level reset of all accounts?

  8. #28
    Join Date
    Aug 2000
    Location
    arlington,vermont
    Posts
    826

    Default

    Let me look though the "Missing Manual" tonight and see whats in there for ideas.

  9. #29
    Join Date
    Aug 2001
    Location
    Grangeville, ID USA
    Posts
    9,122

    Default

    ?I have at times had settings that didn't allow connections on my different computers but I have never had the types of troubles you are having. I currently run an 8500 in OS9 running Timbuktu to control my Quicksilver running 10.2. I also have a B&W that switches back and forth from 9 to X. There are other computers in the LAN and depending on their settings I may or may not see them.

    ?When I run Server on the QS it's a whole new kettle of fish. Then I have the option of turning broadcasting on/off of the Servers address. All my computers though are manually configured, no DHCP for me, and all I usually have to do is enter the address of the Server and I'm in.

    ?That is as long as TCP/IP is enabled. File Sharing is on. Permissions are correct and so on.

    ?I'll give Jazzbo a call just in case he didn't see this. He's probably buried at work or chasing some dame, an even better reason to be busy

    Rick

    Batsignal invoked to Jazzbo!

  10. #30
    Join Date
    Aug 2000
    Location
    Concord, CA
    Posts
    7,056

    Default

    Must be an all nighter. k

  11. #31
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    I see two problems happening, connectivity from earlier OS versions and account/group id for file-access control. Connectivity in this posting, file-access in the next.

    On the connectivity front, I can't remember when AppleShare-over-IP arrived for clients, but it wouldn't surprise me if it was around OS8.6 time. Prior to whenever that was, only AFP-over-AppleTalk was supported in the Chooser.

    First off, then, I'd double-check on the OSX:

    AppleTalk enabled in Network;

    Sharing has Personal File Sharing on (of course), with a "useful" "Computer name" at the top of the panel.

    Next, you should be able to wander around to any Mac on the subnet running OS9 or earlier, launch Chooser, click "AppleShare", and see your OSX hostname show up as an available server.

    If the hostname shows up in all the Choosers, we're ready to debug bringing the connection up. If it doesn't show up in the Chooser, the AppleTalk Zone isn't connecting them.
    -----

    Dredging amongst partially-blown synapses, I remember that we used to have to run something special to have AppleTalk zone information cross subnets. The reason for this is that a lot of AppleTalk-based host and service identification is done with what are called "broadcast" packets, launched by each host onto its ethernet (or LocalTalk) interface and repeated all over the LAN. Thing is, routers will NOT pass broadcast packets from one subnet (interface) to another. That limits visibility to hosts on the same subnet.

    Are all of your hosts on one subnet, or is there a router in between? If there's a router in there between the potential clients and the OSX AFP-server, then without some sort of special AppleTalk Zone repeater bridging the two subnets, the only way for a client on the other subnet to connect to your OSX as AFP server is via AFP-over-TCP -- press the "Server IP Address" button in Chooser and load in the IP address of the OSX. If the OS predates AppleShare-over-TCP, that button won't be there and the client can't connect via an IP address.

    --

    In Terminal on the OSX, netstat -an | grep 548 should report a line like:

    tcp4 0 0 *.548 *.* LISTEN

    if it's listening for AppleTalk-over-TCP connections. If there are any hosts connected that way, you should also see an "ESTABLISHED" line for each.

    --

    There are rumors that some OSX release or other (Jag?) "dropped support for AppleTalk". If so, that should mean native AppleTalk, directly onto ethernet, not AppleTalk-over-TCP. It could be an unhappy mix of a new OSX release trying to be an AFP server which can only do so over TCP and very old (OS8.5 and earlier) clients that may not handle mounts via AppleTalk-over-TCP well, if at all.

    Did you get a Software Update in the mix between working and not?

    Jazzbo

  12. #32
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    The bit about creating an additional account sharing the same home directory as your Graphics owner worries me a bit.

    First off, on Unix systems, account identification is done in four pieces:

    0. In Terminal, run nidump passwd . which we'll be referring to as we go. The passwd table is a colon-separated list of fields defining users.

    1. username -- The first field is the "short name" in OSX lingo, and needs to be unique in the table. In Terminal, when you run ls -l ("ell-ess dash-ell") to get a long-listing of files, each file's owner will be this field. When you use connection methods like ftp, scp, and so on, it's this username that identifies the account in question.

    2. uid number -- The third field is the user identification number associated with this username. This is what's actually stored on-disk to indicate file ownership. The surprise is that it is NOT required to be unique. That ls -l thing earlier simply reports the first passwd table entry found with the uid number matching what's stored as ownership of a file. If multiple users exist with the same uid number, each equally owns the files, each has its individual entry in the passwd table, so each has its own password for access.

    3. gid number -- The fourth field is the group id number of this user's default group, and is cross-referenced through the group table, formatted similarly to the passwd table (nidump group . if you want to inspect it).

    4. GECOS field -- the eighth field is the GECOS field, described in OSX as the "long user name". OSX is the only Unix operating system I know of that supports login authentication based on the GECOS field, so it's also the only one I know of where there's an implied uniqueness requirement. Someone once told me what GECOS stood for, but age is catching up with me and I can't remember.
    ---

    Okay, so let's say we have two entries like this:

    ---- passwd table extract ----
    graphix1:vgcA3jT9GT52A:504:20::0:0:Graphics_Projec t1:/Volumes/G1:/bin/tcsh
    graphix2:2343ZXBUZZea1:505:20::0:0:Graphics_Projec t2:/Volumes/G1:/bin/true
    ---- end passwd table extract ----

    we now have a problem! Both of these accounts, though with different usernames, passwords, and GECOS long-names, share the same home directory. The real problem is that they have different uid numbers. Any file created by one in its home directory will NOT be owned by the other.

    If they really need to peacefully coexist and share file ownership, they need to have the same uid number.

    What I would do is:

    1. In NetInfo Manager, change the uid number of the second to match the first, then

    2. As root in Terminal, chown -Rh graphix1 /Volumes/G1 to reset ownership of all the files on the G1 volume to the graphix1 user -- which really means to both.

    NOTE: The last field in a passwd table entry is the user's "login shell", which defines which of the Unix shell programs is to be executed if this user logs in to a Terminal window. For graphix1, it's one of the standard shells (tcsh). For graphix2, I set it to the "true" command, which exists but simply exits. FTP access is disabled for accounts who don't have standard shells. AFP access should still work (I think).

    --

    By the way, I just spotted in the passwd table that OSX is using an asterisk (*) in the password field to say "this user has no password".

    --

    Did you try the setgid trick on the Public folder on that volume?

    Jazzbo

  13. #33
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Another thought about those older OS versions...

    At what point did HFS+ come out? OS7? OS8? 8.5? At some point back there far enough, AFP-served HFS+ volumes oughta confuse a client.

    Jazzbo

  14. #34
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    And i agree 100% with your take on why can't apple make osX less secure if we choose to do so.

    Remembering that Unix file permissions are fundamental to the file-systems and program execution, that's a lot easier said than done! I'm not sure I can think of a way to do it. (AT&T Research probably could, though.)

    Jazzbo

  15. #35
    Join Date
    Jan 2001
    Location
    Austin, TX, Los Estados Unidos de Mac
    Posts
    672

    Default

    --> First off, then, I'd double-check on the OSX:
    -->
    --> AppleTalk enabled in Network;

    Not sure, but I think so. I'll check tomorrow. Frankly I can't imagine that it isn't.

    --> Sharing has Personal File Sharing on (of course), with a "useful"
    --> "Computer name" at the top of the panel.

    Check- the "useful" name is Secretariat- all the computers and drives on our network are named for famous horses, except for the 6100 which was named for my first horse: Pokey. We also have Man O' War, Traveller, Trigger, Silver, Bucephalus, Custom-Made, Comanche, Kelso, and Champion.

    --> Next, you should be able to wander around to any Mac on the subnet
    --> running OS9 or earlier, launch Chooser, click "AppleShare", and see
    --> your OSX hostname show up as an available server.

    Check- every computer sees the OSX Mac, but only Pokey can successfully connect.

    --> In Terminal on the OSX, netstat -an | grep 548 should report a line like:
    -->
    --> tcp4 0 0 *.548 *.* LISTEN
    -->
    --> if it's listening for AppleTalk-over-TCP connections. If there are any
    --> hosts connected that way, you should also see an "ESTABLISHED"
    --> line for each.

    I'll have to try this tomorrow.

    --> There are rumors that some OSX release or other (Jag?) "dropped
    --> support for AppleTalk". If so, that should mean native AppleTalk,
    --> directly onto ethernet, not AppleTalk-over-TCP. It could be an unhappy
    --> mix of a new OSX release trying to be an AFP server which can only do
    --> so over TCP and very old (OS8.5 and earlier) clients that may not
    --> handle mounts via AppleTalk-over-TCP well, if at all.

    If this is in fact the case, Apple will be getting their first letter from me. Making OSX so that it doesn't run on pre-OS8.6 systems? Completely understandable. Making OSX so it can't TALK to pre-OS8.6 systems? As you've heard me say before: Infuriating.

    --> Did you get a Software Update in the mix between working and not?

    I'm pretty sure I did not. I've downloaded updates for the peripheral software, but not for the OS. Just got the update for Safari today, I don't know what they changed. I also tried out SafariTabs today- a complete waste of time.

  16. #36
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Hey, tm...

    Can i sneak in here and ask a question without trying derail the whole thread? I have been glued to my computer for hours trying to find a solution and it seems that at least 2 of you are osX/permisions gurus. I have a major migrane so i will be brief: (rubbing throbbing temple)....here goes:

    You too, eh? That's one of the reasons I've been outta touch for a coupla daze. Sorry to hear it and hope you've recovered.

    Is it possible in os10.2.3 to save a file across a network in such a way that it land's with a R/W permision rather than the INFURIATING R/O. I am doing kind of what the_anarch is doing, and have been trying to solve this "simple' problem for month's. My life would be so much less complicated if i could find a way to do this. if you want me to start a seperate thread for this i will, but it seems to sort of go hand in hand with whats being discussed. I just want to be able to have someone who creates a file and saves it on our print server, then to have another person be able to open the file and have R/W access to it without needing to have person A go back and switch the preferences manually because she forgot to do after she saved the file.

    How is the connection to the print server being made? NFS or AFP? FTP? Is the file being stored in the user's home directory, or a utility print-spool directory? How many users are involved all-told?

    I could see setting up a print-server drop-box, but turning on its global read/execute permissions, but only if you trust everyone to play nicely in the directory. Here's an AFP solution:

    --- passwd entry ---
    printspool:*:65000:20::0:0:Print Spool:/Volumes/Local/printspool:/bin/tcsh
    ---

    In printspool's Public directory (folder), create one folder per printer if needed, or just one inbound-spool folder -- other than name, they're all the same:

    ## In Terminal as root ##
    mkdir -p ~printspool/Public/Spool
    chown printspool ~printspool/Public/Spool
    chmod 777 ~printspool/Public/Spool
    ## end Terminal session ##

    The Spool folder inside the printspool user's Public folder is globally accessible. I just tested this, connecting in Guest mode, dropped a file into the Spool folder, and the file itself is globally-writeable afterwards.

    Note that if you authenticate the AFP session as an admin-capable user, you won't be offered printspool's Public folder for mount, but the whole disk volume containing it. Authenticated non-admin users will, however.

    Jazzbo

    [This message has been edited by Jazzbo (edited 13 February 2003).]

  17. #37
    Join Date
    Jan 2001
    Location
    Austin, TX, Los Estados Unidos de Mac
    Posts
    672

    Default

    Woof- you posted three times in the amount of time it took me to write that last one.

    As far as HFS+ goes- that was introduced in 8.1. I know I'm sounding like a broken record, but if HFS+ is the issue, why did this not come up when I was sharing an OS 9.0.4 machine with System 7 machines? I mean, I would actually find it hard to believe that a File Sharing client would even be involved in the HFS+ layer of access- I'd think that's between the hard drive and the processor of the host computer. The client doesn't directly access a host's hard drive, does it? I mean, then it would have to have whatever drivers would be necessary for accessing FireWire-based drives, USB-based drives, LVD-based drives, ATA-based drives, etc etc.

    As for the group/owner ID issues, I'll deal with that after I get the connectivity fixed. No point in worrying about what accounts can access what directories if three of our four Macs can't even access the host. I never did try the setgid trick, but I'll try it when I get to that stage of this process.

    I guess I would like to re-ask the question about resetting all the accounts- if not for EVERY account (which would include the root), then at least for all the ones created after. I mean, I can't imagine that it's as simple as using the System Preferences panel to delete whatever users are left (after I reverted their home directories to the Users directory, of course).

  18. #38
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    I hear you about the problems caused by dropping connectivity support for really old OSes, though I'd be happy to see ethertalk gone. Just some random thoughts on it.

    Ethertalk (AppleTalk directly over ethernet) was a really bad idea in the first place. My opinion is that some networking engineer in the olden days at Apple figured "I can do inter-host networking better than IEEE can, so screw this IP stuff, I'll make AppleTalk use ethernet as well as LocalTalk wires." Probably s/he sold it by telling Marketing that users wouldn't have to learn how to assign IP addresses, netmasks, default routers, and name-servers, and Apple always believed users shouldn't have to learn anything.

    It was an acceptable protocol over LocalTalk wires mainly because everything was so damned slow back then that it couldn't hurt it much. The overhead with ethertalk is extreme, hammering every interface on every host on the subnet, and then you can't run it on multiple subnets without repeaters forwarding the whole bushels-and-pecks of broadcasts, defeating the purpose of routers NOT forwarding broadcasts.

    AppleTalk runs like "Got a sec? Sure. I've got a few bytes for you, want 'em? Sure, I'd like a couple of bytes. Here are a few bytes; get 'em? Yep, I got a few bytes. I've got a few (more) bytes for you, want em? Sure, I'd like a couple more bytes. Here..." AWFUL!!

    At some point, no vendor can support archaic OS releases or networking protocols. It just weighs down the new OS, its libraries, its protocol stacks to the point of running like a slug. OSX is already huge enough without trying to support three major releases back (9, 8, 7). As well, trying to maintain compatibility with ancient, unupdateable networking protocols may be flat-out impossible. Same with file-systems. If a file-system looks like its modern definition across network mounts, what do you do with a client that doesn't understand the file-system layout?

    I know none of that helps much,
    Jazzbo

  19. #39
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    I guess I would like to re-ask the question about resetting all the accounts- if not for EVERY account (which would include the root), then at least for all the ones created after. I mean, I can't imagine that it's as simple as using the System Preferences panel to delete whatever users are left (after I reverted their home directories to the Users directory, of course).

    Actually, it is that easy, in the Accounts pref. You may have to manually remove the /Users/username directories afterwards.

    IMPORTANT: You're right on about re-aiming their home directories to the /Users/username locations before deleting them in Accounts.

    Jazzbo

    [This message has been edited by Jazzbo (edited 13 February 2003).]

  20. #40
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    The reason I raised the HFS+ issue is that, other than with WebDAV, Samba, and old-old-old AT&T RFS (Remote File Sharing), remote file-system mounts typically do require the client to understand the way the file-system works.

    AFP is a remote disk-mount, and it worries me greatly to export HFS+ to an OS that doesn't understand it. I just don't know what sort of client-version information may come to the AFP server such that it can hide the "Extended" part of the volume definition from the client machine.

    Values like the number of blocks in the filesystem, the number of file-slots, the remaining free-space can be meaningless to the client. Remember when you've AFP-mounted a really large volume on an old Mac OS version and instead of showing 8Gb of available space on the volume, it reported 2Mb or some such? The field-width holding free-space grew vastly in HFS+, and you wouldn't notice in small volumes, but large ones...

    It's not the hardware/driver layers that apply for network mounts (of any sort), but the file-systems constructed on the devices that matter. So FW/SCSI/USB/ATA/etc. aren't issues except on the server; but the client probably needs to know how to play fair within the HFS, HFS+, or UFS file-system.

    HFS+ also changed the maximum filename length, and I don't know what a pre-HFS+ Mac would do if a network-mounted volume had files with names longer than its compiled-in maximums. The name-length for a volume is even shorter than the allowable name-length of a file or directory (folder).

    I just don't know the answers here. My machines are OSX, OS9.1, and OS9.2, so I can't test it out. Not sure I'd want to except with a test volume that held no important files at all.

    Shoot, two negative posts out of three,
    Jazzbo

    [This message has been edited by Jazzbo (edited 14 February 2003).]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •