<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you tried using the uid= and/or idmap=user mount options?<br>
<br>
<a href="http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html" target="_blank">http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html</a><br>
<br>
idmap=user comes from sshfs (which doesn't appear to have any official<br>
documentation), and is supposed to map UIDs.<br>
</blockquote><div><br>That sounds promising. I think I'll skip that though, since now we've got GRASS running on the server and the server's a lot more comfortable for me anyway due to the long calculations ;)<br>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>Historically, there are two reasons:<br>
<br>
1. To prevent multiple GRASS sessions from using the same mapset<br>
directory. A lock file prevented a user from having more than one<br>
session, and the ownership check prevented anyone other than the<br>
directory's owner from using a directory as the current mapset.<br>
<br>
2. Because otherwise people try to share mapsets by making them<br>
group-writable, then discover that they can't replace maps due to<br>
permission issues.<br>
<br>
Specifically, if you allow someone else to write to your mapset<br>
directory, and that user has a umask of 022 (or more), any directories<br>
which they create (e.g. cell_misc/<mapname> directories) will be mode<br>
755 (drwxr-xr-x) or less, meaning that you can't remove any files from<br>
that directory, and thus won't be able to delete that directory. This<br>
will prevent you from removing or overwriting the map using GRASS<br>
commands.<br>
<br>
Point #1 is no longer relevant, but point #2 is, at least on<br>
multi-user systems.<br>
<br>
On Windows, the checks are bypassed because Windows' stat() function<br>
doesn't report the owner and Windows doesn't have getuid().<br>
<br>
None of this would be a problem except for the fact that it's now<br>
common to use non-Unix filesystems on Unix (where "non-Unix<br>
filesystem" includes any filesystem where "touch file ; ls -l file"<br>
reports an owner that doesn't match the output of "whoami").<br></blockquote><div><br>Thanks for the explanation! That's good to know :)<br><br>Daniel<br></div></div></div>