Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transfer ownership fails if storage exists with user password #26530

Closed
PVince81 opened this issue Nov 2, 2016 · 8 comments · Fixed by #26533
Closed

Transfer ownership fails if storage exists with user password #26530

PVince81 opened this issue Nov 2, 2016 · 8 comments · Fixed by #26533

Comments

@PVince81
Copy link
Contributor

PVince81 commented Nov 2, 2016

Steps

  1. Create two users "user1" and "user2"
  2. Setup an external storage "/sftp" with type "SFTP" and pick the mode "Log-in credentials, save in session"
  3. Login as "user1" and see that the "/sftp" mount can be accessed
  4. Create a local folder "/test" (NOT inside the mount point)
  5. Run the transfer ownership command for "user1" to "user2".

Expected

Only folder "test" (and skeleton files if they were there) was transferred to "user2"

Actual

Nothing transferred, error during mounting:

                                            
  [OCP\Files\StorageNotAvailableException]  
  No session credentials saved              
                                            

                                            
  [OCP\Files\StorageNotAvailableException]  
  No session credentials saved              
                                            

                                                                         
  [OCA\Files_External\Lib\InsufficientDataForMeaningfulAnswerException]  
  No session credentials saved                                           

Versions

Observed on 9.0.5

Unavailable storages must be ignored during transfer.
Even better: any external storages cannot be transferred anyway, so don't bother mounting them!

@PVince81
Copy link
Contributor Author

PVince81 commented Nov 2, 2016

cc @DeepDiver1975

@PVince81
Copy link
Contributor Author

PVince81 commented Nov 2, 2016

@kawohl @cdamken please let me know whether the case from #23881 (comment) shows similar errors to what I posted above.

Fix for this is here: #26533

@cdamken
Copy link
Contributor

cdamken commented Nov 3, 2016

@PVince81 Sofar I remember the error had nothing to do with the credentials.

The configuration in WND that I have is:
wnd does not work

@PVince81
Copy link
Contributor Author

PVince81 commented Nov 3, 2016

@cdamken okay, thanks for the details.

I'm able to reproduce the issue with OC 9.0.5, steps:

  1. Create two users "user1" and "user2", but never login with those
  2. Setup WND with "Log-in credentials, save in database"
  3. Transfer files either from "user1" to "user2" or the reverse.

Expected result

Transfer succeeds

Actual result

# sudo -uwwwrun ./occ files:transfer-ownership user1 user2
Analysing files of user1 ...
    0 [>---------------------------]

  [OCP\Files\StorageNotAvailableException]  
  No login credentials saved                



  [OCP\Files\StorageNotAvailableException]  
  No login credentials saved                



  [OCA\Files_External\Lib\InsufficientDataForMeaningfulAnswerException]  
  No login credentials saved                                             

@PVince81
Copy link
Contributor Author

PVince81 commented Nov 3, 2016

Tried the same scenario with the fix from #26533 and the error disappears, the transfer completes. Note that the patch doesn't apply on top of OC 9.0 due to file name differences, but we will provide a backport.

@cdamken
Copy link
Contributor

cdamken commented Nov 4, 2016

@PVince81 is the problem fixed also when the external storage is AWS S3?

@PVince81
Copy link
Contributor Author

PVince81 commented Nov 5, 2016

@cdamken the fix is independent from storage type, so it should work for S3 as well

@lock
Copy link

lock bot commented Jul 31, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants