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.

Sign up for GitHub

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

Jump to bottom

File was not found because wrong user id #110

Closed
yharroch opened this issue Apr 2, 2022 · 8 comments · Fixed by #116
Closed

File was not found because wrong user id #110

yharroch opened this issue Apr 2, 2022 · 8 comments · Fixed by #116
Assignees
@R0Wi
Labels
needs more information Further information is requested

Comments

@yharroch
Copy link

yharroch commented Apr 2, 2022

Hi there,
thanks a lot for your work. It'll be heaven when I'll be able to scan to PDF with 'fulltextsearch'.
I installed 1.23.2 version on nextcloud 23.0.3 but i have a "Could not process file '/USER_1/files/_SCAN/CCF01042022_0001_OCR.pdf'. File was not found".

I think the problem is that the real owner of the file is another user. The processed file is in a shared folder.
Workflow_ocr look for the current user instead of the owner. The workflow cannot proceed because it look in the wrong data folder. Could you fix this switching 'user' to 'owner' ?
@R0Wi
Copy link
Contributor

R0Wi commented Apr 2, 2022

So the problem occures if you share a folder via share link and some "unknown" user uploads a PDF-file matching your workflow? Is that correct so far?

I think we already use the owner of the file (see https://github.com/R0Wi/workflow_ocr/blob/5aa118e02a37dbd48a7fcc8b97441a98dde0437e/lib/Operation.php#L125) to impersonate when processing the file asynchronously.

I just created a folder link and uploaded a PDF file which was processed correctly by the app. So i think we need some more information here. Could you please try to temporarily set your loglevel to DEBUG (0), reproduce the process and share your server logs with us?

@R0Wi R0Wi self-assigned this Apr 2, 2022
@R0Wi R0Wi added the needs more information Further information is requested label Apr 2, 2022
@yharroch
Copy link
Author

yharroch commented Apr 3, 2022

Yes. I thought the same when i looked for it in the source code. I think it comes from the getUID function that looks for the last modification user but not the real owner.

To clarify, i've a folder named '_scans' shared by 'admin_user'. This folder is the main folder where my scanned files are saved. It means whether you're 'user_1' or 'user_2', every scanned files are sent in this shared folder.
So, when user_1 or user_2 scan and create a new file, it goes in the 'admin_user' data folder which directory is /nextcloud/data/'admin_user'/files/_scans/.
But [workflow_ocr] look for a file in /nextcloud/data/'user_1'/files/_scans/ because 'user_1' was the one who scanned and created the file. Thus, this new file cannot be found because it is not in this directory.

[workflow_ocr] Warning: Could not process file '/_'user_1'_/files/_SCAN/CCF01042022_0001_OCR.pdf'. File was not found
by _admin_user_ at 2022-04-02T15:04:07+00:00

I changed usernames for security reasons but this logs is this only one I've got when the process runs

@yharroch
Copy link
Author

yharroch commented Apr 3, 2022

FYI, I tried to run the process in another folder owned by 'user_1'. It worked like a charm !
I was really happy and impressed. Well done for the App !

@R0Wi
Copy link
Contributor

R0Wi commented Apr 3, 2022

Thanks for clarification. So we're talking about a folder which is owned by a user and which is "internally" shared to other users, right? So no external (link) share to "anonymous" users and no groupfolders involved?

Will try to reproduce this but i think your hint that it could be related to the getUID is a good point, thanks!

@yharroch
Copy link
Author

yharroch commented Apr 3, 2022

Yes. Exactly.
Shared internally on the same nextcloud server.
Don't shared in a group but with 2 users.

@R0Wi
Copy link
Contributor

R0Wi commented Apr 13, 2022 •
edited
Loading

Didn't have the time to dig deeper, yet but i'll keep you up to date 👍

R0Wi added a commit that referenced this issue May 7, 2022
@R0Wi
Use uid from filepath
879aa5c 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 7, 2022
@R0Wi
Use uid from filepath
8b4f8aa 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
@R0Wi R0Wi mentioned this issue May 7, 2022
Merged
@R0Wi R0Wi linked a pull request May 7, 2022 that will close this issue
Use uid from filepath #116
Merged
R0Wi added a commit that referenced this issue May 7, 2022
@R0Wi
Use uid from filepath
6d75d1f 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 7, 2022
@R0Wi
Use uid from filepath
b30fb27 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
@R0Wi
Copy link
Contributor

R0Wi commented May 7, 2022

@yharroch the user id is now determined by the file path so i think this should be consistent. #116 tackles this issue. It would be great if you could give us some feedback by installing the temporary app artifact from https://github.com/R0Wi/workflow_ocr/suites/6415613489/artifacts/234051766. Please let us now if you need further assistance. Thank's for your help!

@R0Wi R0Wi closed this as completed in #116 May 11, 2022
R0Wi added a commit that referenced this issue May 11, 2022
@R0Wi
Use uid from filepath (#116)
3b0f56a 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 11, 2022
@R0Wi @github-actions
Use uid from filepath (#116)
65bed02 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 11, 2022
@R0Wi
Use uid from filepath (#116) (#117)
adc51dd 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 11, 2022
@R0Wi
Use uid from filepath (#116)
aa4ffff 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
R0Wi added a commit that referenced this issue May 11, 2022
@R0Wi
Use uid from filepath (#116) (#118)
73cb6cd 
* Read user id from filepath, don't use fileowner
* Use new \OCP\BackgroundJob\QueuedJob base class
* Closing #110
@R0Wi
Copy link
Contributor

R0Wi commented May 23, 2022

Included in v1.24.1 and v1.23.3 😎

@R0Wi R0Wi mentioned this issue Oct 13, 2024
Open
@XueSheng-GIT XueSheng-GIT mentioned this issue Dec 14, 2024
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@R0Wi R0Wi

Labels
needs more information Further information is requested
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use uid from filepath R0Wi-DEV/workflow_ocr
2 participants
@R0Wi @yharroch