From: Christian Fischer <Christian.Fischer@fischundfischer.com>
To: linux-msdos@vger.kernel.org
Subject: Re: are there any limitations to use drive c on nfs volumes?
Date: Sat, 25 Sep 2004 10:27:06 +0200 [thread overview]
Message-ID: <200409251027.26691.Christian.Fischer@fischundfischer.com> (raw)
In-Reply-To: <200409241513.55174.Christian.Fischer@fischundfischer.com>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Saturday 25 September 2004 05:36, Kevin Noseworthy - Specialty Software
wrote:
> I think Claudia is on the right track. I too use nfs (only for certain
> aspects of the application I run)
> without problem. If you have read rights then your app will see the
> database, however, if writing is required, and it most likely is, then
> the app will be prevented from establishing any kind of file or record
> lock. (Writing in this case may simply be required to gain access or
> notify the multi-user database that a user is connected, even if only a
> single user is accessing it with a single user license.) I don't use an
> XBase such as foxpro but I am certain it is "capable" of multi-user access.
> It is required that the rights of the user/group on the client match
> those on the host by number (name is not important) e.g. if group on
> client is 500 then group on host must be 500.
> I would also note that since you are using foxpro you will not be able
> to establish file/record locking with this configuration. This applies
> not only to multi-user access but to single user access if foxpro is
> capable of windowing (Not to be confused with Microsoft Reboot, aka
> Windows)
Okay, good to hear that there are most probably no limitations on nfs volumes.
Uids and gids are defininite the same on client and server. Also the users are
in the right groups, on both machines definite the same part of /etc/groups.
But there is an other problem, probably it affects dosemu in this case. There
are directories (770 user1:group1) with files in it (660 user1:group1). User1
and members of group1 can browse into these directories but the can't see or
read the files.
# cd directory
directory # ls -al
ls: reading directory .: Permission denied
total 0
Somethig goes completely wrong, i don't know how to trace it on the fly.
Note: directories and files have identical user and group and right
permissions. And not all directories of the same type of user:group (and the
same permissions) are affected, only some one. I can't see any differences.
Thanks for your comments, i think this is an OT thing now.
Christian
--
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2004-09-25 8:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 9:57 are there any limitations to use drive c on nfs volumes? Christian Fischer
2004-09-24 11:20 ` Christian Fischer
2004-09-24 12:14 ` Claudia Neumann
2004-09-24 13:13 ` Christian Fischer
2004-09-25 8:27 ` Christian Fischer [this message]
2004-09-26 7:27 ` Claudia Neumann
2004-10-03 3:42 ` Ryan Underwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409251027.26691.Christian.Fischer@fischundfischer.com \
--to=christian.fischer@fischundfischer.com \
--cc=linux-msdos@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox