Bug 60047 - xterm command not open a xterm
Summary: xterm command not open a xterm
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-02-19 12:51 UTC by Uwe Schmelzer
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-19 14:22:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Uwe Schmelzer 2002-02-19 12:51:52 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4)
Gecko/20011019 Netscape6/6.2

Description of problem:
Problem: Open a xterm of a other machine.
The other Maschine is a CAD-station HP-UX solid1 B.10.20 A 9000/780.
Login on Linux as a normal user.
First command: /usr/bin/X11/xterm -display solid1:0&
               This command open a xterm on the solid1.
Second command: /usr/bin/X11/xterm -display solid1:0&
                This command has following error.
                xterm: Error 1, errno 13: Keine Berechtigung
When a close the first xterm, then I can open a new xterm, but
no a second xterm: 


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. /usr/bin/X11/xterm -display solid1:0&
2. /usr/bin/X11/xterm -display solid1:0&
3.
	

Additional info:
Comment 1 Bernhard Rosenkraenzer 2002-02-19 14:22:09 UTC 
This has nothing to do with X11R6-contrib (xterm is in XFree86, reassigning there). 
It looks much more like a setup problem though.
Comment 2 Mike A. Harris 2002-02-19 17:29:56 UTC 
xterm works both locally and remotely just fine for me.  This is
a local misconfiguration issue of some sort.
Note You need to log in before you can comment on or make changes to this bug.