Auto create Public and Drop shares for each user

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?

Thank you!

An app to automatically create shares for users isn’t known to me at the moment (although that doesn’t mean it doesn’t exist :slight_smile: ).

But you could probably achieve this by using OCS API:
https://docs.nextcloud.com/server/latest/developer_manual/client_apis/OCS/ocs-share-api.html
Although this assumes basic scripting skills in PHP, Bash or others and some time.

This thread is related:

For a small number of users the first (Public read-only folder) can be done manually using Group Folders

Thank you for the tip.

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

Is this possible?

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.

BTW, creating a user (and changing a password) can be done through API calls, too.
https://docs.nextcloud.com/server/18/admin_manual/configuration_user/instruction_set_for_users.html)

Here’s a general example of how to achieve it with cURL in PHP (in this case getting the user data from nextcloud server as an admin):

And here’s how to do it in a shell:
I have prepared examples of all commands you will probably need and linked the docs.

This will fetch existing shares belonging to the “calling” user

This will create a new user

This will create an internal share of the existing folder “Photos” for the new user, shared to group “everyone” with read permissions

These will create a new folder and a public upload link for the new user

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.

This is a good idea. I’ll try it out. Thanks bpcurse.

Another related question: instead of using test.user:goodpassword for curl, it is possible to use oauth2 token based authentication?

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 :slight_smile:

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

Using the dedicated user with an app password is easier. I’ll stay with this first. Thanks a lot!

Glad I could help. Hopefully this thread will help others, too.
Good luck with your project!

I encountered an issue, maybe a bug:

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.

curl -k -u “…” -H “…” -d ‘path=/Dev/Dropbox&shareType=3&publicUpload=true&permissions=4’ -X POST ‘https://domain/ocs/v2.php/apps/files_sharing/api/v1/shares

Output:


15
<can_edit>1</can_edit>
<can_delete>1</can_delete>

If I remove publicUpload=true, I just get a “Readonly” share with permissions=1.

BTW, it seems files_sharing/api/v2/shares does not exist.

Thank you for reporting!

I will check all possible variations of permissions and publicUpload on Nextcloud 16, 17 and 18 and post the findings here.

That would be very helpful. Thanks.

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.

Working on the API tests right now.

Yes you are right, sorry for the typo. I found some other parts that needed corrections, too.

After having tested 16.0.7 and 18.0.1 RC2 I can confirm the bug. Will file an issue at github.
EDIT: Someone else ran into this before: https://github.com/nextcloud/server/issues/17504

I have found 2 workarounds you could use:

  • Set the right permissions manually in WebUI -OR-

  • 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:
nextcloud_api_create_share_response

This works. Thanks.