[JIA]

I've searched the forums and haven't found anything, so here goes:

In the past week my laptop (12" PowerBook, 10.3.5, 1.25GB RAM) is having some serious problems including:

1. In the Sharing preference pane, I cannot select "Personal File Sharing." When I check the box it automatically unchecks.

2. I cannot print to a shared printer (HP LaserJet 1012). The printer is seen on the network and I have been able to print to it in the past. Now "an error has occurred while attempting to print..." which causes the given application to crash.

3. When attempting to install any application that requires admin authentication, I get a message that �the application to be installed requires Administrator or higher level access privileges.� This happens using any administrator account and �root.�

No new programs were installed at the time these problems started and I haven�t been able to find any suggestions as to how I might fix this. Any suggestions are appreciated.

[CubeWannaB]

It's unsettling that you have been logging in as root. The main reason not to log in as root is because it is so easy to damage your system. And your system seems damaged. Perhaps this is not a coincidence.

[cpac]

more usefully:

have you tried repairing permissions?
have you tried repairing your disk?
is you disk almost full?
have you tried cleaning out caches?

[drive-thru]

You say the PB was basically new when the problems started.
If none of the above works, I would simply backup any data you want to keep, wipe the drive and do a fresh install of the OS.
Sure you can try to fix it, but unless repairing permissions or the disk works the problem is probably going to be tricky to track down., especially if you accidentally messed something up in root.

To repair permissions, boot from the OS X cd and click the Apple menu to open up Disk Utility. From there you can verify/repair the permissions and you hard drive. Also if you have DiskWarrior or TechTools it is worth doing a scan of the disk to make sure it is not the fault.

[Horsepoo!!!]

One time I dreamt I was being chased by a werewolf. Then I tripped over my own feet. And the werewolf was gaining on me... Oh wait...you didn't mean nightmare in the literal sense.

Might be a little difficult to fix the problem...take it one step at a time. And if all else fails, backup and reinstall.

[CharlesS]

I agree with CubeWannaB - this could be damage caused by logging in as root.

I would:

1. Archive and install

2. Repair permissions

[Millennium]

Something is seriously messed up with your system. It looks as though several important system files have been deleted; this would explain the issues you're having with sharing and authentication.

This is probably going to require a reinstall of the system to fix (your user folder should be fine, though, so you can back it up and restore it as normal). However, I've got a few questions in the interest of figuring our how and why this happened:

1) It sounds as though you just got this PB; am I mistaken? If you just got it, is it new or used?
2) You've been logging in as root, I see. How long have you been doing this? Did you ever do it before these problems started?
3) Have you deleted anything from the /System folder, or anything outside of /Applications and your own home folder?
4) Do you use fink, gentoo, or darwinports? What sorts of things have you used these for?

If we can figure out how this happened, we can prevent it from happenning again. I can offer this advice for starters, however: never log in as root. It is never necessary, and doing so causes subtle damage to the system which can be difficult to repair. Always use the normal authentication dialogs, or sudo in the Terminal, to do things which require elevated access privileges. Admin accounts are safe to use regularly, but root is not.

[Millennium]

Some others have mentioned using Repair Permissions as a possible solution. If you can get this to work then give it a try, but I'm not sure you'll be able to get it to work. Doesn't the Repair Permissions feature require you to authenticate as an admin or root? If you can't do that, then you won't be able to repair your permissions.

[JIA]

I did an Archive and Install and everything seems to be working as usual.

But to answer some of the questions including Millennium's: The PB was purchased brand new in August. I never logged into root until I got a message that I couldn't authenticate as myself and only then did I try authenticating as the root user. I do not have fink or anything similar running on the system.

[Millennium]

Originally posted by JIA:
I did an Archive and Install and everything seems to be working as usual.

But to answer some of the questions including Millennium's: The PB was purchased brand new in August. I never logged into root until I got a message that I couldn't authenticate as myself and only then did I try authenticating as the root user. I do not have fink or anything similar running on the system.

Hmm. That is disturbing. What could cause these files to disappear, if nothing had been installed and you never logged in as root?

Is it possible that your PowerBook got hit by some kind of power surge? Did you turn it off while it was working on some files, perhaps?

[leperkuhn]

Originally posted by Millennium:

Is it possible that your PowerBook got hit by some kind of power surge? Did you turn it off while it was working on some files, perhaps?

Journaling should prevent even that from being a problem.

[utidjian]

Originally posted by Millennium:
Hmm. That is disturbing. What could cause these files to disappear, if nothing had been installed and you never logged in as root?

Is it possible that your PowerBook got hit by some kind of power surge? Did you turn it off while it was working on some files, perhaps?

I have had this happen about three times so far in my lab of iMac G4 FP 17"ers. Seems to be a random problem but I wouldn't rule out power outages as being the prime suspect. A couple of them might take ages and never fully bootup. The blue candy stripe seems to stall in random spots... still pulsing. Booting from CD and running Disk Repair nad Repair Permissions doesn't help. Also ran the hardware check utility and everyhting came up clean. The last one was already booted but "forgot" how to print. For some reason the /var/spool/cups folder had disappeared. Copying a "known-good" /var/spool/cups folder from a different iMac didn't help. The simplest and quickest solution for me was to just re-image via CCC from my master image on a firewire disk.

It is frustrating but, as I said, for me the implest thing to do was re-image. It has only happened three times amongst a dozen iMacs in the past 9 months. I never lose any user data because no user data is kept on the individual Macs. All user data is kept on the file server.

Some of the systems had the root account enabled but none of those had the problem and root was rarely if ever used as a login account. Those with root enabled have since been disabled now that that feature finally works properly. All were updated regularly.

[utidjian]

Originally posted by leperkuhn:
Journaling should prevent even that from being a problem.

I think you are mistaken in how journaling works in Mac OS X. If a file is open and being written to when the power fails... it is garbage and tagged as such. This doesn't happen all the time but it can happen some of the time. Journaling does not prevent data loss when the power goes off or the system crashes... journaling does minimize the loss and the possibility of a loss. The main advantage is that it speeds up bootup by not forcing the system to go through a very lengthy (with large disk sizes these days) fsck process. The system just checks the journal against the filesystem and ignores anything that is not consistent with the journal.

For more in depth info see:
http://www.backupbook.com/03Freezes_...ournaling.html
and
http://www.afp548.com/articles/Jaguar/journaling.html

[Millennium]

Originally posted by utidjian:
I think you are mistaken in how journaling works in Mac OS X. If a file is open and being written to when the power fails... it is garbage and tagged as such. This doesn't happen all the time but it can happen some of the time. Journaling does not prevent data loss when the power goes off or the system crashes... journaling does minimize the loss and the possibility of a loss. The main advantage is that it speeds up bootup by not forcing the system to go through a very lengthy (with large disk sizes these days) fsck process. The system just checks the journal against the filesystem and ignores anything that is not consistent with the journal.

For more in depth info see:
http://www.backupbook.com/03Freezes_...ournaling.html
and
http://www.afp548.com/articles/Jaguar/journaling.html

Journaling can't prevent individual files from being corrupted, but it should be able to prevent the filesystem itself from being corrupted. I thought we were dealing with a case where the filesystem became corrupted even though journaling was in place. That's what we need to figure out.

[leperkuhn]

Originally posted by utidjian:
I think you are mistaken in how journaling works in Mac OS X. If a file is open and being written to when the power fails... it is garbage and tagged as such. This doesn't happen all the time but it can happen some of the time. Journaling does not prevent data loss when the power goes off or the system crashes... journaling does minimize the loss and the possibility of a loss. The main advantage is that it speeds up bootup by not forcing the system to go through a very lengthy (with large disk sizes these days) fsck process. The system just checks the journal against the filesystem and ignores anything that is not consistent with the journal.

For more in depth info see:
http://www.backupbook.com/03Freezes_...ournaling.html
and
http://www.afp548.com/articles/Jaguar/journaling.html

you should read your own links.

The problem with non-journaled systems

If a power-outage or computer freeze occurs during this write process (after the file has been written and before the meta information has been properly added, the file system loses the file and creates inconsistencies. And it doesn�t just create inconsistencies in the file meta data, the problems affect directories as well. When you update files within a directory, add files to the directory, or delete files from a directory�and the power goes out or the system freezes, the directory is not updated correctly and is therefore corrupted.

In an attempt to fix itself, Unix systems like Mac OSX and Linux will run a program called �fsck� (file system check) in order to validate all entries in the file system and ensure sure that file system blocks are allocated and referenced correctly. It will find this corrupted directory entry and attempt to repair it. There is no guarantee that fsck will manage to repair the damage (hence why programs like those from TechTools and Symantec are important). Sometimes, in a situation as described above, all the directory entries can be lost or the meta information for the file can be lost. This is where journaling file systems help.

Rather than modifying the data in the appropriate block being written to, a journaling file system will store a copy of the inode and appropriate blocks for the file in new locations on the disk. The in-memory list of inodes will be changed to point the appropriate file to the new inode as well. Just like a database transaction, a journaling file system transaction treats this sequence of changes as a single, atomic operation�the journaling file system tracks changes to file system meta-data and/or user data in a way that the transaction guarantees that either all or none of the file system updates are done.

The journal in a journaling file system is simply a list of transactions. Before the file system makes those changes, it creates a transaction that describes what it�s about to do. Once the transaction has been recorded to disk, the file system goes ahead and modifies the metadata or user data. All changes and appends and deletes are logged to a growing part of the file system�s journal, also called the log. Every once in awhile, the file system will checkpoint and update the on-disk list of inodes, as well as freeing the unused parts of files.

In the event of a system failure, the file system is restored to a consistent state by replaying the journal. The file system inspects only those portions of the meta-data that have recently changed. Therefore, after a crash a journaled file system will come online almost immediately. All it needs to restore the correct directory and file information is at most a few blocks, which it has readily available in the journal�s log. An fsck after a power failure will take less than a second.

[Moose]

Originally posted by Millennium:
I can offer this advice for starters, however: never log in as root. It is never necessary, and doing so causes subtle damage to the system which can be difficult to repair.

I have no problem with you discouraging people from logging in as root, but please don't lie to them. Logging in as root does not intrinsically "cause subtle damage to the system." It does, however, make it shittons easier for you to do it yourself.

Root-level access is to be respected, not feared.

[piracy]

Originally posted by Millennium:
I can offer this advice for starters, however: never log in as root. It is never necessary, and doing so causes subtle damage to the system which can be difficult to repair. Always use the normal authentication dialogs, or sudo in the Terminal, to do things which require elevated access privileges. Admin accounts are safe to use regularly, but root is not.

While the advice to never log in as root is sound, and represents a best practice on Mac OS X, it is absolutely and utterly incorrect and inaccurate to say that doing so "causes subtle damage to the system". The reason logging in as root is not advised is because it is easier to cause damage, subtle or otherwise, to the system while logged in as root, graphically or textually. But to say that the act of logging in as root itself causes damage is dishonest and nothing more than a scare tactic.

[theolein]

utidjian: Did you look at the logs after you had these problems?

[utidjian]

Originally posted by theolein:
utidjian: Did you look at the logs after you had these problems?

Yes, the logs reported nothing unusual.

[utidjian]

Originally posted by leperkuhn:
you should read your own links.

The problem with non-journaled systems
....

[trimmage]

Correct. Those are problems with non-journaled filesystems. I was hasty in my response and did not include examples of how a journaled filesystem can have problems. Even a perfectly consistent journaled filesystem with perfectly consistent journaled files can still have corrupt files. Unfortunately the links I gave do not mention that even though the journaled file system (jfs) will faithfully write the meta-data to a journal, then to the file, and then update the journal... they mention nothing about the actual data being passed to the filesystem by the application actually being consistent. GIGO still applies.

IOW... it is up to the application to ensure that correct data is sent to the filesystem to be written to the file.

A power outage or system crash should not cause any data, good or bad to be written to a file if it is passed to a jfs to handle it. But a jfs in and of itself does not prevent bad data being written to a file. A jfs does not prevent bad meta-data being written either... hence the need for Repair Permissions. It isn't the jfs fault that permissions occasionaly get screwed up in Mac OS X, it is the application (the installer or whatever) that sends the incorrect meta-data to the jfs. The jfs faithfully writes that meta-data to disk.

There are a few possible circumstances where "data loss" can occur even when using a jfs:

1 The power dies or the system crashes before the data can be written to the jfs (the jfs didn't even know about it). This is the trivial case. It usually only affects a few files. In any case the system should be easily bootable with a consistent filesystem and the data you had up until the last succesful write should be fine.

2 The power dies or system crashes just as a file is created but it has not yet been written to. This can result in a non-existent or zero-length file(s).

3 The power dies or system crashes as a file is being truncated before being written to. This can result in a non-existent or zero-length or file(s) missing certain data at the end that the application requires.

4 All bets are off if it is a database that has been opened in binary mode for random writes. It is then up to the db to maintain its OWN journal (most do).

5 From my first link you can see that Mac OS X jfs does not do "data logging" so only the meta-data is journaled not the user data. ext3 is the only one with data logging (configurable but on by default).

All of this is assuming there are no bugs in the jfs.

In the case of the OP (JIA) the problem is very similar to when the netinfo database becomes corrupted. This can and DOES happen... however rarely and the jfs is probably not to blame. There is a nightly backup of the netinfo database written to /var/backups/local.nidump . It is done by /etc/daily.

In short... while a jfs certainly makes it so that a filesystem is far far less likely to become corrupted it does not make it impossible. A jfs can also do nothing about a buggy application from corrupting a file or files.