Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

"This directory can exist on the root file system or system disk"

Created: 04 Jun 2013 • Updated: 07 Jun 2013 | 13 comments
This issue has been solved. See solution.

Hi,
I was troubleshooting -> Disk Volume Pool Down (2074) for one of my Windows clients on the master server running Solaris 10, NBU 7.1.0.3 and I saw a solution on here that said to check the box for The option "This directory can exist on the root file system or system disk" on the Storage Unit Disk properties.  So I did and now I can't see my media server anymore.  How do I undo this check mark.  Thanks!

http://www.symantec.com/business/support/index?pag...

Operating Systems:

Comments 13 CommentsJump to latest comment

Marianne's picture

Is this Storage Unit on the master or media server?

Maybe 'disk volume is down' because there is a problem on the media server? And not related to a tick box?

Have you tried to logon to the media server and see if NBU is up and running? 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Nicolai's picture

Go back in the storage unit configuration and un-check the option.

But that said I go with Marianne - This setting is more like a security check than a setting that has impact on operation.

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

jim dalton's picture

All the tickbox is saying is: this dataspace can exist in the root volume.

It does this because its unusual...in the unix world: if you:-

mkdir /datastore1

and add /datastore1 for storage in netbackup then what you are doing is allowing backups to write into your root filesystem, which is bad if you fill it up. However it can have its uses, for testing or for quotad directories for example or if you just need it for a quick disk-based backup, hence why theres a tickbox: you know it's in root and so does netbackup and netbackup is just making sure you know it is.

Compare it with:

mkdir /datastore1

newfs -m 1 /dev/.../...  ; mount /dev/.../... /datastore1

Here you have created a new filesystem that is mounted at /datastore1 but its separate from /: its safe.

cd /datastore1 ; df . will reveal : /datastore1

whereas in the first example it will reveal simply / .ie root.

To sum up, it doesnt sound like its the cause of your problems, but (bugs notwithstanding) it might indicate the storage space hasnt mounted correctly hence it really is in root, and you might not want to do this. So the storage may indeed be corrupt, or you misconfigged the system and hence after a reboot it didnt mount. In Unix, it failing to mount wont stop you from cd /datastore1: its a mountpoint, it exists.

Im sure the same philosophy applies to windows and its C:\ drive.

Jim

JohnnyBgood's picture

Thank you all for your advise.  Marianne, the storage unit is on the media server but by checking that box I think it resides on the root volume of the master server now.  I would uncheck it Nicolai but the media server is gone under storage units whereas before I could right click it, select change and you know ☑ "This directory can exist on the root file system or system disk" Lastly, Jim I haven't created a new filesystem yet but I will give it shot as well check out my media server Marianne which is running Redhat Linux to see if NBU is running properly.  I'll be in touch, thanks again for your input...

Marianne's picture

It is easy enough to check - run 'df -h' on the media server. Is the STU path a separate mountpoint? It should ideally be. This means there is no reason for the checkbox to be selected and should not be selected.
While on the media server, check that NBU is up and running with 'bpps -x'.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

JohnnyBgood's picture

On Media Server:

>df -h

/dev/sda5 -------------- /

/dev/sda2---------------/var

/dev/sda1---------------/boot

tmpfs---------------------/dev/shm

dd01_bk:/backup-----/dd01/backup

dd01_bk:/ddvar-------/dd01/ddvar

>.bpps -x

NB Processes

/usr/openv/netbackup/bin/vnetd -standalone

/usr/openv/netbackup/bin/bpcd -standalone

/usr/openv/db//bin/NB_dbsrv @/usr/openv/var/global/server.conf @/usr/openv/var/global/databases.conf -hn 7

/usr/openv/netbackup/bin/nbemm

..bin/nbrb

bin/bpcompatd

bin/nbrmms

bin/nbs1

bin/nbsvcmon

bin/admincmd/bpstsinfo -DPSPROXY

MM Processes

root ....................vmd

Shared Symantec Processes

root....................../opt/VRTSpbx/bin/pbx_exchange

Side question:  When I'm on the master server under Storage Units and I select "New Storage Unit", I get cannot connect on socket (Status 25)

Thanks all you...

JohnnyBgood's picture

Some other related errors that I get are:

Host Properties>Media {I selected it and this error appeared}

Error:  Failed to initialize EMM Connection verify that network access to the EMM Server is available and that the services nbemm and pbx_exchange are running on the EMM server. (195)

EMM database error (196)

(MM Status 196)

I hope these clues help out.  Thanks again!

Marianne's picture

Please double-check NBU processes/services/daemons are up and running on master as well as media server.

Probably a good idea to restart NBU on master and media server - including PBX.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

SOLUTION
JohnnyBgood's picture

Hi Marianne,

I stopped and started NBU on both the master and media as well the PBX.

After restart I show these daemons running on the master server:

bpcompatd

bpdbm

bprd

ltid

NB_dbsrv

nbjm

nbpem

nbrmms

nbsl

nbstserv

nbsvcmon

vmd

These Daemons are not running:

bmrd

nbars

nbatd

nbaudit

nbazd

nbemm

nbevtmgr

nbkms

nbrb

spad

spoold

JohnnyBgood's picture

Hi Marianne,

Quick question, does it matter what order I stop and start NBU services/process/daemons/PBX on the master and media server?

Thanks a million!

JohnnyBgood's picture

Thanks again everyone for your advise.

Marianne, I stopped all of the NBU services/processes/daemons/ and PBX one more time on both master and media servers and then restarted NBU again.  I also restarted my media server after I brought up the master server first and I was able to uncheck that box I spoke about earlier under storage units.  So I'm up and running :-)

Marianne's picture

So, in summary the 'disk volume pool down' had nothing to do with "This directory can exist on the root file system or system disk" STU attribute, but was caused by master being unable to communicate with media server. This was solved by restart of NBU on master and media server.

The STU on the media server seems to the NFS mount on /dd01/backup, right? This means that the tickbox for directory to exist on root filesystem should never be selected. 

NFS mount for basic disk STU is supported, but not really a good idea as network issues could result in backup issues.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

JohnnyBgood's picture

Even though stoping and restarting the netbackup processes/services/daemons/PBX on both the master and media server resolved my problem temporarily but this issue came back again but this time it's also on another master server which leads me to believe that a log file is full and inturn cause netbackup NBDB to shutdown.  So I posted another thread call Disk volume down with more information.  Thank you all for your help.