You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to run IDLE without write-access to home directory #52478
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/terryjreedy'closed_at=Nonecreated_at=<Date2010-03-25.15:39:27.987>labels= ['expert-IDLE', 'type-feature', '3.7']
title='Unable to run IDLE without write-access to home directory'updated_at=<Date2017-12-30.20:56:29.287>user='https://bugs.python.org/cane'
When trying to run Python 2.6.5 & 3.1 IDLE GUI on Windows 7, I receive the following error that the "IDLE's subprocess didnt make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection."
I've researched this error and tried following the steps to troubleshoot this error without any success. I do not have any firewall software installed or have the Microsoft firewall enabled. When following bpo-8099 and tring to set the TCL and TK library to the idle.py I get the error that I need to check the path and permissions. (see attached screenshot)
These workstations are setup in active directory enviroment where each username that logs into the workstation is a local administrator and the referenced "M:\" drive is a home directory that is mapped for them.
When the local administrator account logs into the workstation the user can execute the IDLE GUI without any issues.
I found reference in one article that the os.py creates a directory called ".idlerc".
I'm wondering if there is a way to hardcode a reference path that doesnt point to my "M:\" drive for this directory or is there something else that I can try to fix this issue?
I just reproduced this by removing write access from my user for my home directory.
It seems odd that you wouldn't have write access to your home directory in the first place, but that's tangent to the issue. I'll see if there are other acceptable locations to attempt to place the config directory.
changed the title [-]Subprocess Startup Error - unable to create user config directory[/-][+]Unable to run IDLE without write-access to config directory[/+]on Mar 25, 2010
Please don't close it. Users in this situation can't use IDLE. We should at least try alternative locations to create this directory or perhaps prompt them for a directory they'd like to use.
bpo-17864 is a duplicate of this. Also, note the error reported here is a result of IDLE not having write access in the user's home directory and thus cannot create the .idlerc directory. IDLE seems to handle more gracefully the case of .idlerc existing but not writable.
bpo-27534 is about reducing the imports into the user runcode process. Without rechecking the reason for each import, I think it possible that this might result in config not being indirectly imported.
mlouielu commented on Jul 10, 2017
mlouielumannequin
Mannequin
More actions
How about only taking warning when not able to create dir at GetUserCfgDir(), then take the permission handler in other place?
e.g. when user trying to save the config in bad dir, pop-out a dialog to tell it is permission problem or dir not eixsts...etc.
Ned diagnosed bpo-32447 as likely due to the space in the user name. What matters for this issue is that a) someone can do that and b) IDLE likely could continue running anyway. There might then be problems with saving files from the editor, so any warning message should include that possibility.
Ned diagnosed bpo-32447 as likely due to the space in the user name.
Actually, that's not what the primary problem was. It was a severely misconfigured home directory, both permissions and groups. I'm not sure how that situation was created (possibly through inadvertent sysadmin commands from the shell) but it's not something that IDLE needs to worry about; such a configuration breaks lots of other system programs. In other words, the OP's system was broken.
IDLE now prints a user friendly warning when trying to start it with a read-only home directory; see #52478 (comment).
Suggesting to close this, as the OP problem seems resolved. If other improvements are needed, I suggest to create targeted, narrow issues for each of these.
Activity
cane commentedon Mar 25, 2010
When trying to run Python 2.6.5 & 3.1 IDLE GUI on Windows 7, I receive the following error that the "IDLE's subprocess didnt make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection."
I've researched this error and tried following the steps to troubleshoot this error without any success. I do not have any firewall software installed or have the Microsoft firewall enabled. When following bpo-8099 and tring to set the TCL and TK library to the idle.py I get the error that I need to check the path and permissions. (see attached screenshot)
These workstations are setup in active directory enviroment where each username that logs into the workstation is a local administrator and the referenced "M:\" drive is a home directory that is mapped for them.
When the local administrator account logs into the workstation the user can execute the IDLE GUI without any issues.
I found reference in one article that the os.py creates a directory called ".idlerc".
I'm wondering if there is a way to hardcode a reference path that doesnt point to my "M:\" drive for this directory or is there something else that I can try to fix this issue?
Thanks,
Bryan
briancurtin commentedon Mar 25, 2010
I just reproduced this by removing write access from my user for my home directory.
It seems odd that you wouldn't have write access to your home directory in the first place, but that's tangent to the issue. I'll see if there are other acceptable locations to attempt to place the config directory.
[-]Subprocess Startup Error - unable to create user config directory[/-][+]Unable to run IDLE without write-access to config directory[/+]asvetlov commentedon Mar 25, 2012
Let's close the issue next week as report doesn't make sense if issuer has no write access to own home dir.
briancurtin commentedon Mar 25, 2012
Please don't close it. Users in this situation can't use IDLE. We should at least try alternative locations to create this directory or perhaps prompt them for a directory they'd like to use.
asvetlov commentedon Mar 25, 2012
Good point. Thank you.
ned-deily commentedon Apr 29, 2013
bpo-17864 is a duplicate of this. Also, note the error reported here is a result of IDLE not having write access in the user's home directory and thus cannot create the .idlerc directory. IDLE seems to handle more gracefully the case of .idlerc existing but not writable.
25 remaining items
terryjreedy commentedon Jul 8, 2017
New changeset 223c7e7 by terryjreedy in branch 'master':
bpo-8231: Call idlelib.IdleConf.GetUserCfgDir only once. (bpo-2629)
223c7e7
terryjreedy commentedon Jul 8, 2017
New changeset 552f266 by terryjreedy in branch '3.6':
[3.6] bpo-8231: Call idlelib.IdleConf.GetUserCfgDir only once. (GH-2629) (bpo-2631)
552f266
terryjreedy commentedon Jul 9, 2017
bpo-27534 is about reducing the imports into the user runcode process. Without rechecking the reason for each import, I think it possible that this might result in config not being indirectly imported.
mlouielu commentedon Jul 10, 2017
How about only taking warning when not able to create dir at GetUserCfgDir(), then take the permission handler in other place?
e.g. when user trying to save the config in bad dir, pop-out a dialog to tell it is permission problem or dir not eixsts...etc.
terryjreedy commentedon Sep 10, 2017
I closed bpo-30918 as a duplicate of this. It has full 'set' and expanduser info.
terryjreedy commentedon Dec 30, 2017
Another duplicate: bpo-32411, MacOS 10.3.1, user apparently cannot write to home dir. Starting IDLE in terminal results in
Warning: unable to create user config directory
/Users/Steve Margetts/.idlerc
Check path and permissions.
Exiting!
terryjreedy commentedon Dec 30, 2017
Ned diagnosed bpo-32447 as likely due to the space in the user name. What matters for this issue is that a) someone can do that and b) IDLE likely could continue running anyway. There might then be problems with saving files from the editor, so any warning message should include that possibility.
ned-deily commentedon Dec 30, 2017
Actually, that's not what the primary problem was. It was a severely misconfigured home directory, both permissions and groups. I'm not sure how that situation was created (possibly through inadvertent sysadmin commands from the shell) but it's not something that IDLE needs to worry about; such a configuration breaks lots of other system programs. In other words, the OP's system was broken.
erlend-aasland commentedon Jul 30, 2022
IDLE now prints a user friendly warning when trying to start it with a read-only home directory; see #52478 (comment).
Suggesting to close this, as the OP problem seems resolved. If other improvements are needed, I suggest to create targeted, narrow issues for each of these.
terryjreedy commentedon Jul 30, 2022
Given Ned's comment and that improvements were made both here and on two other issues, agreed.