does not display "lefttime" at login - Systems Maintenance(Archived)

If a user login to our server or use the command quota, he get the message "Over disk quota on /export/home2, remove 62255K within". There is no time restriction displayed after "within". repquota works fine.
What's wrong?
Best regards


ssh: /etc/issue display between login and password prompts

Hi All,
I currently have ssh installed on one a Solaris 10 (non-global) zone. I have configured the sshd_config to run on protocol 2 and unhashed the 'Banner /etc/issue' parameter.
When I attempt to log into this zone via ssh I get (in this order)...
1. A login prompt
2. The message I have put in /etc/issue
3. A password prompt.
Is there some further configuration I need to consider here?
Any help would be great.
Sorry, it's probably worth mentioning that what i would ultimately like to do is have the message in /etc/issue display itself prior to asking for a login, not after as it currently is.
Include this:
Banner /etc/issuein your sshd_config. That will display the contents of /etc/issue prior to login.

not able to change the password

I have created a new user account in solaris 8 2/02 ,
everything is fine , user is successfully able to login and do his tasks .
only the prob , comes when he want to change his password, i can change as root , but as a login user he is not able to change his passowrd .
here is the error message , any advise wiil be appreciated .
$ passwd user1
Enter existing login password:
SRM: attempting to create new database entry for user1.
Segmentation Fault 
Well, SRM is the Solaris Resource Manager:
I don't know anything about SRM, but maybe the problem is that it doesn't know about your new user? 
I am having the same issue. Did you have find a fix for this? Thanks in advance for your response. 
I had the same problem.
Other users worked fine. The user in question was not listed in the "liminfo -a" output, so I used limadm to set one of the attributes for that user, after that the user could change his password and his info was displayed by "liminfo -a".
Hope this helps. 
i have same problem , for which u got rid in your case,Actually i do not know much abt SRM , and we doesn`t want to run SRM on our box, it is there from old config...and it is giving the error .
if u can give me the full option with syntax to allow a user to register in the SRM Db and allow the user to change the passwd .
that will be agreat help.
I set the user attribute using "limadm", in my case I set the srgroup attribute, because all my users were in that group according to "liminfo -a". you will need to find an attribute that you won't mind setting, and a setting that you also won't mind.
my binary was at /usr/srm/sbin/limadm
use "-H" to get the proper usage.
If you successfully set any attribute for this user, the rest of the record should auto-populate,and the user will be able to change their password. Of course your milage may vary as the user should already auto-populate in SRM when he/she was added. And if that had worked like it was supposed to, none of us would be here now.
I think I used the following command.
/usr/srm/sbin/limadm set srgroup=srmother {loginname}
I really don't know how it works, and I also don't want to use it, but it got in my way.
Hope this helps, it really is all I know on the subject. 
The correct sintax is:
/usr/srm/sbin/limadm set {color:#ff0000}sgroup{color}=srmother {loginname}
Edited by: Emerson on Mar 3, 2008 4:59 AM

Only root can log into CDE, users cannot

I've searched the forums for an answer to this problem. I've seen many questions posted about this, but found none that were solved.
Recently, we had a power outage, which I believe caused the following problem. Only root is able to log into the CDE. When a user tries to log into the CDE, the screen turns black for a moment and then returns to the login prompt. This used to work. Users are, however, able to log into the machine using FTP or TELNET, so I know the user names and passwords are still valid.
I've tried deleting users and adding new users, but the same problem exists.
Does anyone know how to fix this problem?
Many thanks,
The default seesion for the graphical login is "User's Last desktop". This information might be corrupted due to the power outage/fsck.
On the graphical login panel, select Options->Session->CDE and you should be fine. 
nay, that didn't do the trick. The same problem occurs: users cannot log into CDE.
Thanks for the suggestion 
Check HOME/.dt/statlog file to see error loggin or try to copy .dt directory to Home directory's user and change the permissions.

.forward not working

.foward file is not working.
A user account called Sally has Peter ( a valid UID)in the .forward file.
file permissions are correct (only Sally can write, the rest read)
The problem is, if Sally gets an email, it is not forwarded
to Peter.
I even reboot the system (to restart sendmail) and it was still unsuccessful. I also used vacation and still have the same problem. Sally gets the mail without being forwarded to Peter.
My system is Solaris 7.
Anyone can help ?
well the most obvious candidate is permssions ! other than that have you tried sendmail -v <dest_email address> to see if you can get more clues ?

One problem.

One user received a invite event of the calendar,when the user opened the event, can't find the form to write back.
But another user can find the form to write back.
Thank you. 
Do both users that received the invite actually have schedule permission on the organizers calendar? Check the ACL's as this maybe an ACL issue.
Also what client is being used? Are both users using Communication Express or Calendar Express? 
All users in the same organizer.
All users are using Communication Express.
Thank you. 
When you say they can't find the form to write back, what do you actually see. Is it a 404 error, blank window? etc.. What exactly is seen by one user and not the other?
Have you enabled UWC logging by setting the following in
uwc.logging.enable= yes
Also have you checked the calendar servers http.log file which you can also set to debug level by setting the following in ics.conf:
These log files might show come clues as to what's going wrong.