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)
  • 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.
  • 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
  • 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
  • ...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.
  • ok - thank you. That is my exact usecase: GW DBCopy, so I will do proper verification
  • 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?
  • 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.