mount and cifs

Is this command allowed under QNX 6.1?

char* server_data = “user user”;
int datalen = strlen(server_data);
int mStat;
mStat = mount("//WINXP_SERVER:192.168.2.1:/shared_dir",
“/mnt/shared_dir”,
_MOUNT_ENUMERATE ,
“cifs”,
server_data,
datalen);
I ask because mount returns with a “function not implemented” error. Is
there another way to mount a shared cifs filesystem programmatically? I’ve
used fs-cifs in a shell script, but I was hoping for a different approach.
This was an attempt to copy the
fs-cifs //WINXP_SERVER:192.168.2.1:/shared_dir /mnt/shared_dir user user
syntax.

Thanks,
David Kuechenmeister

Is fs-cifs running? It should be, before you can use mount command…

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:b6i76d$plt$1@inn.qnx.com

Is this command allowed under QNX 6.1?

char* server_data = “user user”;
int datalen = strlen(server_data);
int mStat;
mStat = mount("//WINXP_SERVER:192.168.2.1:/shared_dir",
“/mnt/shared_dir”,
_MOUNT_ENUMERATE ,
“cifs”,
server_data,
datalen);
I ask because mount returns with a “function not implemented” error. Is
there another way to mount a shared cifs filesystem programmatically? I’ve
used fs-cifs in a shell script, but I was hoping for a different approach.
This was an attempt to copy the
fs-cifs //WINXP_SERVER:192.168.2.1:/shared_dir /mnt/shared_dir user user
syntax.

Thanks,
David Kuechenmeister

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:

Is this command allowed under QNX 6.1?

mount is kind of finicky.

Have you run fs-cifs already?

I note from the mount (utility doc) example it says:

Mount a CIFS filesystem (fs-cifs must be running first):
mount -t cifs -o abc,efg //node123:1.1.1.1:/C /ctest

char* server_data = “user user”;

From the mount util example, this may have to be “user,user” if used
in a mount command – not sure. (Or, mount may turn that into
“user user” – I don’t know.)

int datalen = strlen(server_data);
int mStat;
mStat = mount("//WINXP_SERVER:192.168.2.1:/shared_dir",

The problem may be here – that is a “null-terminated string that
describing a special device (e.g. /dev/hd0t77) that you want to
mount” – except that what you put in there isn’t a “special
device” in the QNX name space. Or, it may just be that you
aren’t running fs-cifs yet.

“/mnt/shared_dir”,
_MOUNT_ENUMERATE ,
“cifs”,
server_data,
datalen);
I ask because mount returns with a “function not implemented” error. Is
there another way to mount a shared cifs filesystem programmatically?

(warning I don’t know the details of how mount processing works, I’m
hypothesizing here based on general knowledge of how QNX generally does
things.)

If fs-cifs isn’t running, then type “cifs” probably hasn’t been registered,
so you are making a request for which support does not exist, and you get
back EOPNOTSUP (function not implemented).

I’ve
used fs-cifs in a shell script, but I was hoping for a different approach.
This was an attempt to copy the
fs-cifs //WINXP_SERVER:192.168.2.1:/shared_dir /mnt/shared_dir user user
syntax.

How about:

spawnl(P_NOWAIT, “fs-cifs”, “fs-cifs”,
“//WINXP_SERVER:192.168.2.1:/shared_dir”, “/mnt/shared_dir”,
“user”, “user”, NULL );

The docs for fs-cifs do say:

If you want to mount filesystems separately, start fs-cifs without
arguments, as a daemon, then create your mountpoints using mount
specifying cifs as the type. See below for an example.

Of course, this only gives command-line examples, rather than using the
mount() call.

But, I’d bet your main problem is that you didn’t run fs-cifs first.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

When I try to start my 6.1 version of fs-cifs as a daemon, I get an error:
run “use fs-cifs” or “fs-cifs -h” for help.
I don’t think I can start it as a daemon, although the mount(library doc)
help does seem to imply that it should be available before the command is
used. The mount(utility doc) help doesn’t mention fs-cifs directly as does
the 6.2 help.
The 6.2 docs do concur with the help below.

Is this another reason to upgrade? Or can I upgrade fs-cifs to be a daemon?

Thanks,
David

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:b6idt5$mfh$1@nntp.qnx.com

David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Is this command allowed under QNX 6.1?

mount is kind of finicky.

Have you run fs-cifs already?

I note from the mount (utility doc) example it says:

Mount a CIFS filesystem (fs-cifs must be running first):
mount -t cifs -o abc,efg //node123:1.1.1.1:/C /ctest

char* server_data = “user user”;

From the mount util example, this may have to be “user,user” if used
in a mount command – not sure. (Or, mount may turn that into
“user user” – I don’t know.)

int datalen = strlen(server_data);
int mStat;
mStat = mount("//WINXP_SERVER:192.168.2.1:/shared_dir",

The problem may be here – that is a “null-terminated string that
describing a special device (e.g. /dev/hd0t77) that you want to
mount” – except that what you put in there isn’t a “special
device” in the QNX name space. Or, it may just be that you
aren’t running fs-cifs yet.

“/mnt/shared_dir”,
_MOUNT_ENUMERATE ,
“cifs”,
server_data,
datalen);
I ask because mount returns with a “function not implemented” error. Is
there another way to mount a shared cifs filesystem programmatically?

(warning I don’t know the details of how mount processing works, I’m
hypothesizing here based on general knowledge of how QNX generally does
things.)

If fs-cifs isn’t running, then type “cifs” probably hasn’t been
registered,
so you are making a request for which support does not exist, and you get
back EOPNOTSUP (function not implemented).

I’ve
used fs-cifs in a shell script, but I was hoping for a different
approach.
This was an attempt to copy the
fs-cifs //WINXP_SERVER:192.168.2.1:/shared_dir /mnt/shared_dir user user
syntax.

How about:

spawnl(P_NOWAIT, “fs-cifs”, “fs-cifs”,
“//WINXP_SERVER:192.168.2.1:/shared_dir”, “/mnt/shared_dir”,
“user”, “user”, NULL );

The docs for fs-cifs do say:

If you want to mount filesystems separately, start fs-cifs without
arguments, as a daemon, then create your mountpoints using mount
specifying cifs as the type. See below for an example.

Of course, this only gives command-line examples, rather than using the
mount() call.

But, I’d bet your main problem is that you didn’t run fs-cifs first.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Xiaodan Tang wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote in message
news:b6kp35$ncj$> 2@inn.qnx.com> …

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

NFS and CIFS are ‘stateless’ protocols, so clients don’t need to remount

if

server has restarted. I haven’t tried that with CIFS, but NFS definitely
survives.

I can understand how reconnects are easily established. But can’t a
file be in an OPEN state? Or does each successive IO to an
Open/Read|Write/Close?


Yes. An open file can (should) survive remote reboot.

With CIFS ?

I seem to recall CIFS as a stateful protocol.

Rennie

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:

When I try to start my 6.1 version of fs-cifs as a daemon, I get an error:
run “use fs-cifs” or “fs-cifs -h” for help.

Under 6.2.1 I was able to just do “fs-cifs &” and it was then running
in the background.

I don’t think I can start it as a daemon, although the mount(library doc)
help does seem to imply that it should be available before the command is
used. The mount(utility doc) help doesn’t mention fs-cifs directly as does
the 6.2 help.
The 6.2 docs do concur with the help below.

Is this another reason to upgrade? Or can I upgrade fs-cifs to be a daemon?

This might be a reason to upgrade – it sounds like the 6.1 fs-cifs
didn’t support running without command-line arguments to specifically
mount something.

This might encourage an upgrade – or you might be ok with the
spawnl() that I suggested, rather than running fs-cifs, then
mounting.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

One last question about fs-cifs.
I had wanted to use the mount command because of the option to
_MOUNT_ENUMERATE the device. This causes the client to autodetect on the
mounted device and remount when needed. I couldn’t see a way to do that
directly with the fs-cifs command, nor with fs-nfs2, for that matter.

Will fs-cifs autodetect and remount directory structures if the exporting
computer is shutdown and restarted?

Thanks,
David Kuechenmeister


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:b6k9tk$sir$2@nntp.qnx.com

David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
When I try to start my 6.1 version of fs-cifs as a daemon, I get an
error:
run “use fs-cifs” or “fs-cifs -h” for help.

Under 6.2.1 I was able to just do “fs-cifs &” and it was then running
in the background.

I don’t think I can start it as a daemon, although the mount(library
doc)
help does seem to imply that it should be available before the command
is
used. The mount(utility doc) help doesn’t mention fs-cifs directly as
does
the 6.2 help.
The 6.2 docs do concur with the help below.

Is this another reason to upgrade? Or can I upgrade fs-cifs to be a
daemon?

This might be a reason to upgrade – it sounds like the 6.1 fs-cifs
didn’t support running without command-line arguments to specifically
mount something.

This might encourage an upgrade – or you might be ok with the
spawnl() that I suggested, rather than running fs-cifs, then
mounting.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Igor Kovalenko <kovalenko@attbi.com> wrote:

NFS and CIFS are ‘stateless’ protocols, so clients don’t need to remount if
server has restarted. I haven’t tried that with CIFS, but NFS definitely
survives.

I can understand how reconnects are easily established. But can’t a
file be in an OPEN state? Or does each successive IO to an
Open/Read|Write/Close?

NFS and CIFS are ‘stateless’ protocols, so clients don’t need to remount if
server has restarted. I haven’t tried that with CIFS, but NFS definitely
survives.

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:b6kj26$i1j$1@inn.qnx.com

One last question about fs-cifs.
I had wanted to use the mount command because of the option to
_MOUNT_ENUMERATE the device. This causes the client to autodetect on the
mounted device and remount when needed. I couldn’t see a way to do that
directly with the fs-cifs command, nor with fs-nfs2, for that matter.

Will fs-cifs autodetect and remount directory structures if the exporting
computer is shutdown and restarted?

Thanks,
David Kuechenmeister


“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:b6k9tk$sir$> 2@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
When I try to start my 6.1 version of fs-cifs as a daemon, I get an
error:
run “use fs-cifs” or “fs-cifs -h” for help.

Under 6.2.1 I was able to just do “fs-cifs &” and it was then running
in the background.

I don’t think I can start it as a daemon, although the mount(library
doc)
help does seem to imply that it should be available before the command
is
used. The mount(utility doc) help doesn’t mention fs-cifs directly as
does
the 6.2 help.
The 6.2 docs do concur with the help below.

Is this another reason to upgrade? Or can I upgrade fs-cifs to be a
daemon?

This might be a reason to upgrade – it sounds like the 6.1 fs-cifs
didn’t support running without command-line arguments to specifically
mount something.

This might encourage an upgrade – or you might be ok with the
spawnl() that I suggested, rather than running fs-cifs, then
mounting.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Bill Caroselli <qtps@earthlink.net> wrote in message
news:b6kp35$ncj$2@inn.qnx.com

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
NFS and CIFS are ‘stateless’ protocols, so clients don’t need to remount
if
server has restarted. I haven’t tried that with CIFS, but NFS definitely
survives.

I can understand how reconnects are easily established. But can’t a
file be in an OPEN state? Or does each successive IO to an
Open/Read|Write/Close?

Yes. An open file can (should) survive remote reboot.

-xtang

“Rennie Allen” <rallen@csical.com> wrote in message
news:3E8D9829.6010907@csical.com

Xiaodan Tang wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote in message
news:b6kp35$ncj$> 2@inn.qnx.com> …

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

NFS and CIFS are ‘stateless’ protocols, so clients don’t need to
remount

if

server has restarted. I haven’t tried that with CIFS, but NFS
definitely
survives.

I can understand how reconnects are easily established. But can’t a
file be in an OPEN state? Or does each successive IO to an
Open/Read|Write/Close?


Yes. An open file can (should) survive remote reboot.

With CIFS ?

I seem to recall CIFS as a stateful protocol.

Rennie

I don’t know if it’s SUPPOSED to work, but we restart Samba while files are

open with no problem.


Marty Doane
Siemens Dematic