GNOME Bugzilla – Bug 784172
Permission check on "thumbs" is to restrictive
Last modified: 2021-05-19 15:05:46 UTC
Hi, I tried to share a shotwell setup across several users. The goal is that all users can edit the very same photo database. To achieve this, I put ~/.local/share/shotwell/data and ~/.cache/shotwell/* to /shared and created appropriate symbolic links. I changed the ownership of /shared recursively to root:users and changed permissions to 770 for directories and 660 for files. All users are members of the group "users". Unfortunately, Shotwell does not start under this setup. The reason is a check introduced in #737747. There a test is made whether the permissions of ".cache/shotwell/thumbs" can be changed to rwx for the owner of the directory. This can be found easily in the patch that introduced this bug: https://mail.gnome.org/archives/commits-list/2015-March/msg11768.html I think that this check is to restrictive. For one, it changes the permissions silently. Furthermore, it only tests a very restricted case of write access, namely, whether for the owner some action can be performed. In my case, however, write access is granted via the group. I would be very glad if this could be fixed. I think that this can be fixed very fast by anyone knowing Vala better than I do.
Are people able to access the database concurrently? That would be calling for trouble
It's more about enabling me and my partner to edit the same photo database using the respective user account. So this way I can start sorting and editing photos when my partner is not around and vice versa. It's _not_ about concurrency.
I also faced the problem. I dont want to use shotwell concurrently. My home pc has shared between my family members. Each one has different user accounts. Only one person can login at one point of time. I just want to use the same shotwell db for all users. Due do the following reasons. 1. My photo library is huge. The shotwell db and thumbs is almost 2 GB. 2. I stored the shotwell-db in my SSD. Which I have very limited storage. 3. I dont want to scan and index on each users when ever I add a bunch of photos. The reasons 1&3 may be most common for all the desktop users. Finally I end up cloning the code and commented the "ensure_writable" and compiled installed the shotwell. It is working perfectly fine. I don't have an exposure to vala otherwise I should have submitted a patch. I think the current code is added to prevent concurrent access by multiple users. Which prevents my normal use case too. It will be great to have this fixed in some way.
I also have this issue. For a long time I have been running older releases of shotwell and successfully sharing the database between several users. I have the database on an nfs server accessible to several (ubuntu) machines. To prevent concurrent access I start shotwell with a simple script that uses a lock file to ensure only one user can access at any time. Recently I have upgraded to 0.26.4 and now have this problem. Like the original poster I want to use the group permissions, not the owner, to grant access.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/shotwell/-/issues/4851.