DFS Volume Split error "Setting state to 265 for OperationID = (..) and RestoreFromRenamingState: rename(...) returned error 13".

During a DFS Volume split operation, where a folder was split off from an existing volume, and moved onto a new volume, the DFS volume split operation never finished.

The error 13 indicates a 'permission denied' error, so the problem is related to the rights of the user performing the DFS split operation, or to another permission issue.

In this case, it was required to remove the  DeleteInhibit(DI) and  RenameInhibit(RI) attributes for each file and folder as listed on the source volume which are listed at "RestoreFromRenamingState: rename(/media/nss/DATA/(folder_name)"

However, the perception is that such management operations should not be affected by attributes set to individual files and folders, and so a bug was also created to investigate the possibilities to make the DFS Volume Split operation ignore file & folder attributes.

The top level folder that was to split off to a new volume, contained a DeleteInhibit(DI) and RenameInhibit(RI) attribute, which caused the DFS volume split operation to log an error fail to complete.

The source server showed the following

server1:~ # volmn status
Volume Manager Status:
 OperationID   % State                            Request
  1412798014 100 Retry Rename                     SPLIT(DATA:data/Corp-Mktg)
Total Requests: 1,  1 active operations.
server1:~ #

When looking at  /var/log/messages  the following notification very repeatedly observed  :

Oct 15 18:57:04 server1 volmnd[6660]: Setting state to 265 for OperationID = 1412798014 (request 0x596b90)
Oct 15 19:02:04 server1 volmnd[6660]: RestoreFromRenamingState: rename(/media/nss/DATA/data/Corp-Mktg, /media/nss/DATA/data/$DFS_5435963E.000) returned error 13