We have a small number of users. We want each user to have a Public folder, files inside which are automatically visible to others (but not editable); and a Drop folder, to which others can drop files to that user (but not to list or view them). And a summary page (.md or html) that collect all users’ Public/Drop files, i.e., [Username: Public link, Drop link] on each line. This is to mimic the behavior of MacOS Server file shares.
We can create such folders manually for each user but it is tedious to maintain it. Is it possible to automatic this using occ or some kind of app?
I think group folders do not work for us here. We would like a standard set of folders for each user:
Public, Dropbox, Shared with Others, Shared to Me, My Documents, My Media … etc
The Public folder is automatically accessible to all authenticated users
The Dropbox is writable (but not viewable) to all authenticated users
This seems to be a good direction to go. But we still have have one problem: We want to do this from an admin account for all users. The logic would be something like this:
USERS-$(list-of-users)
for u in $USERS; do
su $u # impersonate $u
if ! -d ~/Public; then mkdir ~/Public; fi
if ! shared ~/Public; then share ~/Public; fi
url[$u] = $(get-shared-url ~/Public)
exit-su
done
Nextcloud docs aren’t known to be the most actual and complete, but I think it is not possible at the moment. However, there might be a workaround for you:
If you can set a password for the user upon creation (and it is thus known to you), the script could run once as the new user (“impersonating” the user). Applying this method to existing users is probably not possible if you do not set a new password for them (or you know their passwords). The user can set a new password afterwards.
There is another way of achieving this by creating all the necessary folders and shares through a dedicated sharing user that in turn shares the individual folders to the users.
This way you wouldn’t need to know the users password and could use all the API calls in an automated way with the same user credentials.
Another benefit or downside depending on your use case for public shares is that people opening them will see the dedicated user as owner, not the individual user. This way you can hide users personal information behind the dedicated user.
I’m pretty sure it is possible with cURL, but I have never used it.
Try a search for curl oauth2 or something similar. If you find a good answer that works in this setup, maybe you could post it here for others to benefit from? Thank you
EDIT: Maybe I misunderstood.
What you can do is create an app password for your script in the personal settings/security of the dedicated user and use this instead -u test.user:long_app_password
The following is supposed to create a “File drop (upload only)” share with permissions=4, but instead, it creates an “Allow upload and edit” share with actual permissions=15.
Is it possible to call functions in the file sharing app (or ocs api) in a custom app, e.g., in a post_login hook? Any pointers or examples are appreciated.
I would recommend to post this question separately, as it will probably have the chance of being seen by more people and to be answered as a new question. It is also interesting to others apart from the original caption of this thread.
Update the share’s permission with HTTP PUT after creating the share: curl -X PUT -u test.user:goodpassword -d 'permissions=4' 'https://cloud.example.com/ocs/v2.php/apps/files_sharing/api/v1/shares/<shareID>' -H "OCS-APIRequest: true"
This doesn’t seem to be affected by the bug. The shareID is returned to you upon creation of the share:
).
