diff --git a/.drone.yml b/.drone.yml
index 7db638bb3712..cf220b2b8b82 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1370,6 +1370,8 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
       USE_EMAIL: true
+      USE_FEDERATED_SERVER: true
+      FEDERATION_OC_VERSION: daily-stable10-qa
 
     - PHP_VERSION: 7.1
       TEST_SUITE: selenium
diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
index 0485672bb8f3..bbff9b0a6ec2 100644
--- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
@@ -73,14 +73,18 @@ Feature: edit users
       | email | brand-new-user@example.com |
     And the email address of user "brand-new-user" should be "brand-new-user@example.com"
 
-  Scenario: a normal user should be able to change their display name
+  Scenario Outline: a normal user should be able to change their display name
     Given user "brand-new-user" has been created with default attributes and skeleton files
-    When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API
+    When user "brand-new-user" changes the display name of user "brand-new-user" to "<display-name>" using the provisioning API
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And the attributes of user "brand-new-user" returned by the API should include
-      | displayname | Alan Border |
-    And the display name of user "brand-new-user" should be "Alan Border"
+      | displayname | <display-name> |
+    And the display name of user "brand-new-user" should be "<display-name>"
+    Examples:
+      | display-name   |
+      | Alan Border    |
+      | Phil Cyclist 🚴 |
 
   Scenario: a normal user should not be able to change their quota
     Given user "brand-new-user" has been created with default attributes and skeleton files
diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
index a7cca92cfeaf..6b1a61835618 100644
--- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
@@ -73,14 +73,18 @@ Feature: edit users
       | email | brand-new-user@example.com |
     And the email address of user "brand-new-user" should be "brand-new-user@example.com"
 
-  Scenario: a normal user should be able to change their display name
+  Scenario Outline: a normal user should be able to change their display name
     Given user "brand-new-user" has been created with default attributes and skeleton files
-    When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API
+    When user "brand-new-user" changes the display name of user "brand-new-user" to "<display-name>" using the provisioning API
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
     And the attributes of user "brand-new-user" returned by the API should include
-      | displayname | Alan Border |
-    And the display name of user "brand-new-user" should be "Alan Border"
+      | displayname | <display-name> |
+    And the display name of user "brand-new-user" should be "<display-name>"
+    Examples:
+      | display-name   |
+      | Alan Border    |
+      | Phil Cyclist 🚴 |
 
   Scenario: a normal user should not be able to change their quota
     Given user "brand-new-user" has been created with default attributes and skeleton files
diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature
index f3eb08606f0e..a428ecefb7d7 100644
--- a/tests/acceptance/features/apiShareManagement/reShare.feature
+++ b/tests/acceptance/features/apiShareManagement/reShare.feature
@@ -359,6 +359,38 @@ Feature: sharing
       | 1               | 200              |
       | 2               | 404              |
 
+  @issue-enterprise-3364
+  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 "user0" has created folder "/test"
+    And user "user0" has created folder "/test/sub"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 17
+    And user "user1" has created a public link share with settings
+      | path         | /test/sub |
+      | permissions  | 1         |
+      | publicUpload | false     |
+    And publicly uploading a file should not work
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 15 |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    #Then the OCS status code should be "404"
+    #And the HTTP status code should be "<http_status_code>"
+    And publicly uploading a file should work
+    #And publicly uploading a file should not work
+    # Delete the following 4 steps when fixing the issue:
+    And the public should be able to upload file "file.txt" with content "some text" to the last public shared folder
+    And as "user0" file "/test/sub/file.txt" should exist
+    And as "user1" file "/test/sub/file.txt" should exist
+    And the content of file "/test/sub/file.txt" for user "user0" should be "some text"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+      #| ocs_api_version | http_status_code |
+      #| 1               | 200              |
+      #| 2               | 404              |
+
   Scenario Outline: resharing a file is not allowed when allow resharing has been disabled
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 605e9579fcbe..365e269e43c6 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -383,6 +383,12 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ
 		// We add all the request objects in an array so that we can send all the requests in parallel.
 		$requests = [];
 		$client = new Client();
+
+		if (\getenv("TEST_EXTERNAL_USER_BACKENDS") === "true") {
+			echo "creating LDAP users is not implemented, so assume they exist\n";
+			return;
+		}
+
 		foreach ($table as $row) {
 			$body['userid'] = $this->getActualUsername($row['username']);
 
@@ -3085,7 +3091,7 @@ public function getDisabledApps() {
 	 *
 	 * @return string
 	 */
-	public function popSkeletonDirectoryConfig($baseUrl) {
+	public function popSkeletonDirectoryConfig($baseUrl = null) {
 		$this->runOcc(
 			["config:system:get skeletondirectory"],
 			null, null, $baseUrl
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 4f882d7b7dc7..4ab228510dbd 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -9,17 +9,21 @@ Feature: Share by public link
   So that public sharing is limited according to organization policy
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
 
   @smokeTest
   Scenario: simple sharing by public link
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI
     And the public accesses the last created public link using the webUI
     Then file "lorem.txt" should be listed on the webUI
 
   @skipOnOcV10.0.3 @feature_was_changed_in_10.0.4
   Scenario: creating a public link with read & write permissions makes it possible to delete files via the link
+    Given user "user2" has been created with default attributes and skeleton files
+    And user "user2" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
@@ -34,6 +38,9 @@ Feature: Share by public link
 
   @skipOnOcV10.0.3 @feature_was_changed_in_10.0.4
   Scenario: creating a public link with read permissions only makes it impossible to delete files via the link
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | read |
     And the public accesses the last created public link using the webUI
@@ -42,92 +49,119 @@ Feature: Share by public link
   @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392
   Scenario: mount public link
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
+    And using server "LOCAL"
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI
     And the user logs out of the webUI
     And the public accesses the last created public link using the webUI
     And the public adds the public link to "%remote_server%" as user "user2" with password "%alt2%" using the webUI
     And the user accepts the offered remote shares using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    When the user opens folder "simple-folder (2)" using the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    When the user opens folder "simple-folder" using the webUI
     Then file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" on the remote server should be the same as the original "simple-folder/lorem.txt"
+    And the content of file "simple-folder/lorem.txt" for user "user2" on server "REMOTE" should be "original content"
     And it should not be possible to delete file "lorem.txt" using the webUI
 
   @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392
   Scenario: mount public link and overwrite file
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
+    And using server "LOCAL"
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the user logs out of the webUI
     And the public accesses the last created public link using the webUI
     And the public adds the public link to "%remote_server%" as user "user2" with password "%alt2%" using the webUI
     And the user accepts the offered remote shares using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    When the user opens folder "simple-folder (2)" using the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    When the user opens folder "simple-folder" using the webUI
     Then file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" on the remote server should be the same as the original "simple-folder/lorem.txt"
+    And the content of file "simple-folder/lorem.txt" for user "user2" on server "REMOTE" should be "original content"
     When the user uploads overwriting file "lorem.txt" using the webUI and retries if the file is locked
     Then file "lorem.txt" should be listed on the webUI
     And the content of "lorem.txt" on the remote server should be the same as the local "lorem.txt"
 
   Scenario: public should be able to access a public link with correct password
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | password | pass123 |
     And the public accesses the last created public link with password "pass123" using the webUI
     Then file "lorem.txt" should be listed on the webUI
 
   Scenario: public should not be able to access a public link with wrong password
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | password | pass123 |
     And the public tries to access the last created public link with wrong password "pass12" using the webUI
     Then the public should not get access to the publicly shared file
 
   Scenario: user shares a public link with folder longer than 64 chars and shorter link name
-    Given user "user1" has moved folder "simple-folder" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
-    And the user has reloaded the current page of the webUI
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt"
+    And user "user1" has moved folder "simple-folder" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" using the webUI with
       | name | short_linkname |
     And the public accesses the last created public link using the webUI
     Then file "lorem.txt" should be listed on the webUI
 
   Scenario: user tries to create a public link with read only permission without entering share password while enforce password on read only public share is enforced
-    Given parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes"
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes"
     When the user tries to create a new public link for folder "simple-folder" using the webUI
     Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares"
     And the public link should not have been generated
 
   Scenario: user tries to create a public link with read-write permission without entering share password while enforce password on read-write public share is enforced
-    Given parameter "shareapi_enforce_links_password_read_write" of app "core" has been set to "yes"
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And parameter "shareapi_enforce_links_password_read_write" of app "core" has been set to "yes"
     When the user tries to create a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares"
     And the public link should not have been generated
 
   Scenario: user tries to create a public link with write only permission without entering share password while enforce password on write only public share is enforced
-    Given parameter "shareapi_enforce_links_password_write_only" of app "core" has been set to "yes"
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And parameter "shareapi_enforce_links_password_write_only" of app "core" has been set to "yes"
     When the user tries to create a new public link for folder "simple-folder" using the webUI with
       | permission | upload |
     Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares"
     And the public link should not have been generated
 
   Scenario: user creates a public link with read-write permission without entering share password while enforce password on read only public share is enforced
-    Given parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes"
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes"
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     Then file "lorem.txt" should be listed on the webUI
 
   Scenario: public should be able to access the shared file through public link
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for file 'lorem.txt' using the webUI
     And the public accesses the last created public link using the webUI
-    Then the text preview of the public link should contain "Lorem ipsum dolor sit amet, consectetur"
+    Then the text preview of the public link should contain "Sed ut perspiciatis"
     And the content of the file shared by the last public link should be the same as "lorem.txt"
 
   Scenario: user shares a public link via email
-    Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    Given user "user1" has created folder "/simple-folder"
+    And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | email | foo@bar.co |
     Then the email address "foo@bar.co" should have received an email with the body containing
@@ -137,8 +171,9 @@ Feature: Share by public link
     And the email address "foo@bar.co" should have received an email containing the last shared public link
 
   Scenario: user shares a public link via email and sends a copy to self
-    Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    Given user "user1" has created folder "/simple-folder"
+    And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | email       | foo@bar.co |
       | emailToSelf | true       |
@@ -154,8 +189,9 @@ Feature: Share by public link
     And the email address "user1@example.org" should have received an email containing the last shared public link
 
   Scenario: user shares a public link via email with multiple addresses
-    Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    Given user "user1" has created folder "/simple-folder"
+    And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | email | foo@bar.co, foo@barr.co |
     Then the email address "foo@bar.co" should have received an email with the body containing
@@ -171,7 +207,8 @@ Feature: Share by public link
 
   Scenario: user shares a public link via email with a personal message
     Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | email           | foo@bar.co  |
       | personalMessage | lorem ipsum |
@@ -187,7 +224,8 @@ Feature: Share by public link
 
   Scenario: user shares a public link via email adding few addresses before and then removing some addresses afterwards
     Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     When the user opens the share dialog for folder "simple-folder"
     And the user opens the public link share tab
     And the user opens the create public link share popup
@@ -217,7 +255,8 @@ Feature: Share by public link
 
   Scenario: user edits a public link and does not save the changes
     Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI with
       | email    | foo1234@bar.co |
       | password | pass123        |
@@ -229,7 +268,8 @@ Feature: Share by public link
 
   Scenario: user shares a public link via email with a personal message
     Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
-    And the user has reloaded the current page of the webUI
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | email           | foo@bar.co  |
       | personalMessage | lorem ipsum |
@@ -244,7 +284,10 @@ Feature: Share by public link
     And the email address "foo@bar.co" should have received an email containing the last shared public link
 
   Scenario: user edits a name of an already existing public link
-    Given the user has created a new public link for folder "simple-folder" using the webUI
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI
     And the user has opened the public link share tab
     When the user renames the public link name from "Public link" to "simple-folder Share"
     And the public accesses the last created public link using the webUI
@@ -252,27 +295,37 @@ Feature: Share by public link
 
   Scenario: user shares a file through public link and then it appears in a Shared by link page
     Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes"
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     And the user has reloaded the current page of the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI
     When the user browses to the shared-by-link page
     Then folder "simple-folder" should be listed on the webUI
 
   Scenario: user edits the password of an already existing public link
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | password | pass123 |
     When the user changes the password of the public link named "Public link" to "pass1234"
     And the public accesses the last created public link with password "pass1234" using the webUI
     Then file "lorem.txt" should be listed on the webUI
 
   Scenario: user edits the password of an already existing public link and tries to access with old password
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | password | pass123 |
     When the user changes the password of the public link named "Public link" to "pass1234"
     And the public tries to access the last created public link with wrong password "pass123" using the webUI
     Then the public should not get access to the publicly shared file
 
   Scenario: user edits the permission of an already existing public link from read-write to read
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the user changes the permission of the public link named "Public link" to "read"
     And the public accesses the last created public link using the webUI
@@ -280,7 +333,11 @@ Feature: Share by public link
     And it should not be possible to delete file "lorem.txt" using the webUI
 
   Scenario: user edits the permission of an already existing public link from read to read-write
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has created folder "/simple-folder/simple-empty-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read |
     When the user changes the permission of the public link named "Public link" to "read-write"
     And the public accesses the last created public link using the webUI
@@ -292,22 +349,26 @@ Feature: Share by public link
     And the deleted elements should not be listed on the webUI after a page reload
 
   Scenario: user changes the expiration date of an already existing public link using webUI
-    Given user "user1" has created a share with settings
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has created a share with settings
       | path       | lorem.txt   |
       | name       | Public link |
       | expireDate | 14-10-2038  |
       | shareType  | 3           |
+    And user "user1" has logged in using the webUI
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "21-07-2038"
     And the user gets the info of the last share using the sharing API
     Then the fields of the last response should include
       | expiration | 21-07-2038 |
 
   Scenario: user tries to change the expiration date of the public link to past date using webUI
-    Given user "user1" has created a share with settings
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has created a share with settings
       | path       | lorem.txt   |
       | name       | Public link |
       | expireDate | 14-10-2038  |
       | shareType  | 3           |
+    And user "user1" has logged in using the webUI
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "14-09-2017"
     And the user gets the info of the last share using the sharing API
     Then the user should see an error message on the public link share dialog saying "Expiration date is in the past"
@@ -315,6 +376,10 @@ Feature: Share by public link
       | expiration | 14-10-2038 |
 
   Scenario: share two file with same name but different paths by public link
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for file "lorem.txt" using the webUI
     And the user closes the details dialog
     And the user opens folder "simple-folder" using the webUI
@@ -324,18 +389,24 @@ Feature: Share by public link
     And file "lorem.txt" with path "/simple-folder" should be listed in the shared with others page on the webUI
 
   Scenario: user removes the public link of a file
-    Given the user has created a new public link for file "lorem.txt" using the webUI
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for file "lorem.txt" using the webUI
     When the user removes the public link of file "lorem.txt" using the webUI
     Then the public should see an error message "File not found" while accessing last created public link using the webUI
 
   Scenario: user cancel removes operation for the public link of a file
-    Given the user has created a new public link for file "lorem.txt" using the webUI
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for file "lorem.txt" using the webUI
     When the user tries to remove the public link of file "lorem.txt" but later cancels the remove dialog using webUI
     And the public accesses the last created public link using the webUI
     Then the content of the file shared by the last public link should be the same as "lorem.txt"
 
   Scenario: user creates a multiple public link of a file and delete the first link
-    Given the user has created a new public link for file "lorem.txt" using the webUI with
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | first-link |
     And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | second-link |
@@ -346,7 +417,9 @@ Feature: Share by public link
     And the number of public links should be 2
 
   Scenario: user creates a multiple public link of a file and delete the second link
-    Given the user has created a new public link for file "lorem.txt" using the webUI with
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | first-link |
     And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | second-link |
@@ -357,7 +430,9 @@ Feature: Share by public link
     And the number of public links should be 2
 
   Scenario: user creates a multiple public link of a file and delete the third link
-    Given the user has created a new public link for file "lorem.txt" using the webUI with
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | first-link |
     And the user has created a new public link for file "lorem.txt" using the webUI with
       | name | second-link |
@@ -368,13 +443,19 @@ Feature: Share by public link
     And the number of public links should be 2
 
   Scenario: user creates public link with view and upload feature
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     And the public accesses the last created public link using the webUI
     Then it should not be possible to delete file "lorem.txt" using the webUI
 
   Scenario: user creates public link with view download and upload feature and uploads same file name and verifies no auto-renamed file seen in UI
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     And the public accesses the last created public link using the webUI
     When the user uploads file "lorem.txt" 5 times using webUI
@@ -385,7 +466,7 @@ Feature: Share by public link
       | The file lorem.txt already exists |
       | The file lorem.txt already exists |
     And file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" should not have changed
+    And the content of file "simple-folder/lorem.txt" should be "original content"
     And file "lorem (2).txt" should not be listed on the webUI
 
   @issue-35177
@@ -402,6 +483,7 @@ Feature: Share by public link
       | path | nf2/newfolder |
     And user "user1" has created a public link share with settings
       | path | test/test |
+    And user "user1" has logged in using the webUI
     And the user has browsed to the shared-by-link page
     When the user renames folder "newfolder" to "newfolder1" using the webUI
     Then folder "newfolder1" should be listed on the webUI
@@ -418,6 +500,7 @@ Feature: Share by public link
         | path | nf1/newfolder |
       And user "user1" has created a public link share with settings
         | path | test |
+      And user "user1" has logged in using the webUI
       And the user has browsed to the shared-by-link page
       When the user renames folder "test" to "newfolder" using the webUI
       Then near folder "test" a tooltip with the text 'newfolder already exists' should be displayed on the webUI
@@ -426,7 +509,10 @@ Feature: Share by public link
         #| newfolder |
 
   Scenario: Permissions work correctly on public link share with upload-write-without-modify
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     When the public accesses the last created public link using the webUI
     Then the option to rename file "lorem.txt" should not be available on the webUI
@@ -434,7 +520,10 @@ Feature: Share by public link
     And the option to upload file should be available on the webUI
 
   Scenario: Permissions work correctly on public link share with read-write
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
     Then the option to rename file "lorem.txt" should be available on the webUI
@@ -442,7 +531,10 @@ Feature: Share by public link
     And the option to upload file should be available on the webUI
 
   Scenario: User tries to upload existing file in public link share with permissions upload-write-without-modify
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     And the public accesses the last created public link using the webUI
     When the user uploads file "lorem.txt" using the webUI
@@ -451,7 +543,10 @@ Feature: Share by public link
     And file "lorem (2).txt" should not be listed on the webUI
 
   Scenario: User tries to upload existing file in public link share with permissions read-write
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     When the user uploads file "lorem.txt" keeping both new and existing files using the webUI
@@ -459,7 +554,11 @@ Feature: Share by public link
     And file "lorem (2).txt" should be listed on the webUI
 
   Scenario: Editing the permission on a existing share from read-write to upload-write-without-modify works correctly
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file "filesForUpload/lorem-big.txt" to "/simple-folder/lorem-big.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     Then it should be possible to delete file "lorem.txt" using the webUI
@@ -471,7 +570,11 @@ Feature: Share by public link
     Then the option to delete file "lorem-big.txt" should not be available on the webUI
 
   Scenario: Editing the permission on a existing share from upload-write-without-modify to read-write works correctly
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file "filesForUpload/lorem-big.txt" to "/simple-folder/lorem-big.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     And the public accesses the last created public link using the webUI
     Then the option to delete file "lorem.txt" should not be available on the webUI
@@ -485,12 +588,13 @@ Feature: Share by public link
   Scenario: user tries to deletes the expiration date of already existing public link using webUI when expiration date is enforced
     Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes"
     And parameter "shareapi_enforce_expire_date" of app "core" has been set to "yes"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And user "user1" has created a share with settings
       | path       | lorem.txt   |
       | name       | Public link |
       | expireDate | + 5 days    |
       | shareType  | 3           |
-    When the user reloads the current page of the webUI
+    And user "user1" has logged in using the webUI
     And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
     Then the user should see an error message on the public link popup saying "Expiration date is required"
     And the user gets the info of the last share using the sharing API
@@ -499,12 +603,13 @@ Feature: Share by public link
 
   Scenario: user deletes the expiration date of already existing public link using webUI when expiration date is set but not enforced
     Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And user "user1" has created a share with settings
       | path       | lorem.txt   |
       | name       | Public link |
       | expireDate |  + 5 days   |
       | shareType  | 3           |
-    When the user reloads the current page of the webUI
+    And user "user1" has logged in using the webUI
     And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
     And the user gets the info of the last share using the sharing API
     And the fields of the last response should include
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
index 1b28d230f010..c6fa573ccc30 100644
--- a/tests/acceptance/features/webUITags/deleteTags.feature
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -49,11 +49,13 @@ Feature: Deletion of existing tags from files and folders
 
   Scenario: Delete a tag that exists for multiple file
     Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "another content" to "/a-folder/randomfile.txt"
     And user "user1" has uploaded file with content "more content" to "/randomfile-big.txt"
     And the user has created a "normal" tag with name "random"
     And the user has added tag "random" to file "randomfile.txt"
     And the user has added tag "random" to file "randomfile-big.txt"
-    And the user has browsed directly to display the details of file "randomfile.txt" in folder ""
+    And the user has browsed directly to display the details of file "randomfile.txt" in folder "a-folder"
     When the user deletes tag with name "random" using the webUI
     Then tag "random" should not exist for user "user1"
 
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
index 75ec8be67468..efb3567bc40a 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
@@ -6,15 +6,16 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created with skeleton files:
+    Given these users have been created without skeleton files:
       |username      |
       |brand-new-user|
-    And user "brand-new-user" has logged in using the webUI
 
   Scenario Outline: deleting a file in a public share of a locked folder
-    Given user "brand-new-user" has locked folder "simple-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has locked folder "simple-folder" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
@@ -27,4 +28,3 @@ Feature: Locks
       | lockscope |
       | exclusive |
       | shared    |
-
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/move.feature b/tests/acceptance/features/webUIWebdavLockProtection/move.feature
index f150e74cbaf3..a1ff5d76504d 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/move.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/move.feature
@@ -6,15 +6,16 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created with skeleton files:
+    Given these users have been created without skeleton files:
       | username       |
       | brand-new-user |
-    And user "brand-new-user" has logged in using the webUI
 
   Scenario Outline: moving a locked file
-    Given user "brand-new-user" has locked file "lorem.txt" setting following properties
+    Given user "brand-new-user" has created folder "/simple-empty-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "brand-new-user" has locked file "lorem.txt" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     When the user moves file "lorem.txt" into folder "simple-empty-folder" using the webUI
     Then notifications should be displayed on the webUI with the text
       | Could not move "lorem.txt" because either the file or the target are locked. |
@@ -29,9 +30,12 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: moving a file trying to overwrite a locked file
-    Given user "brand-new-user" has locked file "/simple-folder/lorem.txt" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "brand-new-user" has locked file "/simple-folder/lorem.txt" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     When the user moves file "lorem.txt" into folder "simple-folder" using the webUI
     Then notifications should be displayed on the webUI with the text
       | Could not move "lorem.txt" because either the file or the target are locked. |
@@ -44,9 +48,11 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: moving a file into a locked folder
-    Given user "brand-new-user" has locked file "/simple-empty-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-empty-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "brand-new-user" has locked file "/simple-empty-folder" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     When the user moves file "lorem.txt" into folder "simple-empty-folder" using the webUI
     Then notifications should be displayed on the webUI with the text
       | Could not move "lorem.txt" because either the file or the target are locked. |
@@ -61,9 +67,10 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: renaming of a locked file
-    Given user "brand-new-user" has locked file "lorem.txt" setting following properties
+    Given user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "brand-new-user" has locked file "lorem.txt" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     When the user renames file "lorem.txt" to "a-renamed-file.txt" using the webUI
     Then notifications should be displayed on the webUI with the text
       | The file "lorem.txt" is locked and can not be renamed. |
@@ -78,9 +85,11 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: renaming a file in a public share of a locked folder
-    Given user "brand-new-user" has locked folder "simple-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has locked folder "simple-folder" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
@@ -96,9 +105,12 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: moving a locked file into an other folder in a public share
-    Given user "brand-new-user" has locked file "simple-folder/lorem.txt" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has created folder "/simple-folder/simple-empty-folder"
+    And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has locked file "simple-folder/lorem.txt" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
@@ -113,4 +125,3 @@ Feature: Locks
       | lockscope |
       | exclusive |
       | shared    |
-
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
index 542fc533b60d..fecaa0c78cc1 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
@@ -6,19 +6,19 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created with skeleton files:
+    Given these users have been created without skeleton files:
       | username       |
       | brand-new-user |
-    And user "brand-new-user" has logged in using the webUI
 
   Scenario Outline: uploading a file, trying to overwrite a locked file
-    Given user "brand-new-user" has locked file "lorem.txt" setting following properties
+    Given user "brand-new-user" has uploaded file with content "original content" to "/lorem.txt"
+    And user "brand-new-user" has locked file "lorem.txt" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     When the user uploads overwriting file "lorem.txt" using the webUI
     Then notifications should be displayed on the webUI with the text
       | The file lorem.txt is currently locked, please try again later |
-    And the content of "lorem.txt" should not have changed
+    And the content of file "/lorem.txt" for user "brand-new-user" should be "original content"
     And file "lorem.txt" should be marked as locked on the webUI
     And file "lorem.txt" should be marked as locked by user "brand-new-user" in the locks tab of the details panel on the webUI
     And 1 locks should be reported for file "lorem.txt" of user "brand-new-user" by the WebDAV API
@@ -28,13 +28,16 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: uploading a file, trying to overwrite a file in a locked folder
-    Given user "brand-new-user" has locked folder "simple-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has locked folder "simple-folder" setting following properties
       | lockscope | <lockscope> |
+    And user "brand-new-user" has logged in using the webUI
     And the user has opened folder "simple-folder" using the webUI
     When the user uploads overwriting file "lorem.txt" using the webUI
     Then notifications should be displayed on the webUI with the text
       | The file lorem.txt is currently locked, please try again later |
-    And the content of "lorem.txt" should not have changed
+    And the content of file "/simple-folder/lorem.txt" for user "brand-new-user" should be "original content"
     And file "lorem.txt" should be marked as locked on the webUI
     And file "lorem.txt" should be marked as locked by user "brand-new-user" in the locks tab of the details panel on the webUI
     And 1 locks should be reported for file "simple-folder/lorem.txt" of user "brand-new-user" by the WebDAV API
@@ -44,8 +47,10 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: uploading a new file into a locked folder
-    Given user "brand-new-user" has locked folder "simple-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has locked folder "simple-folder" setting following properties
       | lockscope | <lockscope> |
+    And user "brand-new-user" has logged in using the webUI
     And the user has opened folder "simple-folder" using the webUI
     When the user uploads file "new-lorem.txt" using the webUI
     Then notifications should be displayed on the webUI with the text
@@ -58,19 +63,20 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: uploading a file, trying to overwrite a file in a locked folder in a public share
-    Given user "brand-new-user" has locked folder "simple-folder" setting following properties
+    Given user "brand-new-user" has created folder "/simple-folder"
+    And user "brand-new-user" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "brand-new-user" has locked folder "simple-folder" setting following properties
       | lockscope | <lockscope> |
-    And the user has browsed to the files page
+    And user "brand-new-user" has logged in using the webUI
     And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
     And the user uploads overwriting file "lorem.txt" using the webUI
     Then notifications should be displayed on the webUI with the text
       | The file lorem.txt is currently locked, please try again later |
-    And the content of "simple-folder/lorem.txt" should not have changed
+    And the content of file "/simple-folder/lorem.txt" should be "original content"
     And 1 locks should be reported for file "simple-folder/lorem.txt" of user "brand-new-user" by the WebDAV API
     Examples:
       | lockscope |
       | exclusive |
       | shared    |
-