diff --git a/tests/acceptance/expected-failures-API-on-OCIS-storage.md b/tests/acceptance/expected-failures-API-on-OCIS-storage.md
index bc9edd3c2..3c5a94fee 100644
--- a/tests/acceptance/expected-failures-API-on-OCIS-storage.md
+++ b/tests/acceptance/expected-failures-API-on-OCIS-storage.md
@@ -164,19 +164,19 @@ File and sync features in a shared scenario
 - [coreApiShareManagementToShares/acceptShares.feature:524](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L524)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:39](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L39)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:40](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L40)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:130](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L130)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L131)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:165](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L165)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:166](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L166)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:128](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L128)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:129](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L129)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L161)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:162](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L162)
 
 #### [sharing the shares folder to users exits with different status code than in oc10 backend](https://github.com/owncloud/ocis/issues/2215)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:743](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L743)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:744](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L744)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:762](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L762)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:763](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L763)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:778](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L778)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:779](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L779)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:733](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L733)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:734](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L734)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:752](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L752)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:753](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L753)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:768](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L768)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:769](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L769)
 
 #### [file_target of an auto-renamed file is not correct directly after sharing](https://github.com/owncloud/core/issues/32322)
 
@@ -184,15 +184,15 @@ File and sync features in a shared scenario
 
 #### [File deletion using dav gives unique string in filename in the trashbin](https://github.com/owncloud/product/issues/178)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:64](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L64)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:78](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L78)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:61](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L61)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:75](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L75)
 
 cannot share a folder with create permission
 
 #### [Resource with share permission create is readable for sharee](https://github.com/owncloud/ocis/issues/4524)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L131)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:144](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L144)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:125](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L125)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:138](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L138)
 
 
 #### [OCS error message for attempting to access share via share id as an unauthorized user is not informative](https://github.com/owncloud/ocis/issues/1233)
@@ -267,7 +267,7 @@ cannot share a folder with create permission
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:71](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L71)
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:92](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L92)
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:93](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L93)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:534](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L534)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:533](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L533)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:30](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L30)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:32](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L32)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:98](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L98)
@@ -289,37 +289,37 @@ cannot share a folder with create permission
 
 #### [Cannot move folder/file from one received share to another](https://github.com/owncloud/ocis/issues/2442)
 
-- [coreApiShareUpdateToShares/updateShare.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L197)
 - [coreApiShareUpdateToShares/updateShare.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L161)
+- [coreApiShareUpdateToShares/updateShare.feature:129](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L129)
 - [coreApiShareManagementToShares/mergeShare.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature#L131)
 
 #### [Sharing folder and sub-folder with same user but different permission,the permission of sub-folder is not obeyed ](https://github.com/owncloud/ocis/issues/2440)
 
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:262](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L262)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:297](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L297)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:406](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L406)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:441](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L441)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L222)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:253](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L253)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:352](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L352)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:383](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L383)
 
 #### [Empty OCS response for a share create request using a disabled user](https://github.com/owncloud/ocis/issues/2212)
 
 - [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:21](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L21)
-- [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:24](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L24)
+- [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:12](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L12)
 
 
 #### [Edit user share response has a "name" field](https://github.com/owncloud/ocis/issues/1225)
 
-- [coreApiShareUpdateToShares/updateShare.feature:243](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L243)
-- [coreApiShareUpdateToShares/updateShare.feature:244](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L244)
+- [coreApiShareUpdateToShares/updateShare.feature:236](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L236)
+- [coreApiShareUpdateToShares/updateShare.feature:237](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L237)
 
 #### [Share lists deleted user as 'user'](https://github.com/owncloud/ocis/issues/903)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:678](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L678)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:679](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L679)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:668](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L668)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:669](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L669)
 
 #### [deleting a share with wrong authentication returns OCS status 996 / HTTP 500](https://github.com/owncloud/ocis/issues/1229)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L227)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L228)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:221](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L221)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L222)
 
 ### User Management
 
@@ -451,8 +451,8 @@ And other missing implementation of favorites
 
 #### [Sharing a same file twice to the same group](https://github.com/owncloud/ocis/issues/1710)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:726](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L726)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:727](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L727)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:716](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L716)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:717](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L717)
 
 #### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
 
@@ -521,7 +521,7 @@ And other missing implementation of favorites
 #### [Shares to deleted group listed in the response](https://github.com/owncloud/ocis/issues/2441)
 
 - [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:530](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L530)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:531](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L531)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:529](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L529)
 
 #### [copying the file inside Shares folder returns 404](https://github.com/owncloud/ocis/issues/3874)
 
@@ -577,14 +577,14 @@ Not everything needs to be implemented for ocis. While the oc10 testsuite covers
 - [coreApiShareManagementToShares/acceptShares.feature:438](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L438)
 - [coreApiShareOperationsToShares2/shareAccessByID.feature:122](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L122)
 - [coreApiShareOperationsToShares2/shareAccessByID.feature:123](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L123)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:178](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L178)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:179](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L179)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:180](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L180)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:181](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L181)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L197)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:198](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L198)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:199](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L199)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:200](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L200)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:172](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L172)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:173](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L173)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:174](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L174)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:175](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L175)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:191](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L191)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:192](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L192)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:193](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L193)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:194](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L194)
 
 #### [Content-type is not multipart/byteranges when downloading file with Range Header](https://github.com/owncloud/ocis/issues/2677)
 
diff --git a/tests/acceptance/features/apiGraph/editUser.feature b/tests/acceptance/features/apiGraph/editUser.feature
index 91fc634ce..85f3b84e5 100644
--- a/tests/acceptance/features/apiGraph/editUser.feature
+++ b/tests/acceptance/features/apiGraph/editUser.feature
@@ -186,7 +186,7 @@ Feature: edit user
       | User        | Admin       |
       | User Light  | Space Admin |
       | User Light  | User        |
-      | User Light  | User Light       |
+      | User Light  | User Light  |
       | User Light  | Admin       |
 
 
@@ -209,11 +209,11 @@ Feature: edit user
     }
     """
     Examples:
-      | action description                | newDisplayName | code | displayNameAsResult |
-      | change to a display name          | Olaf Scholz    | 200  | Olaf Scholz         |
-      | override to existing display name | Carol King     | 200  | Carol King          |
-      | change to an empty display name   |                | 400  | Brian Murphy        |
-      | displayName with characters       | *:!;_+-&#(?)   | 200  | *:!;_+-&#(?)        |
+      | action description                | newDisplayName | displayNameAsResult |
+      | change to a display name          | Olaf Scholz    | Olaf Scholz         |
+      | override to existing display name | Carol King     | Carol King          |
+      | change to an empty display name   |                | Brian Murphy        |
+      | displayName with characters       | *:!;_+-&#(?)   | *:!;_+-&#(?)        |
 
 
   Scenario Outline: normal user should not be able to change his/her own display name
@@ -239,7 +239,7 @@ Feature: edit user
       | role        |
       | Space Admin |
       | User        |
-      | User Light       |
+      | User Light  |
 
 
   Scenario Outline: normal user should not be able to edit another user's display name
@@ -500,4 +500,4 @@ Feature: edit user
       | role        |
       | Space Admin |
       | User        |
-      | User Light       |
+      | User Light  |
diff --git a/tests/acceptance/features/apiGraph/getUser.feature b/tests/acceptance/features/apiGraph/getUser.feature
index 97e80fd09..fee9d72cd 100644
--- a/tests/acceptance/features/apiGraph/getUser.feature
+++ b/tests/acceptance/features/apiGraph/getUser.feature
@@ -90,7 +90,7 @@ Feature: get users
       | User        | Admin       |
       | User Light  | Space Admin |
       | User Light  | User        |
-      | User Light  | User Light       |
+      | User Light  | User Light  |
       | User Light  | Admin       |
 
   @skipOnStable2.0
diff --git a/tests/acceptance/features/apiSpaces/quota.feature b/tests/acceptance/features/apiSpaces/quota.feature
index fe80a9f21..d31e23198 100644
--- a/tests/acceptance/features/apiSpaces/quota.feature
+++ b/tests/acceptance/features/apiSpaces/quota.feature
@@ -21,7 +21,7 @@ Feature: State of the quota
 
 
   Scenario Outline: quota information is returned in the list of spaces returned via the Graph API
-    Given user "Alice" has created a space "<spaceName>" of type "project" with quota "<total>"
+    Given user "Alice" has created a space "<spaceName>" of type "project" with quota "100"
     When user "Alice" uploads a file inside space "<spaceName>" with content "<fileContent>" to "test.txt" using the WebDAV API
     And user "Alice" lists all available spaces via the GraphApi
     Then the JSON response should contain space called "<spaceName>" and match
@@ -52,7 +52,7 @@ Feature: State of the quota
             },
             "total" : {
               "type": "number",
-              "enum": [<total>]
+              "enum": [100]
             },
             "remaining" : {
               "type": "number",
@@ -68,14 +68,14 @@ Feature: State of the quota
     }
     """
     Examples:
-      | spaceName | fileContent                                                                                           | state    | total | remaining | used |
-      | Quota1%   | 1                                                                                                    | normal   | 100   | 99        | 1    |
-      | Quota75%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345                          | normal   | 100   | 25        | 75   |
-      | Quota76%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456                         | nearing  | 100   | 24        | 76   |
-      | Quota90%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890           | nearing  | 100   | 10        | 90   |
-      | Quota91%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1          | critical | 100   | 9         | 91   |
-      | Quota99%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789  | critical | 100   | 1         | 99   |
-      | Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 100   | 0         | 100  |
+      | spaceName | fileContent                                                                                          | state    | remaining | used |
+      | Quota1%   | 1                                                                                                    | normal   | 99        | 1    |
+      | Quota75%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345                          | normal   | 25        | 75   |
+      | Quota76%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456                         | nearing  | 24        | 76   |
+      | Quota90%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890           | nearing  | 10        | 90   |
+      | Quota91%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1          | critical | 9         | 91   |
+      | Quota99%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789  | critical | 1         | 99   |
+      | Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 0         | 100  |
 
 
   Scenario: file cannot be uploaded if there is insufficient quota
diff --git a/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature b/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
index 8eafce197..0ac78bbe2 100644
--- a/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
+++ b/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
@@ -1,4 +1,4 @@
-@api 
+@api
 Feature: Remove files, folder
   As a user
   I want to be able to remove files, folders
@@ -65,11 +65,11 @@ Feature: Remove files, folder
       | text.txt |
     And as "<user>" file "text.txt" <shouldOrNotBeInTrash> exist in the trashbin of the space "delete objects"
     Examples:
-      | user  | role    | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash | quotaValue |
-      | Alice | manager | 204  | should not           | should               | 0          |
-      | Brian | manager | 204  | should not           | should               | 0          |
-      | Brian | editor  | 204  | should not           | should               | 0          |
-      | Brian | viewer  | 403  | should               | should not           | 12         |
+      | user  | role    | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
+      | Alice | manager | 204  | should not           | should               |
+      | Brian | manager | 204  | should not           | should               |
+      | Brian | editor  | 204  | should not           | should               |
+      | Brian | viewer  | 403  | should               | should not           |
 
 
   Scenario: try to delete an empty string folder from a space
diff --git a/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature b/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
index eaf30dbe6..7bc737b02 100644
--- a/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
+++ b/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
@@ -1,4 +1,4 @@
-@api 
+@api
 Feature: Restore files, folder
   As a user with manager and editor role
   I want to be able to restore files, folders
@@ -27,15 +27,15 @@ Feature: Restore files, folder
       | role      | <role> |
     And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
     And user "Alice" has removed the folder "newFolder" from space "restore objects"
-    When user "<user>" lists all deleted files in the trash bin of the space "restore objects"
+    When user "Brian" lists all deleted files in the trash bin of the space "restore objects"
     Then the HTTP status code should be "207"
-    And as "<user>" folder "newFolder" should exist in the trashbin of the space "restore objects"
-    And as "<user>" file "file.txt" should exist in the trashbin of the space "restore objects"
+    And as "Brian" folder "newFolder" should exist in the trashbin of the space "restore objects"
+    And as "Brian" file "file.txt" should exist in the trashbin of the space "restore objects"
     Examples:
-      | user  | role    |
-      | Brian | manager |
-      | Brian | editor  |
-      | Brian | viewer  |
+      | role    |
+      | manager |
+      | editor  |
+      | viewer  |
 
 
   Scenario Outline: user can restore a folder with some objects from the trash via the webDav API
diff --git a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
index 101bdda2a..72aeb4944 100644
--- a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
+++ b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
@@ -74,15 +74,15 @@ Feature: Share a file or folder that is inside a space
       | path      | <entity> |
       | shareWith | Bob      |
       | role      | editor   |
-    Then the HTTP status code should be "<statusCode>"
-    And the OCS status code should be "<statusCode>"
-    And the OCS status message should be "<statusMessage>"
+    Then the HTTP status code should be "404"
+    And the OCS status code should be "404"
+    And the OCS status message should be "No share permission"
     Examples:
-      | entity   | spaceRole | statusCode | statusMessage       |
-      | folder   | editor    | 404        | No share permission |
-      | file.txt | editor    | 404        | No share permission |
-      | file.txt | viewer    | 404        | No share permission |
-      | folder   | viewer    | 404        | No share permission |
+      | entity   | spaceRole |
+      | folder   | editor    |
+      | file.txt | editor    |
+      | file.txt | viewer    |
+      | folder   | viewer    |
 
 
   Scenario Outline: user participant of the project space can see the created resources share
diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature
index 6f0494c83..0101618ba 100644
--- a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature
+++ b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature
@@ -51,14 +51,14 @@ Feature: COPY file/folder
       | /remote.php/dav/files/%username%/PARENT/parent.txt |
     Then the HTTP status code of responses on all endpoints should be "403"
 
- @skipOnRevaMaster
- Scenario: send COPY requests to another user's webDav endpoints as normal user using the spaces WebDAV API
-   When user "Brian" requests these endpoints with "COPY" about user "Alice"
-     | endpoint                                           |
-     | /remote.php/dav/spaces/%spaceid%/textfile0.txt     |
-     | /remote.php/dav/spaces/%spaceid%/PARENT            |
-     | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
-   Then the HTTP status code of responses on all endpoints should be "403"
+  @skipOnRevaMaster
+  Scenario: send COPY requests to another user's webDav endpoints as normal user using the spaces WebDAV API
+    When user "Brian" requests these endpoints with "COPY" about user "Alice"
+      | endpoint                                           |
+      | /remote.php/dav/spaces/%spaceid%/textfile0.txt     |
+      | /remote.php/dav/spaces/%spaceid%/PARENT            |
+      | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
+    Then the HTTP status code of responses on all endpoints should be "403"
 
 
   Scenario: send COPY requests to webDav endpoints using invalid username but correct password
@@ -114,7 +114,7 @@ Feature: COPY file/folder
       | /remote.php/dav/files/%username%/PARENT/parent.txt |
     Then the HTTP status code of responses on all endpoints should be "415"
 
- @skipOnRevaMaster
+  @skipOnRevaMaster
   Scenario: send COPY requests to webDav endpoints with body as normal user using the spaces WebDAV API
     When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice"
       | endpoint                                           |
diff --git a/tests/acceptance/features/coreApiCapabilities/capabilities.feature b/tests/acceptance/features/coreApiCapabilities/capabilities.feature
index e34ae3e5e..baf6f7ba9 100644
--- a/tests/acceptance/features/coreApiCapabilities/capabilities.feature
+++ b/tests/acceptance/features/coreApiCapabilities/capabilities.feature
@@ -93,7 +93,7 @@ Feature: capabilities
     }
     """
 
- @skipOnReva
+  @skipOnReva
   Scenario: getting versions app capability with admin user
     When the administrator retrieves the capabilities using the capabilities API
     Then the OCS status code should be "100"
diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
index eff5467db..c0812611e 100644
--- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
+++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
@@ -25,7 +25,7 @@ Feature: share resources where the sharee receives the share in multiple ways
     And the fields of the last response to user "Alice" sharing with user "Brian" should include
       | share_with             | %username%                |
       | share_with_displayname | %displayname%             |
-      | file_target            | <file_target>             |
+      | file_target            | /textfile0 (2).txt        |
       | path                   | /Shares/textfile0 (2).txt |
       | permissions            | share,read,update         |
       | uid_owner              | %username%                |
@@ -35,9 +35,9 @@ Feature: share resources where the sharee receives the share in multiple ways
       | storage_id             | ANY_VALUE                 |
       | share_type             | user                      |
     Examples:
-      | ocs_api_version | ocs_status_code | file_target        |
-      | 1               | 100             | /textfile0 (2).txt |
-      | 2               | 200             | /textfile0 (2).txt |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-1289
   Scenario Outline: share of folder and sub-folder to same user
@@ -53,16 +53,16 @@ Feature: share resources where the sharee receives the share in multiple ways
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And user "Brian" should be able to accept pending share "/PARENT" offered by user "Alice"
-    And user "Brian" should be able to accept pending share "<pending_sub_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/CHILD" offered by user "Alice"
     And user "Brian" should see the following elements
       | /Shares/PARENT/           |
       | /Shares/PARENT/parent.txt |
       | /Shares/CHILD/            |
       | /Shares/CHILD/child.txt   |
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
-      | 1               | 100             | /CHILD                 |
-      | 2               | 200             | /CHILD                 |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-2021
   Scenario Outline: sharing subfolder when parent already shared
@@ -74,12 +74,12 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/sub" offered by user "Alice"
     And as "Brian" folder "/Shares/sub" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
-      | 1               | 100             | /sub               |
-      | 2               | 200             | /sub               |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-2021
   Scenario Outline: sharing subfolder when parent already shared with group of sharer
@@ -92,14 +92,14 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/sub" offered by user "Alice"
     And as "Brian" folder "/Shares/sub" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
-      | 1               | 100             | /sub               |
-      | 2               | 200             | /sub               |
-
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
+  @issue-2131
   Scenario Outline: multiple users share a file with the same name but different permissions to a user
     Given using OCS API version "<ocs_api_version>"
     And user "Carol" has been created with default attributes and without skeleton files
@@ -110,27 +110,25 @@ Feature: share resources where the sharee receives the share in multiple ways
     Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
       | uid_owner   | %username%      |
       | share_with  | %username%      |
-      | file_target | <file_target_1> |
+      | file_target | /randomfile.txt |
       | item_type   | file            |
       | permissions | read            |
     When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API
     And user "Alice" accepts share "/randomfile.txt" offered by user "Carol" using the sharing API
     Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
-      | uid_owner   | %username%      |
-      | share_with  | %username%      |
-      | file_target | <file_target_2> |
-      | item_type   | file            |
-      | permissions | read,update     |
+      | uid_owner   | %username%          |
+      | share_with  | %username%          |
+      | file_target | /randomfile (2).txt |
+      | item_type   | file                |
+      | permissions | read,update         |
     And the content of file "/Shares/randomfile.txt" for user "Alice" should be "First data"
     And the content of file "/Shares/randomfile (2).txt" for user "Alice" should be "Second data"
-
-    @issue-2131
     Examples:
-      | ocs_api_version | file_target_1   | file_target_2       |
-      | 1               | /randomfile.txt | /randomfile (2).txt |
-      | 2               | /randomfile.txt | /randomfile (2).txt |
-
+      | ocs_api_version |
+      | 1               |
+      | 2               |
 
+  @issue-2131
   Scenario Outline: multiple users share a folder with the same name to a user
     Given using OCS API version "<ocs_api_version>"
     And user "Carol" has been created with default attributes and without skeleton files
@@ -141,31 +139,29 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API
     And user "Alice" accepts share "/zzzfolder" offered by user "Brian" using the sharing API
     Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
-      | uid_owner   | %username%      |
-      | share_with  | %username%      |
-      | file_target | <file_target_1> |
-      | item_type   | folder          |
-      | permissions | read,delete     |
+      | uid_owner   | %username%  |
+      | share_with  | %username%  |
+      | file_target | /zzzfolder  |
+      | item_type   | folder      |
+      | permissions | read,delete |
     When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API
     Then the HTTP status code should be "200"
     And the OCS status code should be "<ocs_status_code>"
     And user "Alice" should be able to accept pending share "/zzzfolder" offered by user "Carol"
     Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
-      | uid_owner   | %username%      |
-      | share_with  | %username%      |
-      | file_target | <file_target_2> |
-      | item_type   | folder          |
-      | permissions | read,share      |
+      | uid_owner   | %username%     |
+      | share_with  | %username%     |
+      | file_target | /zzzfolder (2) |
+      | item_type   | folder         |
+      | permissions | read,share     |
     And as "Alice" folder "/Shares/zzzfolder/Brian" should exist
     And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist
-
-    @issue-2131
     Examples:
-      | ocs_api_version | file_target_1 | file_target_2  | ocs_status_code |
-      | 1               | /zzzfolder    | /zzzfolder (2) | 100             |
-      | 2               | /zzzfolder    | /zzzfolder (2) | 200             |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
- @skipOnGraph
+  @skipOnGraph
   Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name
     Given using OCS API version "<ocs_api_version>"
     And user "Carol" has been created with default attributes and without skeleton files
@@ -192,8 +188,8 @@ Feature: share resources where the sharee receives the share in multiple ways
       | 1               | 100             |
       | 2               | 200             |
 
-
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
+  @issue-2440
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -214,20 +210,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to create folder "/Shares/parent/fo1"
     And user "Brian" should be able to create folder "/Shares/parent/child1/fo2"
     And user "Alice" should not be able to create folder "/Shares/child1/fo3"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
+  @issue-2440
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -249,20 +241,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
     And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
     And user "Alice" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
+  @issue-2440
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -284,20 +272,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to delete file "/Shares/parent/child1/child2/textfile-2.txt"
     And user "Brian" should not be able to delete folder "/Shares/child1/child2"
     And user "Alice" should not be able to delete folder "/Shares/child1/child2"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -318,8 +302,8 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     And user "Brian" has accepted share "/parent" offered by user "Carol"
-    And user "Brian" has accepted share "<path>" offered by user "Carol"
-    And user "Alice" has accepted share "<path>" offered by user "Carol"
+    And user "Brian" has accepted share "/child1" offered by user "Carol"
+    And user "Alice" has accepted share "/child1" offered by user "Carol"
     When user "Brian" creates a share using the sharing API with settings
       | path        | /Shares/parent |
       | shareType   | user           |
@@ -331,12 +315,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And as "Brian" folder "/Shares/child1" should exist
     And as "Alice" folder "/Shares/child1" should exist
     And as "Alice" folder "/Shares/parent" should exist
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -356,7 +337,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -366,12 +347,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     But user "Brian" should not be able to create folder "/Shares/parent/fo3"
     And user "Brian" should not be able to create folder "/Shares/parent/fo3"
     And user "Alice" should not be able to create folder "/Shares/parent/fo3"
-    Examples:
-      | path    |
-      | /child1 |
 
-
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
+  @issue-2440
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -392,7 +370,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -400,13 +378,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt"
     And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
     And user "Alice" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
+  @issue-2440
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -427,7 +401,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -435,13 +409,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt"
     And user "Brian" should not be able to delete folder "/Shares/parent/child1"
     And user "Alice" should not be able to delete folder "/Shares/parent/child1"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -461,22 +431,19 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API
-    And user "Alice" should be able to accept pending share "<path>" offered by user "Brian"
+    And user "Alice" should be able to accept pending share "/child1" offered by user "Brian"
     And as "Brian" folder "/Shares/parent" should exist
     And as "Alice" folder "/Shares/parent" should exist
     And as "Alice" folder "/Shares/child1" should exist
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to one group with all permissions and its child folder to another group with read permission
+  Scenario: sharing parent folder to one group with all permissions and its child folder to another group with read permission
     Given these groups have been created:
       | groupname |
       | grp1      |
@@ -502,7 +469,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp2           |
       | permissions | read           |
     When user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Alice" should be able to create folder "/Shares/parent/child1/fo1"
@@ -516,9 +483,6 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2"
     And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
     And user "Brian" should not be able to share folder "/Shares/child1" with group "grp3" with permissions "read" using the sharing API
-    Examples:
-      | path    |
-      | /child1 |
 
 
   Scenario Outline: share receiver renames the received group share and shares same folder through user share again
diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature
index e688df358..bbccb7b17 100644
--- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature
+++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature
@@ -9,16 +9,13 @@ Feature: share resources with a disabled user
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
 
   @issue-2212
-  Scenario Outline: creating a new share with a disabled user
-    Given using OCS API version "<ocs_api_version>"
+  Scenario: creating a new share with a disabled user
+    Given using OCS API version "1"
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has been disabled
     When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "997"
     And the HTTP status code should be "401"
-    Examples:
-      | ocs_api_version | ocs_status_code |
-      | 1               | 997             |
 
 
   Scenario: creating a new share with a disabled user
diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
index 9c0cc41d6..695330637 100644
--- a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
+++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
@@ -467,7 +467,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
- @skipOnGraph
+  @skipOnGraph
   Scenario Outline: share with a group and then add a user to that group
     Given using OCS API version "<ocs_api_version>"
     And these users have been created with default attributes and without skeleton files:
@@ -492,8 +492,8 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-
   # deleting an LDAP group is not relevant or possible using the provisioning API
+  @issue-2441
   Scenario Outline: shares shared to deleted group should not be available
     Given using OCS API version "<ocs_api_version>"
     And these users have been created with default attributes and without skeleton files:
@@ -510,7 +510,7 @@ Feature: sharing
     And the HTTP status code should be "200"
     And the fields of the last response to user "Alice" sharing with group "grp1" should include
       | share_with  | grp1           |
-      | file_target | <path>         |
+      | file_target | /textfile0.txt |
       | path        | /textfile0.txt |
       | uid_owner   | %username%     |
     When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
@@ -524,11 +524,10 @@ Feature: sharing
     And file "/textfile0.txt" should not be included as path in the response
     And as "Brian" file "/Shares/textfile0.txt" should not exist
     And as "Carol" file "/Shares/textfile0.txt" should not exist
-    @issue-2441
     Examples:
-      | ocs_api_version | ocs_status_code | path           |
-      | 1               | 100             | /textfile0.txt |
-      | 2               | 200             | /textfile0.txt |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-2146
   Scenario: share a file by multiple channels and download from sub-folder and direct file share
@@ -560,7 +559,7 @@ Feature: sharing
     And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing back to resharer is allowed
+  Scenario: sharing back to resharer is allowed
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -570,18 +569,15 @@ Feature: sharing
     And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
-    And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/userOneFolder" offered by user "Brian"
     When user "Carol" shares folder "/Shares/userOneFolder" with user "Brian" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Brian" that no shares are in the pending state
     And as "Brian" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing back to original sharer is allowed
+  Scenario: sharing back to original sharer is allowed
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -591,18 +587,15 @@ Feature: sharing
     And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
-    And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/userOneFolder" offered by user "Brian"
     When user "Carol" shares folder "/Shares/userOneFolder" with user "Alice" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Alice" that no shares are in the pending state
     And as "Alice" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing a subfolder to a user that already received parent folder share
+  Scenario: sharing a subfolder to a user that already received parent folder share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -615,15 +608,12 @@ Feature: sharing
     And user "Carol" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "David" with permissions "read, share"
-    And user "David" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "David" has accepted share "/userOneFolder" offered by user "Brian"
     When user "David" shares folder "/Shares/userOneFolder" with user "Carol" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Carol" that no shares are in the pending state
     And as "Carol" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @smokeTest
   Scenario Outline: creating a share of a renamed file
diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature
index 0703a74ec..2503ede9a 100644
--- a/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature
+++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature
@@ -46,19 +46,16 @@ Feature: sharing
       | 2               | 200             |
 
 
-  Scenario Outline: orphaned shares
+  Scenario: orphaned shares
     Given using OCS API version "1"
     And user "Alice" has created folder "/common"
     And user "Alice" has created folder "/common/sub"
     And user "Alice" has shared folder "/common/sub" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/sub" offered by user "Alice"
     When user "Alice" deletes folder "/common" using the WebDAV API
     Then the HTTP status code should be "204"
     And as "Brian" folder "/Shares/sub" should not exist
     And as "Brian" folder "/sub" should not exist
-    Examples:
-      | pending_share_path |
-      | /sub               |
 
   @smokeTest
   Scenario: deleting a file out of a share as recipient creates a backup for the owner
@@ -92,7 +89,7 @@ Feature: sharing
     And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin
 
   @smokeTest
-  Scenario Outline: unshare from self
+  Scenario: unshare from self
     And group "grp1" has been created
     And these users have been created with default attributes and without skeleton files:
       | username |
@@ -102,7 +99,7 @@ Feature: sharing
     And user "Carol" has created folder "PARENT"
     And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
     And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Carol"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Carol"
     And user "Carol" has stored etag of element "/PARENT"
     And user "Brian" has stored etag of element "/"
     And user "Brian" has stored etag of element "/Shares"
@@ -111,9 +108,6 @@ Feature: sharing
     And the etag of element "/" of user "Brian" should have changed
     And the etag of element "/Shares" of user "Brian" should have changed
     And the etag of element "/PARENT" of user "Carol" should not have changed
-    Examples:
-      | pending_share_path |
-      | /parent.txt        |
 
 
   Scenario: sharee of a read-only share folder tries to delete the shared folder
@@ -220,12 +214,12 @@ Feature: sharing
     And user "Alice" has shared file "textfile0.txt" with user "Brian"
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Brian" tries to delete the last share of user "Alice" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 404             | 200              |
-      | 2               | 404             | 404              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
 
 
   Scenario Outline: unshare a shared resources
@@ -234,9 +228,9 @@ Feature: sharing
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Alice" unshares file "textfile0.txt" shared to "Brian"
     Then the OCS status code should be "<ocs_status_code>"
-    And the HTTP status code should be "<http_status_code>"
+    And the HTTP status code should be "200"
     And as "Brian" file "/Shares/textfile0.txt" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 100             | 200              |
-      | 2               | 200             | 200              |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
index d30a5b7ff..d866e742b 100644
--- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
+++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
@@ -179,12 +179,12 @@ Feature: sharing
     And user "Alice" has created folder "/PARENT"
     And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     When user "Alice" gets all the shares inside the folder "PARENT" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And file "/Shares/parent.txt" should be included in the response
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
-      | 1               | 100             | /parent.txt        |
-      | 2               | 200             | /parent.txt        |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature
index 5fc46aeba..7a230e00c 100644
--- a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature
+++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature
@@ -273,12 +273,12 @@ Feature: create a public link share
     Given using OCS API version "<ocs_api_version>"
     When user "Alice" creates a public link share using the sharing API with settings
       | path | / |
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "400"
     And the HTTP status code should be "<http_status_code>"
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 400             | 200              |
-      | 2               | 400             | 400              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 400              |
 
 
   Scenario Outline: user creates a public link share of a file with file name longer than 64 chars using the public WebDAV API
diff --git a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature
index 5664945a4..dd0d95db5 100644
--- a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature
+++ b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature
@@ -330,7 +330,7 @@ Feature: update a public link share
       | 1               | 100             |
       | 2               | 200             |
 
-
+  @issue-1269
   Scenario Outline: updating share permissions from change to read restricts public from deleting files using the public API
     Given using OCS API version "<ocs_api_version>"
     And user "Alice" has created folder "PARENT"
@@ -345,8 +345,6 @@ Feature: update a public link share
     And the public deletes file "CHILD/child.txt" from the last public link share using the new public WebDAV API
     And the HTTP status code of responses on all endpoints should be "403"
     And as "Alice" file "PARENT/CHILD/child.txt" should exist
-
-    @issue-1269
     Examples:
       | ocs_api_version |
       | 1               |
diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
index b600d48e0..df88a9264 100644
--- a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
+++ b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
@@ -113,7 +113,7 @@ Feature: sharing
   Scenario Outline: user is not allowed to reshare file and set more permissions bits
     Given using OCS API version "<ocs_api_version>"
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions <received_permissions>
+    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions 17
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions <reshare_permissions> using the sharing API
     Then the OCS status code should be "404"
@@ -122,21 +122,21 @@ Feature: sharing
     And the sharing API should report to user "Carol" that no shares are in the pending state
     But as "Brian" file "/Shares/textfile0.txt" should exist
     Examples:
-      | ocs_api_version | http_status_code | received_permissions | reshare_permissions |
+      | ocs_api_version | http_status_code | reshare_permissions |
       # passing on more bits including reshare
-      | 1               | 200              | 17                   | 19                  |
-      | 2               | 404              | 17                   | 19                  |
-      | 1               | 200              | 17                   | 23                  |
-      | 2               | 404              | 17                   | 23                  |
-      | 1               | 200              | 17                   | 31                  |
-      | 2               | 404              | 17                   | 31                  |
+      | 1               | 200              | 19                  |
+      | 2               | 404              | 19                  |
+      | 1               | 200              | 23                  |
+      | 2               | 404              | 23                  |
+      | 1               | 200              | 31                  |
+      | 2               | 404              | 31                  |
       # passing on more bits but not reshare
-      | 1               | 200              | 17                   | 3                   |
-      | 2               | 404              | 17                   | 3                   |
-      | 1               | 200              | 17                   | 7                   |
-      | 2               | 404              | 17                   | 7                   |
-      | 1               | 200              | 17                   | 15                  |
-      | 2               | 404              | 17                   | 15                  |
+      | 1               | 200              | 3                   |
+      | 2               | 404              | 3                   |
+      | 1               | 200              | 7                   |
+      | 2               | 404              | 7                   |
+      | 1               | 200              | 15                  |
+      | 2               | 404              | 15                  |
 
 
   Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored
diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
index dffeec535..6a6e8550d 100644
--- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
+++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
@@ -21,13 +21,13 @@ Feature: a subfolder of a received share can be reshared
     When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Carol" should be able to accept pending share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" should be able to accept pending share "/SUB" offered by user "Brian"
     And as "Carol" folder "/Shares/SUB" should exist
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
-      | 1               | 100             | /SUB                   |
-      | 2               | 200             | /SUB                   |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
 
   Scenario Outline: user is not allowed to reshare a sub-folder with more permissions
@@ -89,7 +89,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | share,read |
     Then the OCS status code should be "<ocs_status_code>"
@@ -99,9 +99,9 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
-      | 1               | 100             | /SUB                   |
-      | 2               | 200             | /SUB                   |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-2214
   Scenario Outline: user is allowed to update reshare of a sub-folder to the maximum allowed permissions
@@ -109,7 +109,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | share,create,update,read |
     Then the OCS status code should be "<ocs_status_code>"
@@ -119,9 +119,9 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
-      | 1               | 100             | /SUB                   |
-      | 2               | 200             | /SUB                   |
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
 
   @issue-2214
   Scenario Outline: user is not allowed to update reshare of a sub-folder with more permissions
@@ -129,7 +129,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | all |
     Then the OCS status code should be "404"
@@ -139,6 +139,6 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | http_status_code | pending_sub_share_path |
-      | 1               | 200              | /SUB                   |
-      | 2               | 404              | /SUB                   |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
index b284ab103..00355cc66 100644
--- a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
+++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
@@ -126,7 +126,7 @@ Feature: sharing
       | 2               | 400              | create,delete |
 
   @issue-2201
-  Scenario Outline: share ownership change after moving a shared file outside of an outer share
+  Scenario: share ownership change after moving a shared file outside of an outer share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -137,7 +137,7 @@ Feature: sharing
     And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all"
     And user "Brian" has accepted share "/folder1" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/folder1/folder2" with user "Carol" with permissions "all"
-    And user "Carol" has accepted share "<folder2_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/folder2" offered by user "Brian"
     When user "Brian" moves folder "/Shares/folder1/folder2" to "/moved-out/folder2" using the WebDAV API
     Then the HTTP status code should be "201"
     And the response when user "Brian" gets the info of the last share should include
@@ -156,12 +156,9 @@ Feature: sharing
       | mimetype          | httpd/unix-directory |
     And as "Alice" folder "/Shares/folder1/folder2" should not exist
     And as "Carol" folder "/Shares/folder2" should exist
-    Examples:
-      | folder2_share_path |
-      | /folder2           |
 
-
-  Scenario Outline: share ownership change after moving a shared file to another share
+  @issue-2442
+  Scenario: share ownership change after moving a shared file to another share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -181,7 +178,7 @@ Feature: sharing
       | item_source       | A_STRING             |
       | share_type        | user                 |
       | file_source       | A_STRING             |
-      | file_target       | <path>               |
+      | file_target       | /Carol-folder        |
       | permissions       | all                  |
       | stime             | A_NUMBER             |
       | storage           | A_STRING             |
@@ -191,10 +188,6 @@ Feature: sharing
       | mimetype          | httpd/unix-directory |
     And as "Alice" folder "/Alice-folder/folder2" should not exist
     And as "Carol" folder "/Carol-folder/folder2" should exist
-    @issue-2442
-    Examples:
-      | path          |
-      | /Carol-folder |
 
   @issue-1253 @issue-1224 @issue-1225
   #after fixing all the issues merge this scenario with the one below
diff --git a/tests/acceptance/features/coreApiSharees/sharees.feature b/tests/acceptance/features/coreApiSharees/sharees.feature
index 9dee6fb15..a0bda6677 100644
--- a/tests/acceptance/features/coreApiSharees/sharees.feature
+++ b/tests/acceptance/features/coreApiSharees/sharees.feature
@@ -20,7 +20,7 @@ Feature: search sharees
       | search   | sharee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -31,9 +31,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search without exact match not-exact casing
@@ -42,7 +42,7 @@ Feature: search sharees
       | search   | sHaRee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -53,9 +53,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search only with group members - allowed
@@ -87,7 +87,7 @@ Feature: search sharees
       | search   | Sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -96,9 +96,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search with exact match not-exact casing
@@ -107,7 +107,7 @@ Feature: search sharees
       | search   | sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -116,9 +116,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search with exact match not-exact casing group
@@ -127,7 +127,7 @@ Feature: search sharees
       | search   | shareegroup2 |
       | itemType | file         |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be empty
     And the "exact groups" sharees returned should be
@@ -136,9 +136,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search with "self"
@@ -147,7 +147,7 @@ Feature: search sharees
       | search   | Sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -156,9 +156,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: enumerate only group members - only show partial results from member of groups
@@ -171,7 +171,7 @@ Feature: search sharees
       | search   | anot |
       | itemType | file |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Another | 0 | another |
@@ -180,9 +180,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
 
 
   Scenario Outline: search without exact match such that the search string matches the user getting the sharees
@@ -192,7 +192,7 @@ Feature: search sharees
       | search   | sharee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -204,6 +204,6 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 100        | 200         |
-      | 2               | 200        | 200         |
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature
index 1fa366193..1d8fb8e04 100644
--- a/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature
+++ b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature
@@ -93,16 +93,16 @@ Feature: files and folders can be deleted from the trashbin
     And user "Alice" has deleted file "/PARENT/parent.txt"
     And user "Alice" has deleted file "/PARENT/CHILD/child.txt"
     When user "Brian" tries to delete the file with original path "textfile1.txt" from the trashbin of user "Alice" using the trashbin API
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin
     And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin
     And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin
     And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
-      | new      | 404         |
-      | spaces   | 404         |
+      | dav-path |
+      | new      |
+      | spaces   |
 
 
   Scenario Outline: user tries to delete trashbin file using invalid password
diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
index 98b79afb5..e40fc0718 100644
--- a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
+++ b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
@@ -166,15 +166,15 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "Brian" has been created with default attributes and without skeleton files
     And user "testtrashbin100" has deleted file "/textfile1.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin100"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile1.txt | testtrashbin100 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
-      | new      | 404         |
-      | spaces   | 404         |
+      | dav-path |
+      | new      |
+      | spaces   |
 
   @issue-3561 @smokeTest
   Scenario Outline: listing other user's trashbin is prohibited with multiple files on trashbin
@@ -186,16 +186,16 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "testtrashbin101" has deleted file "/textfile0.txt"
     And user "testtrashbin101" has deleted file "/textfile2.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin101"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile0.txt | testtrashbin101 |
       | textfile2.txt | testtrashbin101 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
-      | new      | 404         |
-      | spaces   | 404         |
+      | dav-path |
+      | new      |
+      | spaces   |
 
   @issue-3561  @provisioning_api-app-required
   Scenario Outline: listing other user's trashbin is prohibited for newly recreated user with same name
@@ -211,7 +211,7 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile3.txt"
     And user "testtrashbin102" has deleted file "/textfile3.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin102"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile0.txt | testtrashbin102 |
@@ -219,9 +219,9 @@ Feature: files and folders exist in the trashbin after being deleted
       | textfile3.txt | testtrashbin102 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
-      | new      | 404         |
-      | spaces   | 404         |
+      | dav-path |
+      | new      |
+      | spaces   |
 
   @issue-3561
   Scenario Outline: listing other user's empty unused trashbin is prohibited
diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
index 9c8b7e10e..ca1139cb9 100644
--- a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
+++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
@@ -136,14 +136,14 @@ Feature: restore deleted files/folders
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has deleted file "/textfile0.txt"
     When user "Brian" tries to restore the file with original path "/textfile0.txt" from the trashbin of user "Alice" using the trashbin API
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin
     And user "Alice" should not see the following elements
       | /textfile0.txt |
     Examples:
-      | dav-path | status-code |
-      | old      | 404         |
-      | new      | 404         |
+      | dav-path |
+      | old      |
+      | new      |
 
   @smokeTest
   Scenario Outline: deleted file cannot be restored with invalid password
diff --git a/tests/acceptance/features/coreApiVersions/fileVersions.feature b/tests/acceptance/features/coreApiVersions/fileVersions.feature
index 548df6b27..159ca5661 100644
--- a/tests/acceptance/features/coreApiVersions/fileVersions.feature
+++ b/tests/acceptance/features/coreApiVersions/fileVersions.feature
@@ -69,20 +69,17 @@ Feature: dav-versions
     And the content of file "/davtest.txt" for user "Alice" should be "Back To The Future."
 
   @smokeTest @skipOnStorage:ceph
-  Scenario Outline: uploading a chunked file does create the correct version that can be restored
-    Given using <dav-path> DAV path
+  Scenario: uploading a chunked file does create the correct version that can be restored
+    Given using old DAV path
     And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
     When user "Alice" uploads file "filesForUpload/davtest.txt" to "/textfile0.txt" in 2 chunks using the WebDAV API
     And user "Alice" uploads file "filesForUpload/lorem.txt" to "/textfile0.txt" in 3 chunks using the WebDAV API
 #    HTTP status code is different for old (201) and new (204) WebDav API when uploading in chunks
-    Then the HTTP status code of responses on all endpoints should be "<status-code>"
+    Then the HTTP status code of responses on all endpoints should be "201"
     And the version folder of file "/textfile0.txt" for user "Alice" should contain "2" elements
     When user "Alice" restores version index "1" of file "/textfile0.txt" using the WebDAV API
     Then the HTTP status code should be "204"
     And the content of file "/textfile0.txt" for user "Alice" should be "Dav-Test"
-    Examples:
-      | dav-path | status-code |
-      | old      | 201         |
 
   @skipOnStorage:ceph @skipOnStorage:scality
   Scenario: restore a file and check the content and checksum
@@ -381,19 +378,19 @@ Feature: dav-versions
       | permissions | change    |
       | shareWith   | Alice     |
     And user "Alice" has accepted share "/testshare" offered by user "Brian"
-    And user "<mover>" has uploaded file with content "test data 1" to "/testfile.txt"
-    And user "<mover>" has uploaded file with content "test data 2" to "/testfile.txt"
-    And user "<mover>" has uploaded file with content "test data 3" to "/testfile.txt"
-    When user "<mover>" moves file "/testfile.txt" to "<dst-folder>/testfile.txt" using the WebDAV API
+    And user "Brian" has uploaded file with content "test data 1" to "/testfile.txt"
+    And user "Brian" has uploaded file with content "test data 2" to "/testfile.txt"
+    And user "Brian" has uploaded file with content "test data 3" to "/testfile.txt"
+    When user "Brian" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
     And the content of file "/Shares/testshare/testfile.txt" for user "Alice" should be "test data 3"
     And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3"
-    And as "<mover>" file "/testfile.txt" should not exist
+    And as "Brian" file "/testfile.txt" should not exist
     And the version folder of file "/Shares/testshare/testfile.txt" for user "Alice" should contain "2" elements
     Examples:
-      | dav_version | mover | dst-folder        |
-      | old         | Brian | /testshare        |
-      | new         | Brian | /testshare        |
+      | dav_version |
+      | old         |
+      | new         |
 
 
   Scenario Outline: moving a file (with versions) out of a shared folder as the sharee and as the sharer
@@ -409,16 +406,16 @@ Feature: dav-versions
       | permissions | change    |
       | shareWith   | Alice     |
     And user "Alice" has accepted share "/testshare" offered by user "Brian"
-    When user "<mover>" moves file "<src-folder>/testfile.txt" to "/testfile.txt" using the WebDAV API
+    When user "Brian" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
-    And the content of file "/testfile.txt" for user "<mover>" should be "test data 3"
+    And the content of file "/testfile.txt" for user "Brian" should be "test data 3"
     And as "Alice" file "/Shares/testshare/testfile.txt" should not exist
     And as "Brian" file "/testshare/testfile.txt" should not exist
-    And the version folder of file "/testfile.txt" for user "<mover>" should contain "2" elements
+    And the version folder of file "/testfile.txt" for user "Brian" should contain "2" elements
     Examples:
-      | dav_version | mover | src-folder |
-      | old         | Brian | /testshare |
-      | new         | Brian | /testshare |
+      | dav_version |
+      | old         |
+      | new         |
 
 
   Scenario: sharee tries to get file versions of file not shared by the sharer
diff --git a/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature b/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
index ae9620cd1..b0a6062e8 100644
--- a/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
+++ b/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
@@ -37,32 +37,32 @@ Feature: independent locks - make sure all locks are independent and don't inter
   Scenario Outline: locking a file/folder with git specific names does not lock other items with the same name in other parts of the file system
     Given using <dav-path> DAV path
     And user "Alice" has created folder "locked/"
-    And user "Alice" has created folder "locked/<foldername>"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/<foldername>/<filename>"
+    And user "Alice" has created folder "locked/.git"
+    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/.git/config"
     And user "Alice" has created folder "notlocked/"
-    And user "Alice" has created folder "notlocked/<foldername>"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/<foldername>/<filename>"
+    And user "Alice" has created folder "notlocked/"
+    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/.git/config"
     When user "Alice" locks file "locked/<to-lock>" using the WebDAV API setting the following properties
       | lockscope | <lock-scope> |
     Then the HTTP status code should be "200"
-    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/<foldername>/file.txt"
-    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/<foldername>/<filename>"
-    But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/<foldername>/<filename>"
+    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/.git/file.txt"
+    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/.git/config"
+    But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/.git/config"
     Examples:
-      | dav-path | lock-scope | foldername | filename | to-lock     |
-      | old      | shared     | .git       | config   | .git        |
-      | old      | shared     | .git       | config   | .git/config |
-      | old      | exclusive  | .git       | config   | .git        |
-      | old      | exclusive  | .git       | config   | .git/config |
-      | new      | shared     | .git       | config   | .git        |
-      | new      | shared     | .git       | config   | .git/config |
-      | new      | exclusive  | .git       | config   | .git        |
-      | new      | exclusive  | .git       | config   | .git/config |
+      | dav-path | lock-scope | to-lock     |
+      | old      | shared     | .git        |
+      | old      | shared     | .git/config |
+      | old      | exclusive  | .git        |
+      | old      | exclusive  | .git/config |
+      | new      | shared     | .git        |
+      | new      | shared     | .git/config |
+      | new      | exclusive  | .git        |
+      | new      | exclusive  | .git/config |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | foldername | filename | to-lock     |
-      | spaces   | shared     | .git       | config   | .git        |
-      | spaces   | shared     | .git       | config   | .git/config |
-      | spaces   | exclusive  | .git       | config   | .git        |
-      | spaces   | exclusive  | .git       | config   | .git/config |
+      | dav-path | lock-scope | to-lock     |
+      | spaces   | shared     | .git        |
+      | spaces   | shared     | .git/config |
+      | spaces   | exclusive  | .git        |
+      | spaces   | exclusive  | .git/config |
diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
index c19b342cf..9cb4e62f0 100644
--- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
+++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
@@ -18,23 +18,23 @@ Feature: UNLOCK locked items (sharing)
     And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     When user "Brian" unlocks file "Shares/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API
     Then the HTTP status code should be "403"
     And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | old      | shared     | /parent.txt        |
-      | old      | exclusive  | /parent.txt        |
-      | new      | shared     | /parent.txt        |
-      | new      | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | old      | shared     |
+      | old      | exclusive  |
+      | new      | shared     |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | spaces   | shared     | /parent.txt        |
-      | spaces   | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | spaces   | shared     |
+      | spaces   | exclusive  |
 
 
   Scenario Outline: sharee cannot unlock a file within a shared folder when it is locked by the file owner unless the owner lock token is used
@@ -64,7 +64,7 @@ Feature: UNLOCK locked items (sharing)
   Scenario Outline: sharee unlock a shared file
     Given using <dav-path> DAV path
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     And user "Brian" has locked file "Shares/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     When user "Brian" unlocks the last created lock of file "Shares/parent.txt" using the WebDAV API
@@ -72,23 +72,23 @@ Feature: UNLOCK locked items (sharing)
     And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 0 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | old      | shared     | /parent.txt        |
-      | old      | exclusive  | /parent.txt        |
-      | new      | shared     | /parent.txt        |
-      | new      | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | old      | shared     |
+      | old      | exclusive  |
+      | new      | shared     |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | spaces   | shared     | /parent.txt        |
-      | spaces   | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | spaces   | shared     |
+      | spaces   | exclusive  |
 
 
   Scenario Outline: as owner unlocking a shared file locked by the receiver is not possible. To unlock use the receivers locktoken
     Given using <dav-path> DAV path
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     And user "Brian" has locked file "Shares/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "Shares/parent.txt" of user "Brian" using the WebDAV API
@@ -96,17 +96,17 @@ Feature: UNLOCK locked items (sharing)
     And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | old      | shared     | /parent.txt        |
-      | old      | exclusive  | /parent.txt        |
-      | new      | shared     | /parent.txt        |
-      | new      | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | old      | shared     |
+      | old      | exclusive  |
+      | new      | shared     |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
-      | spaces   | shared     | /parent.txt        |
-      | spaces   | exclusive  | /parent.txt        |
+      | dav-path | lock-scope |
+      | spaces   | shared     |
+      | spaces   | exclusive  |
 
 
   Scenario Outline: unlocking a file in a shared folder, which was locked by the sharee is not possible for the owner unless the receiver's locktoken is used
diff --git a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature
index 75ca8f991..9e5203c2b 100644
--- a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature
+++ b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature
@@ -24,16 +24,16 @@ Feature: PROPFIND
     When user "Alice" requests "<dav_path>" with "PROPFIND" using basic auth and with headers
       | header | value   |
       | depth  | <depth> |
-    Then the HTTP status code should be "<http_status>"
+    Then the HTTP status code should be "207"
     Examples:
-      | dav_path                    | depth    | http_status |
-      | /remote.php/dav/files/alice | 0        | 207         |
-      | /remote.php/dav/files/alice | infinity | 207         |
+      | dav_path                    | depth    |
+      | /remote.php/dav/files/alice | 0        |
+      | /remote.php/dav/files/alice | infinity |
     @skipOnRevaMaster
     Examples:
-      | dav_path                         | depth    | http_status |
-      | /remote.php/dav/spaces/%spaceid% | 0        | 207         |
-      | /remote.php/dav/spaces/%spaceid% | infinity | 207         |
+      | dav_path                         | depth    |
+      | /remote.php/dav/spaces/%spaceid% | 0        |
+      | /remote.php/dav/spaces/%spaceid% | infinity |
 
 
   Scenario: send PROPFIND request to a public link