#868 closed defect (fixed)
QGIS: Permissions on GRASS LOCATIONS
Reported by: | micha | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | OSGeoLive15.0 |
Component: | OSGeoLive | Keywords: | QGIS, GRASS, data permissions, 7.0 |
Cc: | osgeolive@… |
Description
Two GRASS datasets are included: spearfish60 and nc_spm_08. In each the PERMANENT mapset and landsat mapset are not writeable by 'user'. WHile this is OK in GRASS itself (PERMANENT mapset is not necessarily writeable by everyone), It is causing a crash of QGIS with the error:
Cannot get projection
Cannot run module
Command:...qgis.g.info
info= ... permission denied
The three offending directories are each symlinks to /usr/local/share/grass/.... These directories have permissions i.e.:
drwxr-xr-x 4 root users 4096 2012-02-23 00:49 spearfish60
A workaround might be to do in install_grass.sh:
chown -R $USER_NAME.$USER_NAME "/usr/local/share/grass/nc_spm_08" chown -R $USER_NAME.$USER_NAME "/usr/local/share/grass/spearfish60"
I suppose the problem is in the QGIS GRASS plugin. The above is not ideal but it avoids the error and crash when loading layers from the PERMANENT mapset.
Attachments (4)
Change history (41)
follow-up: 2 comment:1 by , 12 years ago
comment:2 by , 12 years ago
Replying to epifanio:
+1 to apply this change.
creating new mapset/location in the grass data directory is common practice for me, when testing/using/demostrating grass.
Thanks.
Creating a new LOCATION/MAPSET in the QGIS GRASS plugin seems to work fine. The problem appears only when trying to load layers from the existing PERMANENT mapsets in nc_spm_08 or spearfish60 LOCATIONS.
follow-up: 4 comment:3 by , 12 years ago
Hi,
this is a known bug in qgis, it does not support multi-user/collaborative GRASS locations. still unfixed :-(
this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.
unfortunately, making the user account the owner of the files* is not a healthy workaround, it's a no go for the ISO. qgis needs to be fixed.
[*] or be owner of anything in /usr/local/ for that matter
I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?
cheers, Hamish
by , 12 years ago
Attachment: | QGIS_GRASS_error.png added |
---|
by , 12 years ago
Attachment: | QGIS_GRASS_error2.png added |
---|
follow-up: 5 comment:4 by , 12 years ago
Replying to hamish:
Hi,
this is a known bug in qgis, it does not support multi-user/collaborative GRASS locations. still unfixed :-(
this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.
Is this use case relevant to the LiveDVD?
unfortunately, making the user account the owner of the files* is not a healthy workaround, it's a no go for the ISO. qgis needs to be fixed.
[*] or be owner of anything in /usr/local/ for that matter
I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?
Attached are screen shots of the error. Looks like it's failing on setting the region.
How about putting the North Carolina and Spearfish datasets right under ~/user/grassdata instead of a symlink to /usr/local/share ??
cheers, Hamish
follow-up: 11 comment:5 by , 12 years ago
Replying to hamish:
this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.
Replying to micha:
Is this use case relevant to the LiveDVD?
yes, it's specifically intended to be used for quickly seeding a computer lab for workshops and tutorials.
I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?
Attached are screen shots of the error. Looks like it's failing on setting the region.
I played around with it a bit more. As far as I can tell to get it to work the user must be the owner of the PERMANENT mapset directory, but not any files within it. Full write permission is not enough, and AFAICT no files are actually written within the dir during the process (the stat
mtime on the directory does not change, which it would if you created then removed a temporary .gislock file or so within it). Also I noticed with the user owning the PERMANENT/ directory that you could then open read-only maps from other mapsets (ie nc/landsat/) just fine. perhaps a glibc call to access() is checking for permissions wrongly? (the user must actually own the Mapset directory they open, not just have write permissions there)
QGIS should not be changing the region except if the user explicitly runs the g.region module; it can use the GRASS_REGION environment variable to locally override it without touching the disk. But since no file is written to PERMANENT I don't think that's the case (and anyway user1 is the open mapset so that should be the one being modified)
How about putting the North Carolina and Spearfish datasets right under ~/user/grassdata instead of a symlink to /usr/local/share ??
It is undesirable to make the disc dependent on the user account, & so far we've pretty much managed to make just the desktop setup and some superficial program configs rely on the dot files in that account. (mysql/postgres DB permissions might be an exception to that)
Also, wrt my earlier "no go" comment, I've never been 100% clear on this but AFAIU for the ISO version it loads /home/user into RAM(?) so there is a reason to keep ~user/ just containing very small files. One thing I'm not clear on is if that applies to every file user
explicitly owns or just the home dir. The general work around we use is to make the files group writable and owned by the "users" group. The ISO-version remakes the user
account at final-build time which wipes the slate clean on a number of things.
I did try copying the grass Locations into ~user/, but the DVD ISO (run in a VM) became highly unresponsive after I tried to open some maps. I can't say for sure that this was direct causation, but that's the only time I've seen that behaviour.
for now a "just make the darn thing work" end user work-around is a slight modification of your earlier suggestion to just change ownership of the PERM dir itself:
sudo chown user /usr/local/share/grass/nc_spm_08/PERMANENT sudo chown user /usr/local/share/grass/spearfish60/PERMANENT
but as a general solution it is not satisfactory so I wouldn't like to include that in the install script. Understanding/fixing the bug in qgis may lead to a better work-around in the current version.
regards, Hamish
comment:6 by , 12 years ago
another work-around: open a terminal and do "sudo qgis", but then you'll have to make a mapset somewhere owned by root.
comment:8 by , 12 years ago
Summary: | Permissions on GRASS LOCATIONS → QGIS: Permissions on GRASS LOCATIONS |
---|
comment:9 by , 12 years ago
Milestone: | → OSGeoLive6.0Final |
---|
comment:10 by , 12 years ago
debugging session & problem identified in the C++ code here:
(the where and how it is broken, but not the why and exactly how to fix it)
Hamish
comment:11 by , 12 years ago
crappy work-around noted in comment:5 added in svn for testing.
start with comment:10 for a better way..
Hamish
comment:12 by , 12 years ago
Priority: | major → normal |
---|
Tested yesterday and this workaround works. Lets wait for the next build to confirm.
comment:13 by , 12 years ago
Keywords: | 6.5 added |
---|
the rc.local ownership change work-around is working in 6.0beta9, deferring ticket to 6.5..
comment:14 by , 12 years ago
Milestone: | OSGeoLive6.0Final → OSGeoLive6.5 |
---|
comment:16 by , 12 years ago
Milestone: | OSGeoLive6.5 → OSGeoLive7.0 |
---|
working but don't like the work around. punt down the line.
comment:17 by , 12 years ago
Keywords: | 7.0 added; 6.5 removed |
---|
comment:18 by , 11 years ago
This is still open after so much time. The fix has been pushed to QGIS 2, which I am not sure we will get in for 7.0.
comment:19 by , 11 years ago
Keywords: | QGIS GRASS data permissions, 7.0 → QGIS, GRASS, data permissions, 7.0 |
---|---|
Milestone: | OSGeoLive7.0 → OSGeoLive7.5 |
qgis 2.0 doesn't seem to be arriving for 7.0, so postponing to 7.5..
comment:20 by , 10 years ago
Milestone: | OSGeoLive7.9 → OSGeoLive8.0 |
---|
Not fixed in QGIS 2.0, Paolo's moved http://hub.qgis.org/issues/2947 to the future, so we have to as well.
Hamish
comment:22 by , 10 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
This ticket is invalid for 8.5 since we moved to GRASS7.
comment:23 by , 6 years ago
Milestone: | OSGeoLive8.5 → OSGeoLive12.0 |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
Given recent comments on other tickets, perhaps this should be re-opened.
comment:24 by , 6 years ago
Cc: | added |
---|
comment:25 by , 5 years ago
Milestone: | OSGeoLive12.0 → OSGeoLive13.0 |
---|
Ticket retargeted after milestone closed
by , 5 years ago
Attachment: | QGIS_scrot_OSGeo_13.png added |
---|
Errors using Browser with GRASS layers, and GRASS modules in Processing
comment:27 by , 5 years ago
Sorry, but the problem seems to persist. See attached screen shot.
If I create a new GRASS location (not dependent on the nc_basic_spm built in location) then there's no problem. The errors arise only when attempting to use nc_basic_spm (or any mapset in that location) since its PERMANENT mapset is a simlink to /usr/local/share where the user does not have permissions.
comment:28 by , 5 years ago
Milestone: | OSGeoLive13.0 → OSGeoLive14.0 |
---|
Ticket retargeted after milestone closed
comment:29 by , 3 years ago
Micha, could you please give it another try in the current OSGeolive 14 rc2?
You find the download of Version 14 rc2 at:
comment:30 by , 3 years ago
comment:32 by , 3 years ago
I have never heard anyone encountering this issue except in the context of OSGeo Live, with the (unusual?) setup of user's data stored read-only under /user/share/...
.
We know that GRASS is designed to handle this situation. QGIS, apparently not. Furthermore, most of the use of GRASS modules from within QGIS is through the Processing toolbox, which always uses tmp locations. So again, the problem never occurs.
I think we have two choices:
- Just drop the issue due to lack of interest, and rewrite the QGIS quickstart to remove any mention of the GRASS location under /usr/share/data.
- Move
grassdata
to user's home dir in place of the symlink, at the cost of losing group-shared data in a classroom setup.
comment:33 by , 3 years ago
Milestone: | OSGeoLive14.0 → OSGeoLive15.0 |
---|
Ticket retargeted after milestone closed
comment:34 by , 2 years ago
Hi Micha,
I have made some updates in the grass folder permissions, I hope this one is fixed now.
Can you please test and confirm?
comment:35 by , 2 years ago
Seems to be good now. Making the symlink in user's grassdata to the PERMANENT location in /usr/local/share/grass
was a good idea. Now I can create GRASS maps in both GRASS and QGIS.
But... I don't see the GRASS special folders in the QGIS browser. I can't find any way to load GRASS maps into QGIS. (On my local machine there are those special GRASS icons in the browser for all folders recognized as grass data.)
Should I open a new issue for this??
Thanks for all your ongoing effort!
comment:36 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:37 by , 2 years ago
Thank you for testing!
Please open a new ticket for the new issue you found.
+1 to apply this change.
creating new mapset/location in the grass data directory is common practice for me, when testing/using/demostrating grass.
Thanks.