clausbc Absent Member.
Absent Member.
1506 views

NSS - mounting volume on/from remote server

Hi,

I would like to mount a NSS volume, which is currently available through NDS and OES Client from server A, locally on server B. Can that be done?
Both are running OES2015SP1 - and both have NSS volumes already.

I was thinking something like "mount -t nssvol //sif/media/nss/SINGLEVOL1 /mnt/public/" - but gets:
mount: wrong fs type, bad option, bad superblock on //sif/media/nss/SINGLEVOL1,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount.<type> helper program)

Best regards Claus, DK
Labels (2)
0 Likes
7 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: NSS - mounting volume on/from remote server

On 07/27/2017 10:34 AM, clausbc wrote:
>
> I would like to mount a NSS volume, which is currently available through
> NDS and OES Client from server A, locally on server B. Can that be
> done?
> Both are running OES2015SP1 - and both have NSS volumes already.


It would probably be useful to have your use case explicitly called out so
we know what the limitations are. NSS is a filesystem, which means that
in order to be safe you almost certainly want to have the disk local, so
it can be locked for writes to avoid corruption from multiple writers.

> I was thinking something like "mount -t nssvol
> //sif/media/nss/SINGLEVOL1 /mnt/public/" - but gets:


This is NFS, not NSS, syntax. Can you mount something like NSS via NFS?
Probably, or at least I do not know of any reason why not, but you can
mount almost anything via NFS.

> Code:
> --------------------
> mount: wrong fs type, bad option, bad superblock on //sif/media/nss/SINGLEVOL1,
> missing codepage or helper program, or other error
> (for several filesystems (e.g. nfs, cifs) you might
> need a /sbin/mount.<type> helper program)
> --------------------


Yes, the system does not know which network protocol you want, so it tries
what it knows works over a network (NFS or SMB) and those, of course, are
not working because you have not setup the server yet to do that.

Again, knowing your business goals would help find a proper technical
solution.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: NSS - mounting volume on/from remote server

Do i understand correctly that SINGLEVOL1 is attached to and mounted at serverA and you just want to access files residing on it from serverB?
If so you can mount it e.g. via CIFS (provided it's enabled for the volumes) via something like
mount -t cifs //server/cifssharename /mountpoint -o username=xxx
"username" needs to have a UP set.
you can also use the nwclient component like this
nwlogin -u username -p password -t TREENAME -c o=context -s xx.xx.xx.xx (with xx.xx.xx.xx being the ip address of the target server)
followed by
nwmap -d Z -s serverA -V SINGLEVOL1
that would create a link to the volume underneath /root/Z

If you've removed the volume (better: the device holding the volume) from serverA and attached it to serverB just type
ncpcon mount SINGLEVOL1
clausbc Absent Member.
Absent Member.

Re: NSS - mounting volume on/from remote server

mathiasbraun;2462852 wrote:
Do i understand correctly that SINGLEVOL1 is attached to and mounted at serverA and you just want to access files residing on it from serverB?
If so you can mount it e.g. via CIFS (provided it's enabled for the volumes) via something like
mount -t cifs //server/cifssharename /mountpoint -o username=xxx
"username" needs to have a UP set.
you can also use the nwclient component like this
nwlogin -u username -p password -t TREENAME -c o=context -s xx.xx.xx.xx (with xx.xx.xx.xx being the ip address of the target server)
followed by
nwmap -d Z -s serverA -V SINGLEVOL1
that would create a link to the volume underneath /root/Z

If you've removed the volume (better: the device holding the volume) from serverA and attached it to serverB just type
ncpcon mount SINGLEVOL1


the nwlogin - nwmap works fine. Thank you so much

Best regards Claus, DK
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: NSS - mounting volume on/from remote server

...forgot to mention: i've seen an instance a few weeks ago where a GW dbcopy badly failed (i.e. left partly corrupted data on the target) via NCP (nwlogin / nwmap) and worked fine afterwards via CIFS. Didn't retry with NCP so the issue could be totally unrelated to the transport protocol and rather been caused by ghosts on the wire. Just a reminder that you might want to compare file numbers and sizes in such an offset.
0 Likes
clausbc Absent Member.
Absent Member.

Re: NSS - mounting volume on/from remote server

ok - thank you. That is my exact usecase: GW DBCopy, so I will do proper verification

Best regards Claus, DK
0 Likes
clausbc Absent Member.
Absent Member.

Re: NSS - mounting volume on/from remote server

mathiasbraun;2462852 wrote:
Do i understand correctly that SINGLEVOL1 is attached to and mounted at serverA and you just want to access files residing on it from serverB?
If you've removed the volume (better: the device holding the volume) from serverA and attached it to serverB just type
ncpcon mount SINGLEVOL1

BTW: I also tried creating a new (additional) volume in the host pool on serverA.
From serverB:
hugin:~ # ncpcon mount MAILBACKUP
... Executing "mount MAILBACKUP"

The following volume were not mounted.
MAILBACKUP: failure reason = 152
No volume were mounted.

... FAILED completion [elapsed time = 615 msecs 11 usecs]


Any obvious reasons?

Best regards Claus, DK
0 Likes
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: NSS - mounting volume on/from remote server

On 07/27/2017 01:16 PM, mathiasbraun wrote:
>
> that you might want to compare file numbers and sizes in such an offset.


As long as you are going through the effort of comparing everything, you
had might as well do it properly with checksums. Counts of files, their
sizes, and even their timestamps are incomplete since it is very possible,
particularly with corruption of some kind, for bytes to be changed without
impacting the size or timestamp of the file, but a checksum will always
find those differences and warn you about a difference.

Doing this recursively is really easy. On the source system go t a
particular directory and then generate checksums and write them to a file:


cd /path/to/files
md5sum $(find ./ -type f ) > /tmp/files.md5sum


On the target system, go to the same directory, copy the generated file
somewhere locally, and check the files:


cd /path/to/files
md5sum -c /tmp/files.md5sum


Anything without an 'OK' at the end of the line is something to be checked.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.