diff --git a/.drone.star b/.drone.star
index 16eea0cc4fb..78e5629a4ac 100644
--- a/.drone.star
+++ b/.drone.star
@@ -18,7 +18,7 @@ OC_CI_PHP = "owncloudci/php:%s"
 OC_CI_WAIT_FOR = "owncloudci/wait-for:latest"
 OC_CS3_API_VALIDATOR = "owncloud/cs3api-validator:0.2.1"
 OC_LITMUS = "owncloudci/litmus:latest"
-OC_OC_TEST_MIDDLEWARE = "owncloud/owncloud-test-middleware:1.8.8"
+OC_OC_TEST_MIDDLEWARE = "owncloud/owncloud-test-middleware:latest"
 OC_UBUNTU = "owncloud/ubuntu:20.04"
 PLUGINS_CODACY = "plugins/codacy:1"
 PLUGINS_DOCKER = "plugins/docker:latest"
diff --git a/changelog/unreleased/change-default-resharing.md b/changelog/unreleased/change-default-resharing.md
new file mode 100644
index 00000000000..19a5f39550c
--- /dev/null
+++ b/changelog/unreleased/change-default-resharing.md
@@ -0,0 +1,5 @@
+Change: Disable resharing by default for deprecation
+
+We disabled the resharing feature by default. This feature will be removed from the product in the next major release. The resharing feature is not recommended for use and should be disabled. Existing reshares will continue to work.
+
+https://github.com/owncloud/ocis/pull/8653
diff --git a/services/frontend/pkg/config/defaults/defaultconfig.go b/services/frontend/pkg/config/defaults/defaultconfig.go
index c38c40f5933..2364191d009 100644
--- a/services/frontend/pkg/config/defaults/defaultconfig.go
+++ b/services/frontend/pkg/config/defaults/defaultconfig.go
@@ -85,7 +85,7 @@ func DefaultConfig() *config.Config {
 		UploadMaxChunkSize:       1e+7,
 		UploadHTTPMethodOverride: "",
 		DefaultUploadProtocol:    "tus",
-		EnableResharing:          true,
+		EnableResharing:          false,
 		DefaultLinkPermissions:   1,
 		SearchMinLength:          3,
 		Edition:                  "Community",
diff --git a/services/graph/pkg/config/defaults/defaultconfig.go b/services/graph/pkg/config/defaults/defaultconfig.go
index df08d4ad7b8..d665b2f206a 100644
--- a/services/graph/pkg/config/defaults/defaultconfig.go
+++ b/services/graph/pkg/config/defaults/defaultconfig.go
@@ -108,7 +108,7 @@ func DefaultConfig() *config.Config {
 			EnableTLS: false,
 		},
 		FilesSharing: config.FilesSharing{
-			EnableResharing: true,
+			EnableResharing: false,
 		},
 	}
 }
diff --git a/services/graph/pkg/service/v0/driveitems_test.go b/services/graph/pkg/service/v0/driveitems_test.go
index 006f503181b..8f087a85c32 100644
--- a/services/graph/pkg/service/v0/driveitems_test.go
+++ b/services/graph/pkg/service/v0/driveitems_test.go
@@ -731,36 +731,37 @@ var _ = Describe("Driveitems", func() {
 			_, ok := res.GetExpirationDateTimeOk()
 			Expect(ok).To(BeFalse())
 		})
-		It("updates the share permissions with changing the role", func() {
-			getPublicShareMockResponse.Share = nil
-			getPublicShareMockResponse.Status = status.NewNotFound(ctx, "not found")
-			updateShareMock := gatewayClient.On("UpdateShare",
-				mock.Anything,
-				mock.MatchedBy(func(req *collaboration.UpdateShareRequest) bool {
-					return req.GetShare().GetId().GetOpaqueId() == "permissionid"
-				}),
-			)
-			updateShareMock.Return(updateShareMockResponse, nil)
-
-			driveItemPermission.SetRoles([]string{unifiedrole.NewViewerUnifiedRole(true).GetId()})
-			body, err := driveItemPermission.MarshalJSON()
-			Expect(err).To(BeNil())
-			svc.UpdatePermission(
-				rr,
-				httptest.NewRequest(http.MethodPatch, "/", strings.NewReader(string(body))).
-					WithContext(ctx),
-			)
-			Expect(rr.Code).To(Equal(http.StatusOK))
-			data, err := io.ReadAll(rr.Body)
-			Expect(err).ToNot(HaveOccurred())
-
-			res := libregraph.Permission{}
-
-			err = json.Unmarshal(data, &res)
-			Expect(err).ToNot(HaveOccurred())
-			_, ok := res.GetRolesOk()
-			Expect(ok).To(BeTrue())
-		})
+		// that is resharing test. Please delete after disable resharing feature
+		
+		// It("updates the share permissions with changing the role", func() {
+		// 	getPublicShareMockResponse.Share = nil
+		// 	getPublicShareMockResponse.Status = status.NewNotFound(ctx, "not found")
+		// 	updateShareMock := gatewayClient.On("UpdateShare",
+		// 		mock.Anything,
+		// 		mock.MatchedBy(func(req *collaboration.UpdateShareRequest) bool {
+		// 			return req.GetShare().GetId().GetOpaqueId() == "permissionid"
+		// 		}),
+		// 	)
+		// 	updateShareMock.Return(updateShareMockResponse, nil)
+		// 	driveItemPermission.SetRoles([]string{unifiedrole.NewViewerUnifiedRole(false).GetId()})
+		// 	body, err := driveItemPermission.MarshalJSON()
+		// 	Expect(err).To(BeNil())
+		// 	svc.UpdatePermission(
+		// 		rr,
+		// 		httptest.NewRequest(http.MethodPatch, "/", strings.NewReader(string(body))).
+		// 			WithContext(ctx),
+		// 	)
+		// 	Expect(rr.Code).To(Equal(http.StatusOK))
+		// 	data, err := io.ReadAll(rr.Body)
+		// 	Expect(err).ToNot(HaveOccurred())
+
+		// 	res := libregraph.Permission{}
+
+		// 	err = json.Unmarshal(data, &res)
+		// 	Expect(err).ToNot(HaveOccurred())
+		// 	_, ok := res.GetRolesOk()
+		// 	Expect(ok).To(BeTrue())
+		// })
 		It("fails to update the share permissions for a file share when setting a space specific role", func() {
 			getPublicShareMockResponse.Share = nil
 			getPublicShareMockResponse.Status = status.NewNotFound(ctx, "not found")
diff --git a/services/graph/pkg/service/v0/sharedwithme_test.go b/services/graph/pkg/service/v0/sharedwithme_test.go
index 3084cf49369..6bafe962639 100644
--- a/services/graph/pkg/service/v0/sharedwithme_test.go
+++ b/services/graph/pkg/service/v0/sharedwithme_test.go
@@ -32,7 +32,7 @@ import (
 	"github.com/owncloud/ocis/v2/services/graph/pkg/errorcode"
 	identitymocks "github.com/owncloud/ocis/v2/services/graph/pkg/identity/mocks"
 	service "github.com/owncloud/ocis/v2/services/graph/pkg/service/v0"
-	"github.com/owncloud/ocis/v2/services/graph/pkg/unifiedrole"
+	// "github.com/owncloud/ocis/v2/services/graph/pkg/unifiedrole"
 )
 
 var _ = Describe("SharedWithMe", func() {
@@ -351,26 +351,28 @@ var _ = Describe("SharedWithMe", func() {
 			Expect(jsonData.Get("file.mimeType").String()).To(Equal(resourceInfo.MimeType))
 		})
 
-		It("populates the driveItem.remoteItem.permissions properties", func() {
-			resourceInfo := statResponse.Info
-			resourceInfo.PermissionSet = roleconversions.NewViewerRole(true).CS3ResourcePermissions()
-
-			svc.ListSharedWithMe(
-				tape,
-				httptest.NewRequest(http.MethodGet, "/graph/v1beta1/me/drive/sharedWithMe", nil),
-			)
-
-			driveitemJSON := gjson.Get(tape.Body.String(), "value.0")
-			Expect(driveitemJSON.Get("@UI\\.Hidden").Exists()).To(BeTrue())
-			Expect(driveitemJSON.Get("@UI\\.Hidden").Bool()).To(BeFalse())
-			Expect(driveitemJSON.Get("@client\\.synchronize").Exists()).To(BeTrue())
-			Expect(driveitemJSON.Get("@client\\.synchronize").Bool()).To(BeTrue())
-
-			permissionsJSON := driveitemJSON.Get("remoteItem.permissions.0")
-			Expect(permissionsJSON.Get("id").String()).To(Equal(listReceivedSharesResponse.Shares[0].Share.Id.OpaqueId))
-			Expect(permissionsJSON.Get("roles.0").String()).To(Equal(unifiedrole.UnifiedRoleViewerID))
-			Expect(permissionsJSON.Get("invitation.invitedBy.user.id").String()).To(Equal(getUserResponseShareCreator.User.Id.OpaqueId))
-		})
+		// that is resharing test. Please delete after disable resharing feature
+		
+		// It("populates the driveItem.remoteItem.permissions properties", func() {
+		// 	resourceInfo := statResponse.Info
+		// 	resourceInfo.PermissionSet = roleconversions.NewViewerRole(false).CS3ResourcePermissions()
+
+		// 	svc.ListSharedWithMe(
+		// 		tape,
+		// 		httptest.NewRequest(http.MethodGet, "/graph/v1beta1/me/drive/sharedWithMe", nil),
+		// 	)
+
+		// 	driveitemJSON := gjson.Get(tape.Body.String(), "value.0")
+		// 	Expect(driveitemJSON.Get("@UI\\.Hidden").Exists()).To(BeTrue())
+		// 	Expect(driveitemJSON.Get("@UI\\.Hidden").Bool()).To(BeFalse())
+		// 	Expect(driveitemJSON.Get("@client\\.synchronize").Exists()).To(BeTrue())
+		// 	Expect(driveitemJSON.Get("@client\\.synchronize").Bool()).To(BeTrue())
+
+		// 	permissionsJSON := driveitemJSON.Get("remoteItem.permissions.0")
+		// 	Expect(permissionsJSON.Get("id").String()).To(Equal(listReceivedSharesResponse.Shares[0].Share.Id.OpaqueId))
+		// 	Expect(permissionsJSON.Get("roles.0").String()).To(Equal(unifiedrole.UnifiedRoleViewerID))
+		// 	Expect(permissionsJSON.Get("invitation.invitedBy.user.id").String()).To(Equal(getUserResponseShareCreator.User.Id.OpaqueId))
+		// })
 
 		It("returns shares created on project space", func() {
 			ownerID := &userv1beta1.UserId{
diff --git a/services/sharing/pkg/config/defaults/defaultconfig.go b/services/sharing/pkg/config/defaults/defaultconfig.go
index 20d86a739a4..6f0994fa2f5 100644
--- a/services/sharing/pkg/config/defaults/defaultconfig.go
+++ b/services/sharing/pkg/config/defaults/defaultconfig.go
@@ -35,7 +35,7 @@ func DefaultConfig() *config.Config {
 			Name: "sharing",
 		},
 		Reva:              shared.DefaultRevaConfig(),
-		EnableResharing:   true,
+		EnableResharing:   false,
 		UserSharingDriver: "jsoncs3",
 		UserSharingDrivers: config.UserSharingDrivers{
 			JSON: config.UserSharingJSONDriver{
diff --git a/tests/TestHelpers/SharingHelper.php b/tests/TestHelpers/SharingHelper.php
index 0d35f858cda..07a2e74f53a 100644
--- a/tests/TestHelpers/SharingHelper.php
+++ b/tests/TestHelpers/SharingHelper.php
@@ -39,7 +39,6 @@ class SharingHelper {
 		'update' => 2,
 		'create' => 4,
 		'delete' => 8,
-		'share' => 16,
 		'invite' => 0
 	];
 
@@ -123,6 +122,9 @@ public static function createShare(
 
 		if ($permissions !== null) {
 			$fd['permissions'] = self::getPermissionSum($permissions);
+		} elseif ($shareType !== "public_link") {
+			// sharing without permissions should automatically set the permission to 15 for share and 1 for public link
+			$fd['permissions'] = 15;
 		}
 
 		if (!\in_array($ocsApiVersion, [1, 2], true)) {
diff --git a/tests/acceptance/config/behat-core.yml b/tests/acceptance/config/behat-core.yml
index 9625eb63fb9..3808e0a13f3 100644
--- a/tests/acceptance/config/behat-core.yml
+++ b/tests/acceptance/config/behat-core.yml
@@ -145,26 +145,6 @@ default:
         - WebDavPropertiesContext:
         - OcisConfigContext:
 
-    coreApiShareReshareToShares1:
-      paths:
-        - "%paths.base%/../features/coreApiShareReshareToShares1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-
-    coreApiShareReshareToShares2:
-      paths:
-        - "%paths.base%/../features/coreApiShareReshareToShares2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-
     coreApiShareUpdateToShares:
       paths:
         - "%paths.base%/../features/coreApiShareUpdateToShares"
diff --git a/tests/acceptance/expected-failures-API-on-OCIS-storage.md b/tests/acceptance/expected-failures-API-on-OCIS-storage.md
index ab82567b2ea..87e4105e6f3 100644
--- a/tests/acceptance/expected-failures-API-on-OCIS-storage.md
+++ b/tests/acceptance/expected-failures-API-on-OCIS-storage.md
@@ -71,14 +71,6 @@ File and sync features in a shared scenario
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:159](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L159)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:160](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L160)
 
-#### [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:654](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L654)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:655](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L655)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:672](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L672)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:673](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L673)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:687](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L687)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:688](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L688)
 
 #### [file_target of an auto-renamed file is not correct directly after sharing](https://github.com/owncloud/core/issues/32322)
 
@@ -133,29 +125,13 @@ cannot share a folder with create permission
 - [coreApiTrashbin/trashbinSharingToShares.feature:201](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature#L201)
 - [coreApiTrashbin/trashbinSharingToShares.feature:224](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature#L224)
 
-#### [Expiration date for shares is not implemented](https://github.com/owncloud/ocis/issues/1250)
-
-#### Expiration date of user shares
-
-- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:33](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L33)
-- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:34](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L34)
-
-#### Expiration date of group shares
-
-- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:56](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L56)
-- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:57](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L57)
-
-#### [Cannot move folder/file from one received share to another](https://github.com/owncloud/ocis/issues/2442)
-
-- [coreApiShareUpdateToShares/updateShare.feature:124](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L124)
-- [coreApiShareUpdateToShares/updateShare.feature:154](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L154)
 
 #### [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:213](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L213)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:239](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L239)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:324](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L324)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:350](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L350)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:292](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L292)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:318](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L318)
 
 #### [Empty OCS response for a share create request using a disabled user](https://github.com/owncloud/ocis/issues/2212)
 
@@ -164,13 +140,13 @@ cannot share a folder with create permission
 
 #### [Edit user share response has a "name" field](https://github.com/owncloud/ocis/issues/1225)
 
-- [coreApiShareUpdateToShares/updateShare.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L227)
-- [coreApiShareUpdateToShares/updateShare.feature:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L228)
+- [coreApiShareUpdateToShares/updateShare.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L161)
+- [coreApiShareUpdateToShares/updateShare.feature:162](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L162)
 
 #### [Share lists deleted user as 'user'](https://github.com/owncloud/ocis/issues/903)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:594](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L594)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:595](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L595)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:544](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L544)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:545](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L545)
 
 #### [deleting a share with wrong authentication returns OCS status 996 / HTTP 500](https://github.com/owncloud/ocis/issues/1229)
 
@@ -278,8 +254,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:638](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L638)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:639](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L639)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:588](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L588)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:589](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L589)
 
 #### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
 
diff --git a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
index b6f7712335e..61ee78e703c 100644
--- a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
+++ b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
@@ -24,8 +24,8 @@ The expected failures in this file are from features in the owncloud/ocis repo.
 
 ### [Shared mount folder gets deleted when overwritten by a file from personal space](https://github.com/owncloud/ocis/issues/7208)
 
-- [apiSpacesShares/copySpaces.feature:510](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L510)
-- [apiSpacesShares/copySpaces.feature:523](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L523)
+- [apiSpacesShares/copySpaces.feature:512](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L512)
+- [apiSpacesShares/copySpaces.feature:525](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L525)
 
 #### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
 
@@ -285,5 +285,11 @@ The expected failures in this file are from features in the owncloud/ocis repo.
 - [apiSpacesDavOperation/moveByFileId.feature:464](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L464)
 - [apiSpacesDavOperation/moveByFileId.feature:465](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L465)
 
+### [Delete resharing tests ](https://github.com/owncloud/ocis/pull/8704)
+- [apiSpacesShares/shareSubItemOfSpace.feature:119](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L119)
+- [apiSpacesShares/shareSubItemOfSpace.feature:132](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L132)
+- [apiSpacesShares/shareSubItemOfSpace.feature:145](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L145)
+- [apiSpacesShares/shareSubItemOfSpace.feature:156](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L156)
+
 - Note: always have an empty line at the end of this file.
   The bash script that processes this file requires that the last line has a newline on the end.
diff --git a/tests/acceptance/features/apiContract/sharesReport.feature b/tests/acceptance/features/apiContract/sharesReport.feature
index 3a4b5bfca5f..2fe62b77b19 100644
--- a/tests/acceptance/features/apiContract/sharesReport.feature
+++ b/tests/acceptance/features/apiContract/sharesReport.feature
@@ -11,7 +11,7 @@ Feature: REPORT request to Shares space
     And user "Alice" has created folder "/folderMain"
     And user "Alice" has created folder "/folderMain/SubFolder1"
     And user "Alice" has created folder "/folderMain/SubFolder1/subFOLDER2"
-    And user "Alice" has shared entry "/folderMain" with user "Brian" with permissions "17"
+    And user "Alice" has shared entry "/folderMain" with user "Brian" with permissions "1"
 
 
   Scenario Outline: check the REPORT response of the found folder
@@ -60,7 +60,7 @@ Feature: REPORT request to Shares space
     Given user "Brian" has disabled auto-accepting
     And using <dav-path-version> DAV path
     And user "Alice" has created folder "/folderToBrian"
-    And user "Alice" has shared entry "/folderToBrian" with user "Brian" with permissions "17"
+    And user "Alice" has shared entry "/folderToBrian" with user "Brian" with permissions "1"
     When user "Brian" searches for "folderToBrian" using the WebDAV API
     Then the HTTP status code should be "207"
     And the following headers should match these regular expressions
diff --git a/tests/acceptance/features/apiGraph/userGDPRExport.feature b/tests/acceptance/features/apiGraph/userGDPRExport.feature
index d925a3c28e6..c1c2e11cebb 100644
--- a/tests/acceptance/features/apiGraph/userGDPRExport.feature
+++ b/tests/acceptance/features/apiGraph/userGDPRExport.feature
@@ -625,7 +625,6 @@ Feature: user GDPR (General Data Protection Regulation) report
                 "permissions": {
                   "type": "object",
                   "required": [
-                    "add_grant",
                     "get_path",
                     "get_quota",
                     "initiate_file_download",
@@ -634,10 +633,6 @@ Feature: user GDPR (General Data Protection Regulation) report
                     "stat"
                   ],
                   "properties": {
-                    "add_grant" : {
-                      "type": "boolean",
-                      "enum": [true]
-                    },
                     "get_path" : {
                       "type": "boolean",
                       "enum": [true]
diff --git a/tests/acceptance/features/apiNotification/emailNotification.feature b/tests/acceptance/features/apiNotification/emailNotification.feature
index 9c1f231391f..b8c1bf5a73d 100644
--- a/tests/acceptance/features/apiNotification/emailNotification.feature
+++ b/tests/acceptance/features/apiNotification/emailNotification.feature
@@ -30,7 +30,7 @@ Feature: Email notification
 
   Scenario: user gets an email notification when someone shares a file
     Given user "Alice" has uploaded file with content "sample text" to "lorem.txt"
-    When user "Alice" shares file "lorem.txt" with user "Brian" with permissions "17" using the sharing API
+    When user "Alice" shares file "lorem.txt" with user "Brian" using the sharing API
     Then the HTTP status code should be "200"
     And the OCS status code should be "100"
     And user "Brian" should have received the following email from user "Alice"
diff --git a/tests/acceptance/features/apiNotification/notification.feature b/tests/acceptance/features/apiNotification/notification.feature
index c6a55ca7d2b..087bf0d35bb 100644
--- a/tests/acceptance/features/apiNotification/notification.feature
+++ b/tests/acceptance/features/apiNotification/notification.feature
@@ -242,7 +242,7 @@ Feature: Notification
 
   Scenario Outline: get a notification about a file share in various languages
     Given user "Brian" has switched the system language to "<language>" using the <api> API
-    And user "Alice" has shared entry "textfile1.txt" with user "Brian" with permissions "17"
+    And user "Alice" has shared entry "textfile1.txt" with user "Brian"
     When user "Brian" lists all notifications
     Then the HTTP status code should be "200"
     And the JSON response should contain a notification message with the subject "<subject>" and the message-details should match
@@ -272,7 +272,7 @@ Feature: Notification
   @env-config
   Scenario: get a notification about a file share in default languages
     Given the config "OCIS_DEFAULT_LANGUAGE" has been set to "de"
-    And user "Alice" has shared entry "textfile1.txt" with user "Brian" with permissions "17"
+    And user "Alice" has shared entry "textfile1.txt" with user "Brian"
     When user "Brian" lists all notifications
     Then the HTTP status code should be "200"
     And the JSON response should contain a notification message with the subject "Neue Freigabe" and the message-details should match
diff --git a/tests/acceptance/features/apiReshare/disableReshare.feature b/tests/acceptance/features/apiReshare/disableReshare.feature
deleted file mode 100644
index 733999c52b1..00000000000
--- a/tests/acceptance/features/apiReshare/disableReshare.feature
+++ /dev/null
@@ -1,57 +0,0 @@
-@env-config
-Feature: share by disabling re-share
-  As a user
-  I want to share resources
-  So that other users can have access to them but cannot re-share them
-
-  Background:
-    Given the config "FRONTEND_ENABLE_RESHARING" has been set to "false"
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has created folder "test"
-
-
-  Scenario Outline: share folder with different roles
-    Given using <dav-path-version> DAV path
-    When user "Alice" creates a share inside of space "Personal" with settings:
-      | path      | test   |
-      | shareWith | Brian  |
-      | role      | <role> |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "200"
-    And the fields of the last response to user "Alice" sharing with user "Brian" should include
-      | permissions | <expected-permissions> |
-    Examples:
-      | dav-path-version | role   | expected-permissions |
-      | old              | editor | 15                   |
-      | old              | viewer | 1                    |
-      | new              | editor | 15                   |
-      | new              | viewer | 1                    |
-      | spaces           | editor | 15                   |
-      | spaces           | viewer | 1                    |
-
-
-  Scenario Outline: try to re-share folder
-    Given using <dav-path-version> DAV path
-    And user "Carol" has been created with default attributes and without skeleton files
-    And user "Alice" has created a share inside of space "Personal" with settings:
-      | path      | test   |
-      | shareWith | Brian  |
-      | role      | <role> |
-    When user "Brian" creates a share inside of space "Shares" with settings:
-      | path      | test   |
-      | shareWith | Carol  |
-      | role      | <role> |
-    Then the HTTP status code should be "403"
-    And the OCS status code should be "403"
-    And the OCS status message should be "No share permission"
-    Examples:
-      | dav-path-version | role   |
-      | old              | editor |
-      | old              | viewer |
-      | new              | editor |
-      | new              | viewer |
-      | spaces           | editor |
-      | spaces           | viewer |
diff --git a/tests/acceptance/features/apiReshare/resharing.feature b/tests/acceptance/features/apiReshare/resharing.feature
index ae19ae26a6a..23ae0c42a2e 100644
--- a/tests/acceptance/features/apiReshare/resharing.feature
+++ b/tests/acceptance/features/apiReshare/resharing.feature
@@ -1,10 +1,7 @@
-Feature: Resharing
+Feature: re-share resources
   As a user
-  I want to reshare resources
-  So that other users can have access to them
-
-  Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production
-  See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839
+  I cannot to re-share resources
+  This feature has been removed from ocis
 
   Background:
     Given these users have been created with default attributes and without skeleton files:
@@ -12,109 +9,87 @@ Feature: Resharing
       | Alice    |
       | Brian    |
       | Carol    |
-      | Damian   |
-      | Ember    |
-      | Fred     |
-      | Gina     |
-    And user "Alice" has created folder "folder"
-    And user "Alice" has shared folder "folder" with user "Brian" with permissions "31"
-    And user "Brian" has shared folder "Shares/folder" with user "Carol" with permissions "31"
-    And user "Carol" has shared folder "Shares/folder" with user "Damian" with permissions "17"
-
-
-  Scenario Outline: user should only be able to see direct outgoing shares not all the chain
-    Given user "Brian" has shared folder "Shares/folder" with user "Fred" with permissions "17"
-    When user "<user>" gets all the shares inside the folder "Shares/folder" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the response should contain <visible-shares-no> entries
-    And user "Brian" should not be included in the response
-    And user "Carol" <carol-visible> included in the response
-    And user "Damian" <damian-visible> included in the response
-    And user "Fred" <fred-visible> included in the response
-    Examples:
-      | user   | visible-shares-no | carol-visible | damian-visible | fred-visible  |
-      | Brian  | 2                 | should be     | should not be  | should be     |
-      | Carol  | 1                 | should not be | should be      | should not be |
-      | Damian | 0                 | should not be | should not be  | should not be |
-      | Fred   | 0                 | should not be | should not be  | should not be |
+    And user "Alice" has created folder "test"
 
 
-  Scenario: owners can see all the chain
-    When user "Alice" gets all the shares inside the folder "folder" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the response should contain 3 entries
-    And user "Brian" should be included in the response
-    And user "Carol" should be included in the response
-    And user "Damian" should be included in the response
-
-  @skipOnRevaMaster
-  Scenario: user can't share with more permissions than they have
-    When user "Damian" shares folder "Shares/folder" with user "Ember" with permissions "31" using the sharing API
-    Then the OCS status code should be "403"
-    And the OCS status message should be "Cannot set the requested share permissions"
-
-
-  Scenario Outline: editing reshares
-    Given user "Carol" has shared folder "Shares/folder" with user "Fred" with permissions "17"
-    When user "<user>" updates the last share using the sharing API with
-      | permissions | 31 |
-    Then the OCS status code should be "<ocs-status-code>"
-    And user "Fred" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
+  Scenario Outline: share folder with different roles
+    Given using <dav-path-version> DAV path
+    When user "Alice" creates a share inside of space "Personal" with settings:
+      | path      | test   |
+      | shareWith | Brian  |
+      | role      | <role> |
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "200"
+    And the fields of the last response to user "Alice" sharing with user "Brian" should include
+      | permissions | <expected-permissions> |
     Examples:
-      | user  | ocs-status-code | can-upload    |
-      | Alice | 100             | should be     |
-      | Brian | 998             | should not be |
-      | Carol | 100             | should be     |
+      | dav-path-version | role   | expected-permissions |
+      | old              | editor | 15                   |
+      | old              | viewer | 1                    |
+      | new              | editor | 15                   |
+      | new              | viewer | 1                    |
+      | spaces           | editor | 15                   |
+      | spaces           | viewer | 1                    |
 
 
-  Scenario Outline: deleting reshares
-    Given user "Carol" has shared folder "Shares/folder" with user "Gina" with permissions "17"
-    When user "<user>" deletes the last share using the sharing API
-    Then the OCS status code should be "<ocs-status-code>"
-    And as "Gina" folder "Shares/folder" <exists>
-    And as "Carol" folder "Shares/folder" should exist
+  Scenario Outline: try to re-share folder
+    Given using <dav-path-version> DAV path
+    And user "Alice" has created a share inside of space "Personal" with settings:
+      | path      | test   |
+      | shareWith | Brian  |
+      | role      | <role> |
+    When user "Brian" creates a share inside of space "Shares" with settings:
+      | path      | test   |
+      | shareWith | Carol  |
+      | role      | <role> |
+    Then the HTTP status code should be "403"
+    And the OCS status code should be "403"
+    And the OCS status message should be "No share permission"
     Examples:
-      | user  | ocs-status-code | exists           |
-      | Alice | 100             | should not exist |
-      | Brian | 998             | should exist     |
-      | Carol | 100             | should not exist |
+      | dav-path-version | role   |
+      | old              | editor |
+      | old              | viewer |
+      | new              | editor |
+      | new              | viewer |
+      | spaces           | editor |
+      | spaces           | viewer |
 
-  @skipOnRevaMaster
-  Scenario Outline: resharing folder with different permissions
-    When user "<user>" shares folder "Shares/folder" with user "Ember" with permissions "<sharee-permissions>" using the sharing API
-    Then the OCS status code should be "<ocs-status-code>"
-    Examples:
-      | user   | sharee-permissions | ocs-status-code |
-      | Brian  | 17                 | 100             |
-      | Carol  | 31                 | 100             |
-      | Damian | 17                 | 100             |
-      | Damian | 27                 | 403             |
-      | Damian | 31                 | 403             |
 
-  @skipOnRevaMaster
-  Scenario Outline: Resharing files with different permissions
-    Given user "Alice" has uploaded file with content "Random data" to "/file.txt"
-    And user "Alice" has shared file "/file.txt" with user "Brian" with permissions "<sharee-permissions>"
-    When user "Brian" shares file "Shares/file.txt" with user "Fred" with permissions "<grantee-permissions>" using the sharing API
-    Then the OCS status code should be "<ocs-status-code>"
+  Scenario Outline: try to re-share file
+    Given user "Alice" has uploaded file with content "other data" to "/textfile1.txt"
+    Given using <dav-path-version> DAV path
+    And user "Alice" has created a share inside of space "Personal" with settings:
+      | path      | textfile1.txt |
+      | shareWith | Brian         |
+      | role      | <role>        |
+    When user "Brian" creates a share inside of space "Shares" with settings:
+      | path      | textfile1.txt |
+      | shareWith | Carol         |
+      | role      | <role>        |
+    Then the HTTP status code should be "403"
+    And the OCS status code should be "403"
+    And the OCS status message should be "No share permission"
     Examples:
-      | sharee-permissions | grantee-permissions | ocs-status-code |
-      | 17                 | 17                  | 100             |
-      | 17                 | 19                  | 403             |
-      | 19                 | 19                  | 100             |
+      | dav-path-version | role   |
+      | old              | editor |
+      | old              | viewer |
+      | new              | editor |
+      | new              | viewer |
+      | spaces           | editor |
+      | spaces           | viewer |
 
 
-  Scenario Outline: resharing with group with different permissions
-    Given group "security department" has been created
-    And the administrator has added a user "Ember" to the group "security department" using the Graph API
-    And the administrator has added a user "Fred" to the group "security department" using the Graph API
-    When user "Brian" shares folder "Shares/folder" with group "security department" with permissions "<sharee-permissions>" using the sharing API
-    Then the OCS status code should be "100"
-    And user "Ember" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
-    And user "Fred" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
+  Scenario Outline: try to create a link to the shared folder
+    Given using OCS API version "<ocs_api_version>"
+    And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
+    When user "Brian" creates a public link share using the sharing API with settings
+      | path        | /Shares/test |
+      | permissions | 1            |
+      | password    | %public%     |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "<http_status_code>"
     Examples:
-      | sharee-permissions | can-upload    |
-      | 17                 | should not be |
-      | 31                 | should be     |
+      | ocs_api_version | ocs_status_code | http_status_code |
+      | 1               | 403             | 200              |
+      | 2               | 403             | 403              |
+      
\ No newline at end of file
diff --git a/tests/acceptance/features/apiSharingNg/propfindShares.feature b/tests/acceptance/features/apiSharingNg/propfindShares.feature
index 6351e72d31e..1b9aaf3a7c6 100644
--- a/tests/acceptance/features/apiSharingNg/propfindShares.feature
+++ b/tests/acceptance/features/apiSharingNg/propfindShares.feature
@@ -37,11 +37,11 @@ Feature: propfind a shares
     And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
       | key            | value      |
       | oc:name        | <resource> |
-      | oc:permissions | SR         |
+      | oc:permissions | S          |
     And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
       | key            | value        |
       | oc:name        | <resource-2> |
-      | oc:permissions | SR           |
+      | oc:permissions | S            |
     Examples:
       | resource      | resource-2        |
       | textfile.txt  | textfile (1).txt  |
@@ -76,12 +76,12 @@ Feature: propfind a shares
       | key            | value             |
       | oc:fileid      | UUIDof:<resource> |
       | oc:name        | <resource>        |
-      | oc:permissions | SR                |
+      | oc:permissions | S                 |
     And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
       | key            | value               |
       | oc:fileid      | UUIDof:<resource-2> |
       | oc:name        | <resource-2>        |
-      | oc:permissions | SR                  |
+      | oc:permissions | S                   |
     Examples:
       | dav-path-version | resource      | resource-2        |
       | old              | textfile.txt  | textfile (1).txt  |
@@ -114,9 +114,9 @@ Feature: propfind a shares
       | key            | value                    |
       | oc:fileid      | UUIDof:folderToShare (1) |
       | oc:name        | folderToShare            |
-      | oc:permissions | SR                       |
+      | oc:permissions | S                        |
     And the "PROPFIND" response to user "Brian" should contain a mountpoint "folderToShare (1)" with these key and value pairs:
       | key            | value               |
       | oc:fileid      | UUIDof:textfile.txt |
       | oc:name        | textfile.txt        |
-      | oc:permissions | SR                  |
+      | oc:permissions | S                   |
diff --git a/tests/acceptance/features/apiSharingNg/shareInvitations.feature b/tests/acceptance/features/apiSharingNg/shareInvitations.feature
index df1decf2697..7e08cf5f95c 100644
--- a/tests/acceptance/features/apiSharingNg/shareInvitations.feature
+++ b/tests/acceptance/features/apiSharingNg/shareInvitations.feature
@@ -271,7 +271,6 @@ Feature: Send a sharing invitations
       """
     Examples:
       | permissions-action |
-      | permissions/create |
       | upload/create      |
       | path/read          |
       | quota/read         |
@@ -283,10 +282,7 @@ Feature: Send a sharing invitations
       | basic/read         |
       | versions/update    |
       | deleted/update     |
-      | permissions/update |
-      | permissions/delete |
       | deleted/delete     |
-      | permissions/deny   |
 
 
   Scenario Outline: send share invitation for a folder to user with different permissions
@@ -366,7 +362,6 @@ Feature: Send a sharing invitations
       """
     Examples:
       | permissions-action |
-      | permissions/create |
       | children/create    |
       | upload/create      |
       | path/read          |
@@ -380,11 +375,8 @@ Feature: Send a sharing invitations
       | path/update        |
       | versions/update    |
       | deleted/update     |
-      | permissions/update |
       | standard/delete    |
-      | permissions/delete |
       | deleted/delete     |
-      | permissions/deny   |
 
 
   Scenario Outline: send share invitation for a file to group with different permissions
@@ -470,7 +462,6 @@ Feature: Send a sharing invitations
       """
     Examples:
       | permissions-action |
-      | permissions/create |
       | upload/create      |
       | path/read          |
       | quota/read         |
@@ -482,10 +473,7 @@ Feature: Send a sharing invitations
       | basic/read         |
       | versions/update    |
       | deleted/update     |
-      | permissions/update |
-      | permissions/delete |
       | deleted/delete     |
-      | permissions/deny   |
 
 
   Scenario Outline: send share invitation for a folder to group with different permissions
@@ -571,7 +559,6 @@ Feature: Send a sharing invitations
       """
     Examples:
       | permissions-action |
-      | permissions/create |
       | children/create    |
       | upload/create      |
       | path/read          |
@@ -585,11 +572,8 @@ Feature: Send a sharing invitations
       | path/update        |
       | versions/update    |
       | deleted/update     |
-      | permissions/update |
       | standard/delete    |
-      | permissions/delete |
       | deleted/delete     |
-      | permissions/deny   |
 
 
   Scenario Outline: send share invitation with expiration date to user with different roles
@@ -2375,4 +2359,33 @@ Feature: Send a sharing invitations
       | Space Viewer     | space type is not eligible for sharing                                                             |
       | Space Editor     | space type is not eligible for sharing                                                             |
       | Manager          | space type is not eligible for sharing                                                             |
-      | Co Owner         | Key: 'DriveItemInvite.Roles' Error:Field validation for 'Roles' failed on the 'available_role' tag |
\ No newline at end of file
+      | Co Owner         | Key: 'DriveItemInvite.Roles' Error:Field validation for 'Roles' failed on the 'available_role' tag |
+
+
+  Scenario Outline: try to send share invitation with re-sharing permissions
+    Given group "grp1" has been created
+    And user "Alice" has created folder "FolderToShare"
+    And the following users have been added to the following groups
+      | username | groupname |
+      | Brian    | grp1      |
+    And user "Alice" has uploaded file with content "to share" to "textfile1.txt"
+    When user "Alice" sends the following share invitation using the Graph API:
+      | resource          | textfile1.txt        |
+      | space             | Personal             |
+      | sharee            | grp1                 |
+      | shareType         | group                |
+      | permissionsAction | <permissions-action> |
+    Then the HTTP status code should be "400" 
+    When user "Alice" sends the following share invitation using the Graph API:
+      | resource          | FolderToShare        |
+      | space             | Personal             |
+      | sharee            | Brian                |
+      | shareType         | user                 |
+      | permissionsAction | <permissions-action> |
+    Then the HTTP status code should be "400" 
+    Examples:
+      | permissions-action |
+      | permissions/create |
+      | permissions/update |
+      | permissions/delete |
+      | permissions/deny   |
diff --git a/tests/acceptance/features/apiSpaces/listSpaces.feature b/tests/acceptance/features/apiSpaces/listSpaces.feature
index 50b3456cabe..fecec9ef5cd 100644
--- a/tests/acceptance/features/apiSpaces/listSpaces.feature
+++ b/tests/acceptance/features/apiSpaces/listSpaces.feature
@@ -80,7 +80,7 @@ Feature: List and create spaces
   Scenario: ordinary user can request information about their Space via the Graph API using a filter
     Given user "Brian" has been created with default attributes and without skeleton files
     And user "Brian" has created folder "folder"
-    And user "Brian" has shared folder "folder" with user "Alice" with permissions "31"
+    And user "Brian" has shared folder "folder" with user "Alice" with permissions "15"
     When user "Alice" lists all available spaces via the Graph API with query "$filter=driveType eq 'personal'"
     Then the HTTP status code should be "200"
     And the JSON response should contain space called "Alice Hansen" and match
diff --git a/tests/acceptance/features/apiSpaces/tag.feature b/tests/acceptance/features/apiSpaces/tag.feature
index 8e9ecbd4000..8622564fc87 100644
--- a/tests/acceptance/features/apiSpaces/tag.feature
+++ b/tests/acceptance/features/apiSpaces/tag.feature
@@ -136,10 +136,8 @@ Feature: Tag
       | space-role | resource-type | resource                       | http-status-code | should-or-not |
       | viewer     | file          | folderMain/insideTheFolder.txt | 403              | should not    |
       | editor     | file          | folderMain/insideTheFolder.txt | 200              | should        |
-      | manager    | file          | folderMain/insideTheFolder.txt | 200              | should        |
       | viewer     | folder        | folderMain                     | 403              | should not    |
       | editor     | folder        | folderMain                     | 200              | should        |
-      | manager    | folder        | folderMain                     | 200              | should        |
 
 
   Scenario Outline: recipient of the shared resource tries to remove a tag
@@ -163,10 +161,8 @@ Feature: Tag
       | space-role | resource-type | resource                       | http-status-code | should-or-not |
       | viewer     | file          | folderMain/insideTheFolder.txt | 403              | should        |
       | editor     | file          | folderMain/insideTheFolder.txt | 200              | should not    |
-      | manager    | file          | folderMain/insideTheFolder.txt | 200              | should not    |
       | viewer     | folder        | folderMain                     | 403              | should        |
       | editor     | folder        | folderMain                     | 200              | should not    |
-      | manager    | folder        | folderMain                     | 200              | should not    |
 
 
   Scenario: user removes folder tags
diff --git a/tests/acceptance/features/apiSpacesDavOperation/fileVersionByFileID.feature b/tests/acceptance/features/apiSpacesDavOperation/fileVersionByFileID.feature
index 2e252ea279b..601305acac8 100644
--- a/tests/acceptance/features/apiSpacesDavOperation/fileVersionByFileID.feature
+++ b/tests/acceptance/features/apiSpacesDavOperation/fileVersionByFileID.feature
@@ -18,19 +18,18 @@ Feature: checking file versions using file id
 
   Scenario Outline: check the file versions of a file shared from project space
     Given user "Alice" has created a share inside of space "Project1" with settings:
-      | path      | text.txt     |
-      | shareWith | Brian        |
-      | role      | <space-role> |
+      | path      | text.txt |
+      | shareWith | Brian    |
+      | role      | <role>   |
     When user "Alice" gets the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
     Then the HTTP status code should be "207"
     And the number of versions should be "1"
     When user "Brian" tries to get the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
     Then the HTTP status code should be "403"
     Examples:
-      | space-role |
-      | editor     |
-      | viewer     |
-      | all        |
+      | role   |
+      | editor |
+      | viewer |
 
 
   Scenario Outline: check the versions of a file in a shared space as editor/manager
@@ -60,9 +59,9 @@ Feature: checking file versions using file id
   Scenario Outline: check the versions of a file after moving to a shared folder inside a project space as editor/viewer
     Given user "Alice" has created a folder "testFolder" in space "Project1"
     And user "Alice" has created a share inside of space "Project1" with settings:
-      | path      | testFolder   |
-      | shareWith | Brian        |
-      | role      | <space-role> |
+      | path      | testFolder |
+      | shareWith | Brian      |
+      | role      | <role>     |
     And user "Alice" has moved file "text.txt" to "/testFolder/movedText.txt" in space "Project1"
     When user "Alice" gets the number of versions of file "/testFolder/movedText.txt" using file-id path "/meta/<<FILEID>>/v"
     Then the HTTP status code should be "207"
@@ -70,17 +69,19 @@ Feature: checking file versions using file id
     When user "Brian" tries to get the number of versions of file "/Shares/testFolder/movedText.txt" using file-id path "/meta/<<FILEID>>/v"
     Then the HTTP status code should be "403"
     Examples:
-      | space-role |
-      | editor     |
-      | viewer     |
+      | role   |
+      | editor |
+      | viewer |
 
   @issue-7738
-  Scenario: check the versions of a file after moving it to a shared folder of a project space shared with all permissions
+  Scenario: check the versions of a file after moving it to a shared folder inside a project space as manager
     Given user "Alice" has created a folder "testFolder" in space "Project1"
     And user "Alice" has created a share inside of space "Project1" with settings:
       | path      | testFolder |
       | shareWith | Brian      |
-      | role      | all        |
+    And user "Alice" has shared a space "Project1" with settings:
+      | shareWith | Brian   |
+      | role      | manager |
     And user "Alice" has moved file "text.txt" to "/testFolder/movedText.txt" in space "Project1"
     When user "Brian" gets the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
     Then the HTTP status code should be "207"
diff --git a/tests/acceptance/features/apiSpacesDavOperation/propfindByFileId.feature b/tests/acceptance/features/apiSpacesDavOperation/propfindByFileId.feature
index c29976af9c2..9ea1ae80b9c 100644
--- a/tests/acceptance/features/apiSpacesDavOperation/propfindByFileId.feature
+++ b/tests/acceptance/features/apiSpacesDavOperation/propfindByFileId.feature
@@ -110,7 +110,7 @@ Feature: propfind a file using file id
     And the "PROPFIND" response to user "Alice" should contain a mountpoint "Brian Murphy" with these key and value pairs:
       | key            | value        |
       | oc:name        | textfile.txt |
-      | oc:permissions | SRNVW        |
+      | oc:permissions | SNVW         |
     Examples:
       | dav-path                          |
       | /remote.php/dav/spaces/<<FILEID>> |
@@ -128,7 +128,7 @@ Feature: propfind a file using file id
     And the "PROPFIND" response to user "Alice" should contain a mountpoint "Brian Murphy" with these key and value pairs:
       | key            | value        |
       | oc:name        | textfile.txt |
-      | oc:permissions | RDNVWZP      |
+      | oc:permissions | DNVW         |
     Examples:
       | dav-path                          |
       | /remote.php/dav/spaces/<<FILEID>> |
diff --git a/tests/acceptance/features/apiSpacesShares/copySpaces.feature b/tests/acceptance/features/apiSpacesShares/copySpaces.feature
index af235737709..fcea6b8517a 100644
--- a/tests/acceptance/features/apiSpacesShares/copySpaces.feature
+++ b/tests/acceptance/features/apiSpacesShares/copySpaces.feature
@@ -116,7 +116,9 @@ Feature: copy file
     And user "Brian" has shared a space "Project" with settings:
       | shareWith | Alice        |
       | role      | <space-role> |
-    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31"
+    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "15"
+      | shareWith | Alice  |
+      | role      | <role> |
     When user "Alice" copies file "/project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "201"
     And for user "Alice" folder "testshare" of the space "Shares" should contain these files:
@@ -137,7 +139,7 @@ Feature: copy file
     And user "Brian" has shared a space "Project" with settings:
       | shareWith | Alice        |
       | role      | <space-role> |
-    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17"
+    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "1"
     When user "Alice" copies file "/project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "403"
     And for user "Alice" folder "testshare" of the space "Shares" should not contain these files:
@@ -182,7 +184,7 @@ Feature: copy file
 
   Scenario: user copies a file from personal space to share space with role editor
     Given user "Brian" has created folder "/testshare"
-    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31"
+    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "15"
     And user "Alice" has uploaded file with content "personal content" to "personal.txt"
     When user "Alice" copies file "/personal.txt" from space "Personal" to "/testshare/personal.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "201"
@@ -193,7 +195,7 @@ Feature: copy file
 
   Scenario: user copies a file from personal space to share space with role viewer
     Given user "Brian" has created folder "/testshare"
-    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17"
+    And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "1"
     And user "Alice" has uploaded file with content "personal content" to "/personal.txt"
     When user "Alice" copies file "/personal.txt" from space "Personal" to "/testshare/personal.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "403"
@@ -213,8 +215,8 @@ Feature: copy file
     And for user "Alice" the content of the file "/testshare.txt" of the space "Personal" should be "testshare content"
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario Outline: user copies a file from share space with different role to project space with different role
@@ -233,10 +235,10 @@ Feature: copy file
     And for user "Alice" the content of the file "/testshare.txt" of the space "Project" should be "testshare content"
     Examples:
       | space-role | permissions |
-      | manager    | 31          |
-      | manager    | 17          |
-      | editor     | 31          |
-      | editor     | 17          |
+      | manager    | 15          |
+      | manager    | 1           |
+      | editor     | 15          |
+      | editor     | 1           |
 
 
   Scenario Outline: user copies a file from share space with different role to project space with role viewer
@@ -254,8 +256,8 @@ Feature: copy file
       | /testshare.txt |
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario Outline: user copies a file from share space with different role to share space with role editor
@@ -263,7 +265,7 @@ Feature: copy file
     And user "Brian" has created folder "/testshare2"
     And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
     And user "Brian" has shared folder "/testshare1" with user "Alice" with permissions "<permissions>"
-    And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "31"
+    And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "15"
     When user "Alice" copies file "/testshare1/testshare1.txt" from space "Shares" to "/testshare2/testshare1.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "201"
     And for user "Alice" folder "testshare2" of the space "Shares" should contain these files:
@@ -274,8 +276,8 @@ Feature: copy file
     And for user "Brian" the content of the file "/testshare1/testshare1.txt" of the space "Personal" should be "testshare1 content"
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario Outline: user copies a file from share space with different role to share space with role viewer
@@ -283,7 +285,7 @@ Feature: copy file
     And user "Brian" has created folder "/testshare2"
     And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
     And user "Brian" has shared folder "/testshare1" with user "Alice" with permissions "<permissions>"
-    And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "17"
+    And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "1"
     When user "Alice" copies file "/testshare1/testshare1.txt" from space "Shares" to "/testshare2/testshare1.txt" inside space "Shares" using the WebDAV API
     Then the HTTP status code should be "403"
     And for user "Alice" folder "testshare2" of the space "Shares" should not contain these files:
@@ -292,8 +294,8 @@ Feature: copy file
       | testshare1.txt |
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario Outline: copying a folder within the same project space with different role
@@ -378,12 +380,12 @@ Feature: copy file
       | <entry> |
     Examples:
       | space-role | should-or-not | permissions | status-code | parent-folder     | entry    |
-      | manager    | should        | 31          | 201         | testshare/folder1 | demo.txt |
-      | editor     | should        | 31          | 201         | testshare/folder1 | demo.txt |
-      | viewer     | should        | 31          | 201         | testshare/folder1 | demo.txt |
-      | manager    | should not    | 17          | 403         | testshare         | folder1  |
-      | editor     | should not    | 17          | 403         | testshare         | folder1  |
-      | viewer     | should not    | 17          | 403         | testshare         | folder1  |
+      | manager    | should        | 15          | 201         | testshare/folder1 | demo.txt |
+      | editor     | should        | 15          | 201         | testshare/folder1 | demo.txt |
+      | viewer     | should        | 15          | 201         | testshare/folder1 | demo.txt |
+      | manager    | should not    | 1           | 403         | testshare         | folder1  |
+      | editor     | should not    | 1           | 403         | testshare         | folder1  |
+      | viewer     | should not    | 1           | 403         | testshare         | folder1  |
 
 
   Scenario Outline: user copies a folder from personal space to project space with different role
@@ -416,8 +418,8 @@ Feature: copy file
       | <resource> |
     Examples:
       | permissions | should-or-not | status-code | parent-folder     | resource |
-      | 31          | should        | 201         | testshare/folder1 | demo.txt |
-      | 17          | should not    | 403         | testshare         | folder1  |
+      | 15          | should        | 201         | testshare/folder1 | demo.txt |
+      | 1           | should not    | 403         | testshare         | folder1  |
 
 
   Scenario Outline: user copies a folder from share space with different role to personal space
@@ -432,8 +434,8 @@ Feature: copy file
     And for user "Alice" the content of the file "/testshare.txt" of the space "Personal" should be "testshare content"
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario Outline: user copies a folder from share space with different role to project space with different role
@@ -452,10 +454,10 @@ Feature: copy file
       | testshare.txt |
     Examples:
       | space-role | permissions |
-      | manager    | 31          |
-      | manager    | 17          |
-      | editor     | 31          |
-      | editor     | 17          |
+      | manager    | 15          |
+      | manager    | 1           |
+      | editor     | 15          |
+      | editor     | 1           |
 
 
   Scenario Outline: user copies a folder from share space with different role to project space with role viewer
@@ -474,8 +476,8 @@ Feature: copy file
       | folder1 |
     Examples:
       | permissions |
-      | 31          |
-      | 17          |
+      | 15          |
+      | 1           |
 
 
   Scenario: copying a file to a folder with no permissions
diff --git a/tests/acceptance/features/apiSpacesShares/shareOperations.feature b/tests/acceptance/features/apiSpacesShares/shareOperations.feature
index 96386ac3346..218be5d9e5d 100644
--- a/tests/acceptance/features/apiSpacesShares/shareOperations.feature
+++ b/tests/acceptance/features/apiSpacesShares/shareOperations.feature
@@ -19,7 +19,7 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "19"
+    And the single response should contain a property "ocs:share-permissions" with value "3"
 
 
   Scenario: correct webdav share-permissions for received group shared file with edit and reshare permissions
@@ -27,15 +27,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has created a share with settings
-      | path        | /tmp.txt          |
-      | shareType   | group             |
-      | permissions | share,update,read |
-      | shareWith   | grp1              |
+      | path        | /tmp.txt    |
+      | shareType   | group       |
+      | permissions | update,read |
+      | shareWith   | grp1        |
     When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "19"
+    And the single response should contain a property "ocs:share-permissions" with value "3"
 
 
   Scenario: correct webdav share-permissions for received file with edit permissions but no reshare permissions
@@ -67,9 +67,9 @@ Feature: sharing
     Given user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has shared file "tmp.txt" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,read |
+      | permissions | read |
     Then the HTTP status code should be "200"
-    And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "17"
+    And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "1"
 
 
   Scenario: correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions
@@ -77,15 +77,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has created a share with settings
-      | path        | /tmp.txt   |
-      | shareType   | group      |
-      | permissions | share,read |
-      | shareWith   | grp1       |
+      | path        | /tmp.txt |
+      | shareType   | group    |
+      | permissions | read     |
+      | shareWith   | grp1     |
     When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "17"
+    And the single response should contain a property "ocs:share-permissions" with value "1"
 
 
   Scenario: correct webdav share-permissions for received folder with all permissions
@@ -95,7 +95,7 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "31"
+    And the single response should contain a property "ocs:share-permissions" with value "15"
 
 
   Scenario: correct webdav share-permissions for received group shared folder with all permissions
@@ -110,16 +110,16 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "31"
+    And the single response should contain a property "ocs:share-permissions" with value "15"
 
 
   Scenario: correct webdav share-permissions for received folder with all permissions but edit
     Given user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,delete,create,read |
+      | permissions | delete,create,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "29"
+    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "13"
 
 
   Scenario: correct webdav share-permissions for received group shared folder with all permissions but edit
@@ -127,24 +127,24 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,delete,create,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | delete,create,read |
     When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "29"
+    And the single response should contain a property "ocs:share-permissions" with value "13"
 
 
   Scenario: correct webdav share-permissions for received folder with all permissions but create
     Given user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,delete,update,read |
+      | permissions | delete,update,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "27"
+    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "11"
 
 
   Scenario: correct webdav share-permissions for received group shared folder with all permissions but create
@@ -152,24 +152,24 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,delete,update,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | delete,update,read |
     When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "27"
+    And the single response should contain a property "ocs:share-permissions" with value "11"
 
 
   Scenario: correct webdav share-permissions for received folder with all permissions but delete
     Given user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
+      | permissions | create,update,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "23"
+    And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "7"
 
 
   Scenario: correct webdav share-permissions for received group shared folder with all permissions but delete
@@ -177,15 +177,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,create,update,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | create,update,read |
     When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "23"
+    And the single response should contain a property "ocs:share-permissions" with value "7"
 
 
   Scenario: correct webdav share-permissions for received folder with all permissions but share
diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
index ec40ec7e4d1..95a6d3bc37b 100644
--- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
+++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
@@ -143,7 +143,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | 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
+    When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read" using the sharing API
     Then the HTTP status code should be "200"
     And the OCS status code should be "<ocs-status-code>"
     And as "Alice" the info about the last share by user "Carol" with user "Alice" should include
@@ -262,38 +262,6 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Alice" should not be able to delete folder "/Shares/child1/child2"
 
 
-  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
-      | path                  |
-      | /parent               |
-      | /parent/child1        |
-      | /parent/child1/child2 |
-    And user "Alice" has been added to group "grp1"
-    And user "Brian" has been added to group "grp1"
-    And user "Carol" has created a share with settings
-      | path        | /parent |
-      | shareType   | user    |
-      | shareWith   | Brian   |
-      | permissions | all     |
-    And user "Carol" has created a share with settings
-      | path        | /parent/child1 |
-      | shareType   | group          |
-      | shareWith   | grp1           |
-      | permissions | read           |
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /Shares/parent |
-      | shareType   | user           |
-      | shareWith   | Alice          |
-      | permissions | read           |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    And as "Brian" folder "/Shares/child1" should exist
-    And as "Alice" folder "/Shares/child1" should exist
-    And as "Alice" folder "/Shares/parent" should exist
-
-
   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
@@ -373,32 +341,6 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Alice" should not be able to delete folder "/Shares/parent/child1"
 
 
-  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
-      | path                  |
-      | /parent               |
-      | /parent/child1        |
-      | /parent/child1/child2 |
-    And user "Alice" has been added to group "grp1"
-    And user "Brian" has been added to group "grp1"
-    And user "Carol" has created a share with settings
-      | path        | /parent |
-      | shareType   | group   |
-      | shareWith   | grp1    |
-      | permissions | read    |
-    And user "Carol" has created a share with settings
-      | path        | /parent/child1 |
-      | shareType   | user           |
-      | shareWith   | Brian          |
-      | permissions | all            |
-    And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API
-    And as "Brian" folder "/Shares/parent" should exist
-    And as "Alice" folder "/Shares/parent" should exist
-    And as "Alice" folder "/Shares/child1" should exist
-
-
   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 |
@@ -429,7 +371,7 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Alice" should be able to delete folder "/Shares/parent/child1/fo1"
     And user "Alice" should be able to delete folder "/Shares/parent/child1/child2/fo2"
     And user "Alice" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
-    And user "Alice" should be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API
+    And user "Alice" should not be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API
     And as "Brian" folder "/Shares/child1" should exist
     And user "Brian" should not be able to create folder "/Shares/child1/fo1"
     And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2"
diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
index 8b72e781be8..8aead7e68e3 100644
--- a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
+++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
@@ -8,7 +8,7 @@ Feature: sharing
     Given user "Alice" has been created with default attributes and without skeleton files
 
   @smokeTest
-  Scenario Outline: creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16)
+  Scenario Outline: creating a share of a file with a user, the default permissions are read(1)+update(2)
     Given using OCS API version "<ocs-api-version>"
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
@@ -21,7 +21,7 @@ Feature: sharing
       | share_with_user_type   | 0                     |
       | file_target            | /Shares/textfile0.txt |
       | path                   | /textfile0.txt        |
-      | permissions            | share,read,update     |
+      | permissions            | read,update           |
       | uid_owner              | %username%            |
       | displayname_owner      | %displayname%         |
       | item_type              | file                  |
@@ -47,7 +47,7 @@ Feature: sharing
       | share_with_displayname | %displayname%        |
       | file_target            | /Shares/sample,1.txt |
       | path                   | /sample,1.txt        |
-      | permissions            | share,read,update    |
+      | permissions            | read,update          |
       | uid_owner              | %username%           |
       | displayname_owner      | %displayname%        |
       | item_type              | file                 |
@@ -83,11 +83,11 @@ Feature: sharing
     Examples:
       | ocs-api-version | requested-permissions | granted-permissions | ocs-status-code |
       # Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file
-      | 1               | 31                    | 19                  | 100             |
-      | 2               | 31                    | 19                  | 200             |
-      # Ask for read, share (17), create and delete. You get share plus read
-      | 1               | 29                    | 17                  | 100             |
-      | 2               | 29                    | 17                  | 200             |
+      | 1               | 15                    | 3                   | 100             |
+      | 2               | 15                    | 3                   | 200             |
+      # Ask for read, create and delete. You get share plus read
+      | 1               | 13                    | 1                   | 100             |
+      | 2               | 13                    | 1                   | 200             |
       # Ask for read, update, create, delete. You get read plus update.
       | 1               | 15                    | 3                   | 100             |
       | 2               | 15                    | 3                   | 200             |
@@ -128,7 +128,7 @@ Feature: sharing
       | 2               | 400              |
 
   @issue-2133
-  Scenario Outline: creating a share of a folder with a user, the default permissions are all permissions(31)
+  Scenario Outline: creating a share of a folder with a user, the default permissions are all permissions(15)
     Given using OCS API version "<ocs-api-version>"
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has created folder "/FOLDER"
@@ -153,7 +153,7 @@ Feature: sharing
       | 2               | 200             |
 
 
-  Scenario Outline: creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16)
+  Scenario Outline: creating a share of a file with a group, the default permissions are read(1)+update(2)
     Given using OCS API version "<ocs-api-version>"
     And group "grp1" has been created
     And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
@@ -165,7 +165,7 @@ Feature: sharing
       | share_with_displayname | grp1                  |
       | file_target            | /Shares/textfile0.txt |
       | path                   | /textfile0.txt        |
-      | permissions            | share,read,update     |
+      | permissions            | read,update           |
       | uid_owner              | %username%            |
       | displayname_owner      | %displayname%         |
       | item_type              | file                  |
@@ -178,7 +178,7 @@ Feature: sharing
       | 2               | 200             |
 
 
-  Scenario Outline: creating a share of a folder with a group, the default permissions are all permissions(31)
+  Scenario Outline: creating a share of a folder with a group, the default permissions are all permissions(15)
     Given using OCS API version "<ocs-api-version>"
     And group "grp1" has been created
     And user "Alice" has created folder "/FOLDER"
@@ -363,7 +363,7 @@ Feature: sharing
       | share_with  | brian                  |
       | file_target | /Shares/randomfile.txt |
       | path        | /randomfile.txt        |
-      | permissions | share,read,update      |
+      | permissions | read,update            |
       | uid_owner   | %username%             |
     Then user "brian" should see the following elements
       | /Shares/randomfile.txt |
@@ -496,56 +496,6 @@ Feature: sharing
     And the content of file "/Shares/common/sub/textfile0.txt" for user "Brian" should be "BLABLABLA" plus end-of-line
     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: sharing back to resharer is allowed
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Brian    |
-      | Carol    |
-    And user "Alice" has created folder "userZeroFolder"
-    And user "Alice" has shared folder "userZeroFolder" with user "Brian"
-    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"
-    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
-
-  @issue-enterprise-3896 @issue-2201
-  Scenario: sharing back to original sharer is allowed
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Brian    |
-      | Carol    |
-    And user "Alice" has created folder "userZeroFolder"
-    And user "Alice" has shared folder "userZeroFolder" with user "Brian"
-    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"
-    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
-
-  @issue-enterprise-3896 @issue-2201
-  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    |
-      | Carol    |
-      | David    |
-    And user "Alice" has created folder "userZeroFolder"
-    And user "Alice" has shared folder "userZeroFolder" with user "Brian"
-    And user "Alice" has shared folder "userZeroFolder" with user "Carol"
-    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"
-    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
-
   @smokeTest
   Scenario Outline: creating a share of a renamed file
     Given using OCS API version "<ocs-api-version>"
@@ -560,7 +510,7 @@ Feature: sharing
       | share_with_displayname | %displayname%       |
       | file_target            | /Shares/renamed.txt |
       | path                   | /renamed.txt        |
-      | permissions            | share,read,update   |
+      | permissions            | read,update         |
       | uid_owner              | %username%          |
       | displayname_owner      | %displayname%       |
       | item_type              | file                |
@@ -630,59 +580,10 @@ Feature: sharing
     And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
     And user "Alice" has shared file "textfile0.txt" with group "grp1"
     When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
+    Then the HTTP status code should be "<http-status>"
     And the OCS status code should be "403"
     And the OCS status message should be "Path already shared with this group"
     Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @issue-2215
-  Scenario Outline: sharing the shares folder to users is not possible
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Carol" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
-    And user "Alice" has shared file "textfile0.txt" with user "Brian"
-    When user "Brian" shares folder "Shares" with user "Carol" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    And the OCS status message should be "Path contains files shared with you"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @issue-2215
-  Scenario Outline: sharing the shares folder to groups is not possible
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Carol" has been created with default attributes and without skeleton files
-    And group "share_group" has been created
-    And user "Carol" has been added to group "share_group"
-    And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
-    And user "Alice" has shared file "textfile0.txt" with user "Brian"
-    When user "Brian" shares folder "Shares" with group "share_group" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    And the OCS status message should be "Path contains files shared with you"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @issue-2215
-  Scenario Outline: sharing the shares folder as public link is not possible
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
-    And user "Alice" has shared file "textfile0.txt" with user "Brian"
-    When user "Brian" creates a public link share of folder "Shares" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    And the OCS status message should be "Path contains files shared with you"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
+      | ocs-api-version | http-status |
+      | 1               | 200         |
+      | 2               | 403         |
diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
index 53676177669..1bf0c79f871 100644
--- a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
+++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
@@ -94,7 +94,7 @@ Feature: accept/decline shares coming from internal users
       | share_type             | user                          |
       | uid_owner              | %username%                    |
       | displayname_owner      | %displayname%                 |
-      | permissions            | share,read,update             |
+      | permissions            | read,update                   |
       | uid_file_owner         | %username%                    |
       | displayname_file_owner | %displayname%                 |
       | state                  | 0                             |
diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature
index c09fb324c1f..d8891221961 100644
--- a/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature
+++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature
@@ -44,7 +44,7 @@ Feature: accept/decline shares coming from internal users to the Shares folder
       | share_with_displayname | %displayname%         |
       | file_target            | /Shares/textfile0.txt |
       | path                   | /Shares/textfile0.txt |
-      | permissions            | share,read,update     |
+      | permissions            | read,update           |
       | uid_owner              | %username%            |
       | displayname_owner      | %displayname%         |
       | item_type              | file                  |
diff --git a/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature
index f6044b8662b..1e061da49fe 100644
--- a/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature
+++ b/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature
@@ -30,7 +30,7 @@ Feature: sharing
     And user "Brian" accepts share "/merge-test-outside-perms" offered by user "Alice" using the sharing API
     Then the OCS status code of responses on all endpoints should be "100"
     And the HTTP status code of responses on all endpoints should be "200"
-    And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SRDNVCK"
+    And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SDNVCK"
     And as "Brian" folder "/Shares/merge-test-outside-perms (2)" should not exist
 
 
@@ -56,7 +56,7 @@ Feature: sharing
     And user "Brian" accepts share "/merge-test-outside-twogroups-perms" offered by user "Alice" using the sharing API
     Then the OCS status code of responses on all endpoints should be "100"
     And the HTTP status code of responses on all endpoints should be "200"
-    And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SRDNVCK"
+    And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SDNVCK"
     And as "Brian" folder "/Shares/merge-test-outside-twogroups-perms (2)" should not exist
 
 
@@ -70,7 +70,7 @@ Feature: sharing
     And user "Brian" accepts share "/merge-test-outside-twogroups-member-perms" offered by user "Alice" using the sharing API
     Then the OCS status code of responses on all endpoints should be "100"
     And the HTTP status code of responses on all endpoints should be "200"
-    And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SRDNVCK"
+    And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SDNVCK"
     And as "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms (2)" should not exist
 
 
diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
index b94354a6622..8d0a7826215 100644
--- a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
+++ b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
@@ -136,10 +136,10 @@ Feature: sharing
     And as "Alice" file "Shares/TMP" should not exist
 
 
-  Scenario: receiver renames a received share with share, read, change permissions inside the Shares folder
+  Scenario: receiver renames a received share with read, change permissions inside the Shares folder
     Given user "Alice" has created folder "folderToShare"
     And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
-    And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change"
+    And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "read,change"
     When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" folder "/Shares/myFolder" should exist
@@ -151,10 +151,10 @@ Feature: sharing
     But as "Alice" file "/folderToShare/fileInside" should not exist
 
 
-  Scenario: receiver tries to rename a received share with share, read permissions inside the Shares folder
+  Scenario: receiver tries to rename a received share with read permissions inside the Shares folder
     Given user "Alice" has created folder "folderToShare"
     And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
-    And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read"
+    And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "read"
     When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" folder "/Shares/myFolder" should exist
@@ -205,22 +205,22 @@ Feature: sharing
     But as "Alice" folder "myFolder" should not exist
 
 
-  Scenario: receiver renames a received file share with read,update,share permissions inside the Shares folder in group sharing
+  Scenario: receiver renames a received file share with read,update permissions inside the Shares folder in group sharing
     Given group "grp1" has been created
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
-    And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update,share"
+    And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update"
     When user "Brian" moves folder "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" file "/Shares/newFile.txt" should exist
     But as "Alice" file "/Shares/newFile.txt" should not exist
 
 
-  Scenario: receiver renames a received folder share with share, read, change permissions inside the Shares folder in group sharing
+  Scenario: receiver renames a received folder share with read, change permissions inside the Shares folder in group sharing
     Given group "grp1" has been created
     And user "Alice" has created folder "PARENT"
     And user "Brian" has been added to group "grp1"
-    And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read,change"
+    And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "read,change"
     When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" folder "/Shares/myFolder" should exist
@@ -231,18 +231,18 @@ Feature: sharing
     Given group "grp1" has been created
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
-    And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "share,read"
+    And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read"
     When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" file "/Shares/newFile.txt" should exist
     But as "Alice" file "/Shares/newFile.txt" should not exist
 
 
-  Scenario: receiver renames a received folder share with share, read permissions inside the Shares folder in group sharing
+  Scenario: receiver renames a received folder share with read permissions inside the Shares folder in group sharing
     Given group "grp1" has been created
     And user "Alice" has created folder "PARENT"
     And user "Brian" has been added to group "grp1"
-    And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read"
+    And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "read"
     When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Brian" folder "/Shares/myFolder" should exist
@@ -270,19 +270,19 @@ Feature: sharing
       | @a#8a=b?c=d   | @a#8a=b?c=d grp | ?a#8 a=b?c=d    |
 
   @issue-2141
-  Scenario Outline: receiver renames a received file share to name with special characters with share, read, change permissions in group sharing
+  Scenario Outline: receiver renames a received file share to name with special characters with read, change permissions in group sharing
     Given group "grp1" has been created
     And user "Carol" has been added to group "grp1"
     And user "Alice" has created folder "<sharer-folder>"
     And user "Alice" has created folder "<group-folder>"
     And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<sharer-folder>/fileInside"
     And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<group-folder>/fileInside"
-    And user "Alice" has shared folder "<sharer-folder>" with user "Brian" with permissions "share,read,change"
+    And user "Alice" has shared folder "<sharer-folder>" with user "Brian" with permissions "read,change"
     When user "Brian" moves folder "/Shares/<sharer-folder>/fileInside" to "/Shares/<sharer-folder>/<receiver_file>" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Alice" file "<sharer-folder>/<receiver_file>" should exist
     And as "Brian" file "/Shares/<sharer-folder>/<receiver_file>" should exist
-    When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "share,read,change" using the sharing API
+    When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "read,change" using the sharing API
     And user "Carol" moves folder "/Shares/<group-folder>/fileInside" to "/Shares/<group-folder>/<receiver_file>" using the WebDAV API
     Then the HTTP status code should be "201"
     And as "Alice" file "<group-folder>/<receiver_file>" should exist
diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
index 9f72d0c2b87..4fd3519039c 100644
--- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
+++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
@@ -59,47 +59,6 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @smokeTest
-  Scenario Outline: getting all shares of a file with reshares
-    Given using OCS API version "<ocs-api-version>"
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Carol    |
-      | David    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has shared file "textfile0.txt" with user "Brian"
-    And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol"
-    When user "Alice" gets all the shares with reshares of the file "textfile0.txt" 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 included in the response
-    And user "Carol" should be included in the response
-    And user "David" should not be included in the response
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @smokeTest
-  Scenario Outline: resource can be reshared to resource owner
-    Given using OCS API version "<ocs-api-version>"
-    And group "grp1" has been created
-    And user "Carol" has been created with default attributes and without skeleton files
-    And user "Carol" has been added to group "grp1"
-    And user "Carol" has created folder "/shared"
-    And user "Carol" has uploaded file with content "some data" to "/shared/shared_file.txt"
-    And user "Carol" has shared folder "/shared" with user "Brian"
-    And user "Brian" has shared folder "/Shares/shared" with group "grp1"
-    # no need to accept this share as it is Carol's file
-    When user "Carol" gets all the shares shared with her 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/shared" should be included in the response
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
   @smokeTest @issue-1226 @issue-1270 @issue-1271
   Scenario Outline: getting share info of a share
     Given using OCS API version "<ocs-api-version>"
@@ -117,7 +76,7 @@ Feature: sharing
       | file_source            | A_STRING                  |
       | file_target            | /Shares/file_to_share.txt |
       | path                   | /file_to_share.txt        |
-      | permissions            | share,read,update         |
+      | permissions            | read,update               |
       | stime                  | A_NUMBER                  |
       | storage                | A_STRING                  |
       | mail_send              | 0                         |
@@ -181,7 +140,7 @@ Feature: sharing
       | file_source            | A_STRING                  |
       | file_target            | /Shares/file_to_share.txt |
       | path                   | /PARENT/file_to_share.txt |
-      | permissions            | share,read,update         |
+      | permissions            | read,update               |
       | stime                  | A_NUMBER                  |
       | storage                | A_STRING                  |
       | mail_send              | 0                         |
diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature
index 5c5a39b6b40..abc0874300a 100644
--- a/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature
+++ b/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature
@@ -31,7 +31,7 @@ Feature: sharing
       | spaces           |
 
   @skipOnReva
-  Scenario Outline: check webdav share-permissions for received file with edit and reshare permissions
+  Scenario Outline: check webdav share-permissions for received file with edit
     Given using <dav-path-version> DAV path
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has shared file "/tmp.txt" with user "Brian"
@@ -39,28 +39,28 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "19"
+    And the single response should contain a property "ocs:share-permissions" with value "3"
     Examples:
       | dav-path-version |
       | old              |
       | new              |
 
 
-  Scenario Outline: check webdav share-permissions for received group shared file with edit and reshare permissions
+  Scenario Outline: check webdav share-permissions for received group shared file with edit
     Given using <dav-path-version> DAV path
     And group "grp1" has been created
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has created a share with settings
-      | path        | /tmp.txt          |
-      | shareType   | group             |
-      | permissions | share,update,read |
-      | shareWith   | grp1              |
+      | path        | /tmp.txt    |
+      | shareType   | group       |
+      | permissions | update,read |
+      | shareWith   | grp1        |
     When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "19"
+    And the single response should contain a property "ocs:share-permissions" with value "3"
     Examples:
       | dav-path-version |
       | old              |
@@ -102,14 +102,14 @@ Feature: sharing
       | new              |
 
   @skipOnReva @issue-2213
-  Scenario Outline: check webdav share-permissions for received file with reshare permissions but no edit permissions
+  Scenario Outline: check webdav share-permissions for received file without edit permissions
     Given using <dav-path-version> DAV path
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has shared file "tmp.txt" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,read |
+      | permissions | read |
     Then the HTTP status code should be "200"
-    And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "17"
+    And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "1"
     Examples:
       | dav-path-version |
       | old              |
@@ -122,15 +122,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
     And user "Alice" has created a share with settings
-      | path        | /tmp.txt   |
-      | shareType   | group      |
-      | permissions | share,read |
-      | shareWith   | grp1       |
+      | path        | /tmp.txt |
+      | shareType   | group    |
+      | permissions | read     |
+      | shareWith   | grp1     |
     When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "17"
+    And the single response should contain a property "ocs:share-permissions" with value "1"
     Examples:
       | dav-path-version |
       | old              |
@@ -164,7 +164,7 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "31"
+    And the single response should contain a property "ocs:share-permissions" with value "15"
     Examples:
       | dav-path-version |
       | old              |
@@ -184,7 +184,7 @@ Feature: sharing
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "31"
+    And the single response should contain a property "ocs:share-permissions" with value "15"
     Examples:
       | dav-path-version |
       | old              |
@@ -196,9 +196,9 @@ Feature: sharing
     And user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,delete,create,read |
+      | permissions | delete,create,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "29"
+    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "13"
     Examples:
       | dav-path-version |
       | old              |
@@ -211,15 +211,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,delete,create,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | delete,create,read |
     When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "29"
+    And the single response should contain a property "ocs:share-permissions" with value "13"
     Examples:
       | dav-path-version |
       | old              |
@@ -231,9 +231,9 @@ Feature: sharing
     And user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,delete,update,read |
+      | permissions | delete,update,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "27"
+    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "11"
     Examples:
       | dav-path-version |
       | old              |
@@ -246,15 +246,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,delete,update,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | delete,update,read |
     When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "27"
+    And the single response should contain a property "ocs:share-permissions" with value "11"
     Examples:
       | dav-path-version |
       | old              |
@@ -266,9 +266,9 @@ Feature: sharing
     And user "Alice" has created folder "/tmp"
     And user "Alice" has shared file "/tmp" with user "Brian"
     When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
+      | permissions | create,update,read |
     Then the HTTP status code should be "200"
-    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "23"
+    And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "7"
     Examples:
       | dav-path-version |
       | old              |
@@ -281,15 +281,15 @@ Feature: sharing
     And user "Brian" has been added to group "grp1"
     And user "Alice" has created folder "/tmp"
     And user "Alice" has created a share with settings
-      | path        | tmp                      |
-      | shareType   | group                    |
-      | shareWith   | grp1                     |
-      | permissions | share,create,update,read |
+      | path        | tmp                |
+      | shareType   | group              |
+      | shareWith   | grp1               |
+      | permissions | create,update,read |
     When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
       | propertyName          |
       | ocs:share-permissions |
     Then the HTTP status code should be "207"
-    And the single response should contain a property "ocs:share-permissions" with value "23"
+    And the single response should contain a property "ocs:share-permissions" with value "7"
     Examples:
       | dav-path-version |
       | old              |
diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature
index 6bcf3783021..f09be64e1db 100644
--- a/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature
+++ b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature
@@ -23,7 +23,7 @@ Feature: share access by ID
       | share_with_displayname | %displayname%         |
       | file_target            | /Shares/textfile0.txt |
       | path                   | /textfile0.txt        |
-      | permissions            | share,read,update     |
+      | permissions            | read,update           |
       | uid_owner              | %username%            |
       | displayname_owner      | %displayname%         |
       | item_type              | file                  |
diff --git a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature
deleted file mode 100644
index 5cf28e274c2..00000000000
--- a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature
+++ /dev/null
@@ -1,184 +0,0 @@
-Feature: reshare as public link
-  As a user
-  I want to create public link shares from files/folders shared with me
-  So that I can give controlled access to others
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-
-  @skipOnReva
-  Scenario Outline: creating a public link from a share with read permission only is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "read"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test |
-      | publicUpload | false        |
-      | password     | %public%     |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: creating a public link from a share with share+read only permissions is allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test |
-      | publicUpload | false        |
-      | password     | %public%     |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
-    Then the HTTP status code should be "200"
-    And the downloaded content should be "some content"
-    But uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnReva
-  Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test              |
-      | permissions  | read,update,create,delete |
-      | publicUpload | true                      |
-      | password     | %public%                  |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: creating a public link from a share with read+write permissions only is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "change"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test |
-      | publicUpload | true         |
-      | password     | %public%     |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: creating a public link from a share with share+read+write permissions is allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test |
-      | publicUpload | false        |
-      | password     | %public%     |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
-    Then the HTTP status code should be "200"
-    And the downloaded content should be "some content"
-    But uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnReva
-  Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test              |
-      | permissions  | read,update,create,delete |
-      | publicUpload | true                      |
-      | password     | %public%                  |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
-    Then the HTTP status code should be "200"
-    And the downloaded content should be "some content"
-    And uploading a file with password "%public%" should work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnReva
-  Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has created folder "/test/sub"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path         | /Shares/test/sub          |
-      | permissions  | read,update,create,delete |
-      | publicUpload | true                      |
-      | password     | %public%                  |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has created folder "/test/sub"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    And user "Brian" has created a public link share with settings
-      | path         | /Shares/test |
-      | permissions  | read         |
-      | publicUpload | false        |
-      | password     | %public%     |
-    When user "Brian" updates the last public link share using the sharing API with
-      | permissions | read,update,create,delete |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/test"
-    And user "Alice" has created folder "/test/sub"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    And user "Brian" has created a public link share with settings
-      | path         | /Shares/test/sub |
-      | permissions  | read             |
-      | publicUpload | false            |
-      | password     | %public%         |
-    And uploading a file should not work using the new public WebDAV API
-    When user "Brian" updates the last public link share using the sharing API with
-      | permissions | read,update,create,delete |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
diff --git a/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature
index b87d19ca4a4..969062fba9e 100644
--- a/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature
+++ b/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature
@@ -232,89 +232,6 @@ Feature: update a public link share
       | 1               | 100             |
       | 2               | 200             |
 
-  @skipOnReva
-  Scenario Outline: adding public upload to a read only shared folder as recipient is not allowed using the public API
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    And user "Brian" has created a public link share with settings
-      | path         | /Shares/test |
-      | publicUpload | false        |
-      | password     | %public%     |
-    When user "Brian" updates the last public link share using the sharing API with
-      | publicUpload | true |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And uploading a file should not work using the old public WebDAV API
-    And uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline:adding public upload to a shared folder as recipient is allowed with permissions using the public API
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
-    And user "Brian" has created a public link share with settings
-      | path         | /Shares/test |
-      | publicUpload | false        |
-      | password     | %public%     |
-    When user "Brian" updates the last public link share using the sharing API with
-      | publicUpload | true |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And uploading a file with password "%public%" should work using the old public WebDAV API
-    And uploading a file with password "%public%" should work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnReva
-  Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is not allowed using the public API
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
-    And user "Brian" has created a public link share with settings
-      | path        | /Shares/test |
-      | permissions | read         |
-      | password    | %public%     |
-    When user "Brian" updates the last public link share using the sharing API with
-      | permissions | read,update,create,delete |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And uploading a file should not work using the old public WebDAV API
-    And uploading a file should not work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnReva
-  Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is allowed with permissions using the public API
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/test"
-    And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
-    And user "Brian" has created a public link share with settings
-      | path        | /Shares/test |
-      | permissions | read         |
-      | password    | %public%     |
-    When user "Brian" updates the last public link share using the sharing API with
-      | permissions | read,update,create,delete |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And uploading a file with password "%public%" should work using the new public WebDAV API
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 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>"
diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
deleted file mode 100644
index 5e99f705d90..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
+++ /dev/null
@@ -1,283 +0,0 @@
-@issue-1328 @skipOnReva
-Feature: sharing
-  As a user
-  I want to re-share a resource
-  So that other users can have access to it
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-      | Carol    |
-
-  @smokeTest @skipOnRevaMaster
-  Scenario Outline: user is not allowed to reshare file when reshare permission is not given
-    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 "read,update"
-    When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" file "/Shares/textfile0.txt" should not exist
-    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 |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @skipOnRevaMaster
-  Scenario Outline: user is not allowed to reshare folder when reshare permission is not given
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update"
-    When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "read,update" using the sharing API
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" folder "/Shares/FOLDER" should not exist
-    And the sharing API should report to user "Carol" that no shares are in the pending state
-    But as "Brian" folder "/Shares/FOLDER" should exist
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-  @smokeTest
-  Scenario Outline: user is allowed to reshare file with the same permissions
-    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 "share,read"
-    When user "Brian" shares file "/Shares/textfile0.txt" 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 as "Carol" file "/Shares/textfile0.txt" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: user is allowed to reshare folder with the same permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read"
-    When user "Brian" shares folder "/Shares/FOLDER" 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 as "Carol" folder "/Shares/FOLDER" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: user is allowed to reshare file with less permissions
-    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 "share,update,read"
-    When user "Brian" shares file "/Shares/textfile0.txt" 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 as "Carol" file "/Shares/textfile0.txt" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: user is allowed to reshare folder with less permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read"
-    When user "Brian" shares folder "/Shares/FOLDER" 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 as "Carol" folder "/Shares/FOLDER" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnRevaMaster
-  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 17
-    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 "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" file "/Shares/textfile0.txt" should not exist
-    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 | reshare-permissions |
-      # passing on more bits including reshare
-      | 1               | 200              | 19                  |
-      | 2               | 403              | 19                  |
-      | 1               | 200              | 23                  |
-      | 2               | 403              | 23                  |
-      | 1               | 200              | 31                  |
-      | 2               | 403              | 31                  |
-      # passing on more bits but not reshare
-      | 1               | 200              | 3                   |
-      | 2               | 403              | 3                   |
-      | 1               | 200              | 7                   |
-      | 2               | 403              | 7                   |
-      | 1               | 200              | 15                  |
-      | 2               | 403              | 15                  |
-
-
-  Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored
-    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>
-    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 "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Carol" should include
-      | share_with  | %username%            |
-      | file_target | /Shares/textfile0.txt |
-      | path        | /textfile0.txt        |
-      | permissions | <granted-permissions> |
-      | uid_owner   | %username%            |
-    And as "Carol" file "/Shares/textfile0.txt" should exist
-    # The receiver of the reshare can always delete their received share, even though they do not have delete permission
-    And user "Carol" should be able to delete file "/Shares/textfile0.txt"
-    # But the upstream sharers will still have the file
-    But as "Brian" file "/Shares/textfile0.txt" should exist
-    And as "Alice" file "/textfile0.txt" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code | received-permissions | reshare-permissions | granted-permissions |
-      | 1               | 100             | 19                   | 23                  | 19                  |
-      | 2               | 200             | 19                   | 23                  | 19                  |
-      | 1               | 100             | 19                   | 31                  | 19                  |
-      | 2               | 200             | 19                   | 31                  | 19                  |
-      | 1               | 100             | 19                   | 7                   | 3                   |
-      | 2               | 200             | 19                   | 7                   | 3                   |
-      | 1               | 100             | 19                   | 15                  | 3                   |
-      | 2               | 200             | 19                   | 15                  | 3                   |
-      | 1               | 100             | 17                   | 21                  | 17                  |
-      | 2               | 200             | 17                   | 21                  | 17                  |
-      | 1               | 100             | 17                   | 5                   | 1                   |
-      | 2               | 200             | 17                   | 5                   | 1                   |
-      | 1               | 100             | 17                   | 25                  | 17                  |
-      | 2               | 200             | 17                   | 25                  | 17                  |
-      | 1               | 100             | 17                   | 9                   | 1                   |
-      | 2               | 200             | 17                   | 9                   | 1                   |
-
-  @skipOnRevaMaster
-  Scenario Outline: user is not allowed to reshare folder and set more permissions bits
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
-    When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" folder "/Shares/PARENT" should not exist
-    And the sharing API should report to user "Carol" that no shares are in the pending state
-    But as "Brian" folder "/Shares/PARENT" should exist
-    Examples:
-      | ocs-api-version | http-status-code | received-permissions | reshare-permissions |
-      # try to pass on more bits including reshare
-      | 1               | 200              | 17                   | 19                  |
-      | 2               | 403              | 17                   | 19                  |
-      | 1               | 200              | 17                   | 21                  |
-      | 2               | 403              | 17                   | 21                  |
-      | 1               | 200              | 17                   | 23                  |
-      | 2               | 403              | 17                   | 23                  |
-      | 1               | 200              | 17                   | 31                  |
-      | 2               | 403              | 17                   | 31                  |
-      | 1               | 200              | 19                   | 23                  |
-      | 2               | 403              | 19                   | 23                  |
-      | 1               | 200              | 19                   | 31                  |
-      | 2               | 403              | 19                   | 31                  |
-      # try to pass on more bits but not reshare
-      | 1               | 200              | 17                   | 3                   |
-      | 2               | 403              | 17                   | 3                   |
-      | 1               | 200              | 17                   | 5                   |
-      | 2               | 403              | 17                   | 5                   |
-      | 1               | 200              | 17                   | 7                   |
-      | 2               | 403              | 17                   | 7                   |
-      | 1               | 200              | 17                   | 15                  |
-      | 2               | 403              | 17                   | 15                  |
-      | 1               | 200              | 19                   | 7                   |
-      | 2               | 403              | 19                   | 7                   |
-      | 1               | 200              | 19                   | 15                  |
-      | 2               | 403              | 19                   | 15                  |
-
-  @skipOnRevaMaster
-  Scenario Outline: user is not allowed to reshare folder and add delete permission bit (8)
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
-    When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" folder "/Shares/PARENT" should not exist
-    And the sharing API should report to user "Carol" that no shares are in the pending state
-    But as "Brian" folder "/Shares/PARENT" should exist
-    Examples:
-      | ocs-api-version | http-status-code | received-permissions | reshare-permissions |
-      # try to pass on extra delete (including reshare)
-      | 1               | 200              | 17                   | 25                  |
-      | 2               | 403              | 17                   | 25                  |
-      | 1               | 200              | 19                   | 27                  |
-      | 2               | 403              | 19                   | 27                  |
-      | 1               | 200              | 23                   | 31                  |
-      | 2               | 403              | 23                   | 31                  |
-      # try to pass on extra delete (but not reshare)
-      | 1               | 200              | 17                   | 9                   |
-      | 2               | 403              | 17                   | 9                   |
-      | 1               | 200              | 19                   | 11                  |
-      | 2               | 403              | 19                   | 11                  |
-      | 1               | 200              | 23                   | 15                  |
-      | 2               | 403              | 23                   | 15                  |
-
-
-  Scenario Outline: reshare a file with same name as a deleted file
-    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"
-    And user "Alice" has deleted file "textfile0.txt"
-    And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt"
-    When user "Alice" shares file "textfile0.txt" 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 the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: reshare a folder with same name as a deleted folder
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has shared folder "PARENT" with user "Brian"
-    And user "Alice" has deleted folder "PARENT"
-    And user "Alice" has created folder "/PARENT"
-    When user "Alice" shares folder "PARENT" 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 as "Brian" folder "/Shares/PARENT" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: reshare a folder with same name as a deleted file
-    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"
-    And user "Alice" has deleted file "/textfile0.txt"
-    And user "Alice" has created folder "/textfile0.txt"
-    When user "Alice" shares folder "textfile0.txt" 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 as "Brian" folder "/Shares/textfile0.txt" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShareChain.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShareChain.feature
deleted file mode 100644
index b9524dcf6ce..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares1/reShareChain.feature
+++ /dev/null
@@ -1,22 +0,0 @@
-@issue-2141 @skipOnReva
-Feature: resharing can be done on a reshared resource
-  As a user
-  I want to re-share a resource
-  So that other users can have access to it
-
-
-  Scenario: reshared files can be still accessed if a user in the middle removes it
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-      | Carol    |
-      | David    |
-    And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
-    And user "Alice" has shared file "textfile0.txt" with user "Brian"
-    And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol"
-    And user "Carol" has shared file "/Shares/textfile0.txt" with user "David"
-    When user "Brian" deletes file "/Shares/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And the content of file "/Shares/textfile0.txt" for user "Carol" should be "ownCloud test text file 0"
-    And the content of file "/Shares/textfile0.txt" for user "David" should be "ownCloud test text file 0"
diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature
deleted file mode 100644
index 52cb73736fa..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature
+++ /dev/null
@@ -1,22 +0,0 @@
-@issue-1328 @skipOnReva
-Feature: resharing can be disabled
-  As a user
-  I want to share a resource without reshare permission
-  So that the resource won't be accessible to unwanted individuals
-
-
-  Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And as "Brian" file "/Shares/textfile0.txt" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
deleted file mode 100644
index 6b7a1e15b71..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
+++ /dev/null
@@ -1,135 +0,0 @@
-@issue-1328 @skipOnReva
-Feature: a subfolder of a received share can be reshared
-  As a user
-  I want to re-share a resource
-  So that other users can have access to it
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-      | Carol    |
-    And user "Alice" has created folder "/TMP"
-    And user "Alice" has created folder "/TMP/SUB"
-
-  @smokeTest @issue-2214
-  Scenario Outline: user is allowed to reshare a sub-folder with the same permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
-    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 as "Carol" folder "/Shares/SUB" should exist
-    And as "Brian" folder "/Shares/TMP/SUB" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnRevaMaster
-  Scenario Outline: user is not allowed to reshare a sub-folder with more permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions <received-permissions>
-    When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions <reshare-permissions> using the sharing API
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" folder "/Shares/SUB" should not exist
-    And the sharing API should report to user "Carol" that no shares are in the pending state
-    And as "Brian" folder "/Shares/TMP/SUB" should exist
-    Examples:
-      | ocs-api-version | http-status-code | received-permissions | reshare-permissions |
-      # try to pass on more bits including reshare
-      | 1               | 200              | 17                   | 19                  |
-      | 2               | 403              | 17                   | 19                  |
-      | 1               | 200              | 17                   | 21                  |
-      | 2               | 403              | 17                   | 21                  |
-      | 1               | 200              | 17                   | 23                  |
-      | 2               | 403              | 17                   | 23                  |
-      | 1               | 200              | 17                   | 31                  |
-      | 2               | 403              | 17                   | 31                  |
-      | 1               | 200              | 19                   | 23                  |
-      | 2               | 403              | 19                   | 23                  |
-      | 1               | 200              | 19                   | 31                  |
-      | 2               | 403              | 19                   | 31                  |
-      # try to pass on more bits but not reshare
-      | 1               | 200              | 17                   | 3                   |
-      | 2               | 403              | 17                   | 3                   |
-      | 1               | 200              | 17                   | 5                   |
-      | 2               | 403              | 17                   | 5                   |
-      | 1               | 200              | 17                   | 7                   |
-      | 2               | 403              | 17                   | 7                   |
-      | 1               | 200              | 17                   | 15                  |
-      | 2               | 403              | 17                   | 15                  |
-      | 1               | 200              | 19                   | 7                   |
-      | 2               | 403              | 19                   | 7                   |
-      | 1               | 200              | 19                   | 15                  |
-      | 2               | 403              | 19                   | 15                  |
-      # try to pass on extra delete (including reshare)
-      | 1               | 200              | 17                   | 25                  |
-      | 2               | 403              | 17                   | 25                  |
-      | 1               | 200              | 19                   | 27                  |
-      | 2               | 403              | 19                   | 27                  |
-      | 1               | 200              | 23                   | 31                  |
-      | 2               | 403              | 23                   | 31                  |
-      # try to pass on extra delete (but not reshare)
-      | 1               | 200              | 17                   | 9                   |
-      | 2               | 403              | 17                   | 9                   |
-      | 1               | 200              | 19                   | 11                  |
-      | 2               | 403              | 19                   | 11                  |
-      | 1               | 200              | 23                   | 15                  |
-      | 2               | 403              | 23                   | 15                  |
-
-  @issue-2214
-  Scenario Outline: user is allowed to update reshare of a sub-folder with less permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read"
-    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>"
-    And the HTTP status code should be "200"
-    And as "Carol" folder "/Shares/SUB" should exist
-    But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
-    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 |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @issue-2214
-  Scenario Outline: user is allowed to update reshare of a sub-folder to the maximum allowed permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    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>"
-    And the HTTP status code should be "200"
-    And as "Carol" folder "/Shares/SUB" should exist
-    And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
-    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 |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @issue-2214 @skipOnRevaMaster
-  Scenario Outline: user is not allowed to update reshare of a sub-folder with more permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
-    And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    When user "Brian" updates the last share using the sharing API with
-      | permissions | all |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And as "Carol" folder "/Shares/SUB" should exist
-    But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
-    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 |
-      | 1               | 200              |
-      | 2               | 403              |
diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature
deleted file mode 100644
index f7330fef7b6..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature
+++ /dev/null
@@ -1,138 +0,0 @@
-@issue-1328 @skipOnReva
-Feature: sharing
-  As a user
-  I want to update share permissions
-  So that I can decide what resources can be shared with which permission
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-      | Carol    |
-    And user "Alice" has created folder "/TMP"
-
-
-  Scenario Outline: update of reshare can reduce permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
-    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>"
-    And the HTTP status code should be "200"
-    And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: update of reshare can increase permissions to the maximum allowed
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
-    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>"
-    And the HTTP status code should be "200"
-    And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @skipOnRevaMaster
-  Scenario Outline: do not allow update of reshare to exceed permissions
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
-    When user "Brian" updates the last share using the sharing API with
-      | permissions | all |
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-
-  Scenario Outline: update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
-    When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
-    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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
-    When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
-    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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: update of group reshare by the original share owner can increase permissions up to permissions of the top-level share
-    Given using OCS API version "<ocs-api-version>"
-    And group "grp1" has been created
-    And user "Carol" has been added to group "grp1"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
-    When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
-    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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share
-    Given using OCS API version "<ocs-api-version>"
-    And group "grp1" has been created
-    And user "Carol" has been added to group "grp1"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
-    When user "Alice" updates the last share using the sharing API with
-      | permissions | share,create,update,read |
-    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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: after losing share permissions user can still delete a previously reshared share
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
-    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
-    And user "Alice" has updated the last share of "Alice" with
-      | permissions | create,update,read |
-    When user "Brian" deletes the last share 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 not have any received shares
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature
deleted file mode 100644
index 909df57a2ff..00000000000
--- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature
+++ /dev/null
@@ -1,77 +0,0 @@
-@issue-1328 @skipOnReva
-Feature: resharing a resource with an expiration date
-  As a user
-  I want to reshare resources with expiration date
-  So that other users will have access to the resources only for a limited amount of time
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Carol" has been created with default attributes and without skeleton files
-
-
-  Scenario Outline: user should be able to set expiration while resharing a file with user
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /Shares/textfile0.txt |
-      | shareType   | user                  |
-      | permissions | change                |
-      | shareWith   | Carol                 |
-      | expireDate  | +3 days               |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And the information of the last share of user "Brian" should include
-      | expiration | +3 days |
-    And the response when user "Carol" gets the info of the last share should include
-      | expiration | +3 days |
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-  @issue-1289
-  Scenario Outline: user should be able to set expiration while resharing a file with group
-    Given using OCS API version "<ocs-api-version>"
-    And group "grp1" has been created
-    And user "Carol" has been added to group "grp1"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /Shares/textfile0.txt |
-      | shareType   | group                 |
-      | permissions | change                |
-      | shareWith   | grp1                  |
-      | expireDate  | +3 days               |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And the information of the last share of user "Brian" should include
-      | expiration | +3 days |
-    And the response when user "Carol" gets the info of the last share should include
-      | expiration | +3 days |
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: resharing using the sharing API with default expire date set but not enforced
-    Given using OCS API version "<ocs-api-version>"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /Shares/textfile0.txt |
-      | shareType   | user                  |
-      | permissions | change                |
-      | shareWith   | Carol                 |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And the information of the last share of user "Brian" should include
-      | expiration |  |
-    And the response when user "Carol" gets the info of the last share should include
-      | expiration |  |
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
index 6a0b53d5a3d..389a1bc2ca3 100644
--- a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
+++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
@@ -8,26 +8,6 @@ Feature: sharing
     Given using OCS API version "1"
     And user "Alice" has been created with default attributes and without skeleton files
 
-  @smokeTest
-  Scenario Outline: allow modification of reshare
-    Given using OCS API version "<ocs-api-version>"
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Brian    |
-      | Carol    |
-    And user "Alice" has created folder "/TMP"
-    And user "Alice" has shared folder "TMP" with user "Brian"
-    And user "Brian" has shared folder "/Shares/TMP" with user "Carol"
-    When user "Brian" updates the last share using the sharing API with
-      | permissions | read |
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
-    And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
 
   @issue-1289 @issue-7555
   Scenario Outline: keep group permissions in sync when the share is renamed by the receiver and then the permissions are updated by sharer
@@ -120,36 +100,6 @@ Feature: sharing
       | 1               | 200              | create,delete |
       | 2               | 400              | create,delete |
 
-  @issue-2201
-  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    |
-      | Carol    |
-    And user "Alice" has created folder "/folder1"
-    And user "Alice" has created folder "/folder1/folder2"
-    And user "Brian" has created folder "/moved-out"
-    And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all"
-    And user "Brian" has shared folder "/Shares/folder1/folder2" with user "Carol" with permissions "all"
-    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
-      | id                | A_STRING             |
-      | item_type         | folder               |
-      | item_source       | A_STRING             |
-      | share_type        | user                 |
-      | file_source       | A_STRING             |
-      | file_target       | /Shares/folder2      |
-      | permissions       | all                  |
-      | stime             | A_NUMBER             |
-      | storage           | A_STRING             |
-      | mail_send         | 0                    |
-      | uid_owner         | %username%           |
-      | displayname_owner | %displayname%        |
-      | mimetype          | httpd/unix-directory |
-    And as "Alice" folder "/Shares/folder1/folder2" should not exist
-    And as "Carol" folder "/Shares/folder2" should exist
-
   @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:
@@ -162,23 +112,7 @@ Feature: sharing
     And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all"
     And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all"
     When user "Brian" moves folder "/Shares/Alice-folder/folder2" to "/Shares/Carol-folder/folder2" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the response when user "Carol" gets the info of the last share should include
-      | id                | A_STRING             |
-      | item_type         | folder               |
-      | item_source       | A_STRING             |
-      | share_type        | user                 |
-      | file_source       | A_STRING             |
-      | file_target       | /Carol-folder        |
-      | permissions       | all                  |
-      | stime             | A_NUMBER             |
-      | storage           | A_STRING             |
-      | mail_send         | 0                    |
-      | uid_owner         | %username%           |
-      | displayname_owner | %displayname%        |
-      | mimetype          | httpd/unix-directory |
-    And as "Alice" folder "/Alice-folder/folder2" should not exist
-    And as "Carol" folder "/Carol-folder/folder2" should exist
+    Then the HTTP status code should be "502"
 
   @issue-1253 @issue-1224 @issue-1225
   #after fixing all the issues merge this scenario with the one below