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

Ownership of share-folders inside gh folder #319

Closed
michaepr opened this issue Oct 31, 2023 · 6 comments
Closed

Ownership of share-folders inside gh folder #319

michaepr opened this issue Oct 31, 2023 · 6 comments
Labels

Comments

@michaepr
Copy link

Hello,

I'm experience some permission problems and I was wondering if the order in which I set up greyhole could be improved.

I initially set up three hard drives which are mounted at /mnt/disk1, /mnt/disk2 and /mnt/disk3. I create a folder gh in each of them and a folder shares in one of them, eg in disk2. After adding shares in the setup wizard, the corresponding folders are created in /mnt/disk2/shares. So for example if I add a share called ShareA then folder /mnt/disk2/shares/ShareA is created (I use default options for the shares except for adding wide links = yes). At this point no ShareA subfolders are created in the gh folders. Then I run chown -R main_user:users /mnt/disk1 (same for disk2 and disk3) so each of my samba users has access to the drives.

Now user user1 mounts ShareA and creates a folder Subfolder1 inside. Greyhole then creates ShareA (and Subfolder1) in some of the gh folders. But the newly created folder ShareA is now owned by user1:user1 so other users don't have access to the share (because the symlink in /mnt/disk2/shares/ShareA... points to the folder owned by user1). I then have to rerun the chown command on the gh folder so all users can access the subfolder belonging to ShareA (but not Subfolder1). This has to happen everytime a new ShareX folder is created inside a gh folder.

My approach doesn't feel very efficient. (I think it might work well if folder ShareA was created in each gh folder upon creation of the share.) What is the recommended/better way of setting up greyhole with correct permissions? I want the ShareX folders to be accessible to all users but the subfolders (like Subfolder1) only to the user that created them.

Thanks for your help!

@gboudreau
Copy link
Owner

Greyhole simply replicates the ownership & permissions of the files & folders created by Samba, so your permission problem is more Samba & Linux-related than Greyhole-related.

You probably want to configure Linux so that when user1 creates a folder, it is owned by user1:users, instead of user1:user1. I know you could do that by changing the main group of user1 ; not sure if there are other ways.

Not sure if you can configure Samba to do that without changing it in Linux. Samba has options for create mask and create mode, in shares config, but I don't think you can ask Samba to control which GID will be used for new files & folders.

On my server, my user is configured like this:

$ id gb
uid=1000(gb) gid=100(users)

And my Samba shares:

[meh]
    path = /mnt/hdd8/samba-shares/meh
    writeable = yes
    browseable = yes
    create mask = 0775
    force create mode = 0664
    directory mask = 0775
    force directory mode = 0775
    dfree command = /usr/bin/greyhole-dfree
    vfs objects = greyhole

So when I create a folder in Linux, it's owned by gb:users, but has permission drwxr-xr-x (aka 755).
Since I want my shares to be writable my other users too, I configured Samba to use 755 (and 644 for files) instead.

@michaepr
Copy link
Author

Thanks for your fast reply!

Ok, I see what you're saying about replicating samba's ownership/permissions. I know nothing about the implementation details of Greyhole so forgive me if my follow-up question seems naive.

In the shares folder (eg /mnt/disk2/shares) the (sub-)folders for each of the shares (eg /mnt/disk2/shares/ShareA) are owned by root with permissions 777. That seems reasonable to me. The subfolders of /*/gh (eg /mnt/disk1/gh/ShareA) effectively mirror the shares folder but from what I've seen they are owned by a random user (whoever first saves something in the share). Conceptually I find that a bit odd, why should a random user own them? Wouldn't it make sense to treat these folders differently -- eg by also having them owned by root with permissions 777 -- and to replicate samba's ownership/permissions for the subfolders that are actually created by users (such as /mnt/disk1/gh/ShareA/Subfolder1)? In this specific case folder /mnt/disk1/gh/ShareA is only created for user1 as a side-effect because it didn't exist and because it's necessary so that /mnt/disk1/gh/ShareA/Subfolder1 can be created. Since this folder doesn't really have anything to do with user1 why should they own it?

I'm assuming that having /mnt/disk1/gh/ShareA owned by root with permissions 777 would allow for more flexible set-ups. Eg what I'm trying to do would probably work out of the box (and I guess everything that currently works would still work).

What do you think? (I hope I've explained myself clear enough, let me know if not)

@gboudreau
Copy link
Owner

This definitely shouldn't happen. The ownership & permission of all folders inside the storage pool drives (gh folders) should replicate the ownership & permission of the corresponding folders from the landing zone (Samba shares folders).
There might be a bug where this is not done for the share's root folders. I'll try to replicate, and fix it if it is indeed a bug.

As a workaround, you could simply create all your shares manually inside each storage pool drives, and give those folders the proper ownership + permissions.

@michaepr
Copy link
Author

michaepr commented Nov 5, 2023

Ok great, thanks for your work on this! Eventually I did manage to get the setup I was looking for by setting directory mask = 0771 when creating the share.

@gboudreau gboudreau added Bug and removed Support labels Nov 5, 2023
@gboudreau
Copy link
Owner

A fix for this will be included in the next release. Thank you for your time.

@gboudreau
Copy link
Owner

Version 0.5.21 includes this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants