On Feb 3, 2014, at 1:09 PM, Bruce Johnson wrote: > > On Feb 3, 2014, at 8:09 AM, Mugsy Lunsford <[email protected]> wrote: > >> Here's one view from Directory Utility, for the Administrators Group. >> Yes, there are multiple admin accounts; all systems in this store are >> configured with all accounts needed in the store, so that any mac can be >> used in any capacity. It's a redundancy that allows me to bring one home to >> fix it without crippling the store. >> >> http://imgur.com/3KYgoyg >> >> Any suggestions? I've been trying various terminal commands, have done >> everything I could find to try short of Archive and Install, which is next >> on my list if I can't think of anything else. I've downloaded BatCHMOD and >> Permissions Repair, both cannot run on that system. > > Ugh. The 'Crashes when connected to the network' issue is likely unrelated to > permissions, and the rest sounds like it expects to be connected to the > network to work.
The database is on the server, which it can't reach from here, so I've been unable to replicate the crashing. The error messages revealed when inside their building before it crashes are all about locations of pertinent files, which are all where they are supposed to be. I think all the confusion between users and groups, and memberships thereof, in addition to the lack of an owner on the volume, is the reason for the crashing. Additionally, an attempt by the POSiM support staff to remotely access the computer resulted in crashing. I've never seen anything this weird with permissions before, so was hoping to fix the root cause, while sorting it out. Running out of time, so I tried an A & I last night, and although it's running fine today, the permissions are still fetching. > My first guess on the apps issue is to see what the user/group permissions > are (including ACL's, if there's a '+' on the long directory listing in > Terminal). ACL's can definitely Mess You Up if misapplied. You can do stuff > like this <http://krypted.com/mac-security/recursively-remove-acls/> to clear > them all out before trying to get them straightened. Krypted is a great site > for this kind of stuff. > > If you only see a uuid not a name in terminal when the machine is > disconnected, this means that the user who 'owns' this stuff is not present > in the local directory, and any permissions changes must be done the hard way > (chown & chmod as root) by comparing it to a working system. changes made via chown and chmod by root are ignored on this system. > If "everything" means EVERYTHING, not just the POS software, nuke&pave it if > Disk Utility Repair Permissionsdoesn't fix it. (This is the one time where > Repair Permissions might actually be something more than a placebo) > > Me I'd probably say 'screw it' and nuke&pave followed by restoring data. Going to take it back in and format/clone from existing system. Really hoping that these permissions issues aren't on some sort of multi-clone creep all over the building. -- You received this message because you are subscribed to the Google Groups "StrataList-OT" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/stratalist-ot. For more options, visit https://groups.google.com/groups/opt_out.
