BTSync Plugin Permission issue

[shmixx]

Ok so I'm working on getting BTSync up and running using the plugin jails. The problem I'm running into is when I get the BTSync service up and running, trying to add a folder I've amounted to the jail is resulting in a message:

"Don't have permissions to write to the selected folder."

In all of my googling around I've seen multiple different ways people have talked through trying to fix this. I'm trying to identify the least intrusive way (aka without making lots of custom modifications I need to document) to achieve getting the proper permissions.

I have attempted to create a btsync user inside FreeNAS, map it to the user group (homeusers) that has permissions of rwx on the dataset as well. I've tried mounting the storage in the jail to /mnt/sharename or /media/sharename but have been unsuccessful with this configuration. I've also tried mapping the UID of the user to btsync inside the jail (817). I'm still not successful. Is there something else I'm missing or can someone provide some assistance?

 

[Joshua Parker Ruehlig]

Ok so I'm working on getting BTSync up and running using the plugin jails. The problem I'm running into is when I get the BTSync service up and running, trying to add a folder I've amounted to the jail is resulting in a message:

"Don't have permissions to write to the selected folder."

In all of my googling around I've seen multiple different ways people have talked through trying to fix this. I'm trying to identify the least intrusive way (aka without making lots of custom modifications I need to document) to achieve getting the proper permissions.

I have attempted to create a btsync user inside FreeNAS, map it to the user group (homeusers) that has permissions of rwx on the dataset as well. I've tried mounting the storage in the jail to /mnt/sharename or /media/sharename but have been unsuccessful with this configuration. I've also tried mapping the UID of the user to btsync inside the jail (817). I'm still not successful. Is there something else I'm missing or can someone provide some assistance?

You are on the right track but..
The btsync user you created in the FreeNAS userland being in a group doesn't help the process in the jail which only sees matching UIDs/GIDs and has a different user/group database as the host FreeNAS system. The process in the jail's runs as btsync (UID 817) which isn't in the same group(s) as the user you created in FreeNAS, at least from the jail's perspective.

You can either...

1. change the permissions of the dataset to allow any user write to it
2. change the group of the dataset to a group with GID 817
3. add the btsync user in the jail to a matching group as the dataset's group owner. This would probably also mean creating a group with a matching GID in the jail.

If you are interacting with the data with other program as well as btsync I recommend option 3, but it does require a few command be run on the commandline.

 

[shmixx]

Joshua - THANK YOU!!!

This has been plaguing me for too long. I think you finally illustrated the piece I was missing. It's not about mimicking the user and UID from the jail in the FreeNAS system, it's about mimicking the group and GID inside the jail. Because I'm using group permissions on my dataset to grant access to users, and not wanting to specify the btsync user as owner, it's the GID that is essentially granting the permissions. Since this GID does not exist in the jail, and the btsync user is not part of said group (GID) then it was being denied access when attempting to touch the mount point. This makes total sense now.

For those who may have had the same issue, here are the steps I followed to get this working inside the jail;

1. Open the Jails view in FreeNAS GUI, select the jail (btsync_1 ing mcase) and click on the Shell button in the bottom right. Alternatively you can SSH into the FreeNAS box and enter into the jail interface this way.
2. In the shell window that opens run the following:
   1. pw groupadd <groupname> -g <GID>
   2. pw usermod <user> -G <groupname>
   3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)
3. Close the Shell window in the browser
4. Go to the plugin menu and turn the service for the plugin off
5. Select the Jails again, select the intended jail, and choose to Stop the jail from the lower toolbar
6. Once this has completed, choose to Start the jail
7. Finally go to the plugins section again, and start the service for the plugin

Upon completing these steps, I was able to get my btsync to successfully get access to the datasets I needed it to.
Keep in mind this does not affect the security of the datasets from external access, but if someone was to gain access to one of the jails directly they would have backwards access into your dataset based on the permissions you granted the user in the jail. Just a thought on the security side to keep in mind using this workaround.

 

[shmixx]

BTW - is there a way for a mod or someone to mark this as Solved now instead of Problem?

 

[Joshua Parker Ruehlig]

Joshua - THANK YOU!!!

This has been plaguing me for too long. I think you finally illustrated the piece I was missing. It's not about mimicking the user and UID from the jail in the FreeNAS system, it's about mimicking the group and GID inside the jail. Because I'm using group permissions on my dataset to grant access to users, and not wanting to specify the btsync user as owner, it's the GID that is essentially granting the permissions. Since this GID does not exist in the jail, and the btsync user is not part of said group (GID) then it was being denied access when attempting to touch the mount point. This makes total sense now.

For those who may have had the same issue, here are the steps I followed to get this working inside the jail;

1. Open the Jails view in FreeNAS GUI, select the jail (btsync_1 ing mcase) and click on the Shell button in the bottom right. Alternatively you can SSH into the FreeNAS box and enter into the jail interface this way.
2. In the shell window that opens run the following:
   1. pw groupadd <groupname> -g <GID>
   2. pw usermod <user> -G <groupname>
   3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)
3. Close the Shell window in the browser
4. Go to the plugin menu and turn the service for the plugin off
5. Select the Jails again, select the intended jail, and choose to Stop the jail from the lower toolbar
6. Once this has completed, choose to Start the jail
7. Finally go to the plugins section again, and start the service for the plugin

Upon completing these steps, I was able to get my btsync to successfully get access to the datasets I needed it to.

Keep in mind this does not affect the security of the datasets from external access, but if someone was to gain access to one of the jails directly they would have backwards access into your dataset based on the permissions you granted the user in the jail. Just a thought on the security side to keep in mind using this workaround.

Glad you got it working. I think you are proposing the ideal solution and I don't see it as a security issue. The dataset is only open to read/write from users in a certain group. You're only adding the dataset in jails that explicitly need access to them. I think you are poking the smallest possible hole, which is absolutely necessary to allow writing to the dataset.

 

[Zachary Johnson]

sorry. Shell button in bottom right? I can't figure out where that is. I have the shell button on the left side bar, but nowhere else. Thanks

 

[shmixx]

Zach - yes if you click on the Jails button on the ton bar, it will bring the main window to the Jails list. Click on the Jail in question and you will see at the bottom of the window a small bar of icons will appear. The last one to the right in the row, will be the Shell button. Clicking this will pop you open a Shell window inside the jail rather than having to fuss with SSH'ing into the server and entering the jail that way. Just a little shortcut.

 

[Zachary Johnson]

Not to hijack your thread, but have you guys heard of permissions issues like this interfering with the ability to even switch a plugin to 'on'? I had mine working, now only a couple can flip to on, and i've even re-installed them all. Sorry, this just seemed like the most relevant thread I'd come across.

 

[Joshua Parker Ruehlig]

Not to hijack your thread, but have you guys heard of permissions issues like this interfering with the ability to even switch a plugin to 'on'? I had mine working, now only a couple can flip to on, and i've even re-installed them all. Sorry, this just seemed like the most relevant thread I'd come across.

If you changed the owner of the datadirectory ( mine use /usr/pbi/plugin/etc/plugin/ ) of a plugin it's possible it would refuse to start. But normal operation shouldn't cause this. I hope 9.2.1 fixes alot of the issues people have been having with stuff breaking in the GUI

 

[Zachary Johnson]

Sorry, new guy here. 9.2.1? When is that coming?

 

[Joshua Parker Ruehlig]

Sorry, new guy here. 9.2.1? When is that coming?

Probably in the coming week(s)

http://forums.freenas.org/threads/f...e-candidate-now-available-for-download.18172/

 

[Tom7320]

I'm sorry to bring this up again, but I still have a similar problem which I don't know how to solve...
I also installed BTSync plugin. For storage I mounted /mnt/vol1/BTSync (FreeNAS) to /mnt/BTSync (Jail) which works quite well. To gain access to the files of the BTSync folder I also created a cifs share to /mnt/vol1/BTSync. Now I do have read access to this share but I can't delete files and folder within this dir. This seems logical to me, since the permissions (from a FreeNAS point of view) are:

Code:

drwxr-xr-x  3 817  wheel    3 Feb  8 18:01 test/

Thus I tried to change the btsync user in the jail. I wanted to give this user uid and gid of a user that exists on FreeNAS. This did not work. The jail just didn't start anymore... :-(

I also tried to put the FreeNAS user in the wheel group. This also did not work because the wheel group does not have write permission to the files and folder created by BTSync.

I'm looking for an easy way to grant read and write (delete) access to my FreeNAS users via cifs shares to the BTSync files and folders....

Help would be really apprecited!

THX!

 

[Joshua Parker Ruehlig]

I'm sorry to bring this up again, but I still have a similar problem which I don't know how to solve...
I also installed BTSync plugin. For storage I mounted /mnt/vol1/BTSync (FreeNAS) to /mnt/BTSync (Jail) which works quite well. To gain access to the files of the BTSync folder I also created a cifs share to /mnt/vol1/BTSync. Now I do have read access to this share but I can't delete files and folder within this dir. This seems logical to me, since the permissions (from a FreeNAS point of view) are:

Code:

drwxr-xr-x  3 817  wheel    3 Feb  8 18:01 test/

Thus I tried to change the btsync user in the jail. I wanted to give this user uid and gid of a user that exists on FreeNAS. This did not work. The jail just didn't start anymore... :-(

I also tried to put the FreeNAS user in the wheel group. This also did not work because the wheel group does not have write permission to the files and folder created by BTSync.

I'm looking for an easy way to grant read and write (delete) access to my FreeNAS users via cifs shares to the BTSync files and folders....

Help would be really apprecited!

THX!

To change the user btsync is running as you cound set 'btsync_user' in /etc/rc.conf.local (i think), and change the ownership of the /usr/pbi/btsync-amd64/etc/btsync directory.

Or.. you could add a group in the Jail userland that has matching GID as the CIFS user in the FreeNAS userland. Then, in the jail, add the btsync user to the said group.

 

[shmixx]

Tom - I'm not sure I'm fully understanding the issue as it sounds like you've muddied two concepts into one problem. Let's try to break it down:

Part 1 - Permissions/Groups/Users in your FreeNAS system and on your datasets - this affects CIFS sharing (I assume you have the Unix permissions set, not the Windows/Mac permissions. If you have Windows/Mac, I can't help you)

• Permissions on your network via CIFS (aka through the FreeNAS interface)
  • Ensure you have created a user for yourself inside FreeNAS (for ex user1) GUI
  • If you will be granting multiple users access and still want to block others (aka, user1 and user2 and user3, but not EVERYONE (or a guest account for that matter) - be sure to create a Group and add the users needed to the group inside your FreeNAS GUI
  • If you don't really mind or think people will be getting on your local network to get access to the system or don't really care as much about creating a locked down system (read: more secure), then you can simply modify the permissions as I'll describe next, to simply allow RWX on User/Group/Everyone
• Setting the permissions in FreeNAS
  • For the individual user setting, you simply need to make sure in the Dataset permissions view, that your Owner (user) is listed as your user and give the owner column in the permissions boxes, RWX are selected
  • For the group config, you need to make sure in the Dataset permissions view, that your Group is listed in the Owner (group) selection box and in the group column in the permissions boxes, RWX are selected
  • If you want to leave it wide open, then you can simply check off RWX in all 9 selection boxes in the permissions view. Additionally I believe most people then set the owner user/group as nobody/nogroup. This I believe helps with guest access if you enable this in the CIFS share options.

Part 2 - Permissions inside your BTSync jail

• By default most Jails will create a user for their service to run under. They don't generally use built-in accounts. In the case of BTSync, it's user is btsync. It also belongs to a primary group named btsync.
• Since you mentioned trying to modify permissions and the jail wouldn't start properly or the service wouldn't start properly, I suggest 2 things:
  • Try reloading your web view. I find on occasion that sometimes something won't appear to have started or appeared properly, but it did. Reloading the browser fixes these simple missteps.
  • Alternately, you may have modified the Primary Group of the user account inside the jail. This primary group may be used in some way to assign the btsync user permissions/privileges to do things inside the jail. Aka local ACL's inside the jail.
• To set the permissions as described above in my previous post that Joshua helped point me in the right direction, just follow the instructions. Be sure to use the -G and -g appropriately. The case of them makes sense. For example using the lowercase in place of the upper case, I believe will replace the Primary Group. You don't want to be modifying the Primary group inside the jails as far as I'm concerned. There is no need.
• Lastly, the example I gave perviously of setting the permissions, assumes your permissions are configured as I've just described in this post.

 

[Tom7320]

Thank you very much for your comprehensive answers!!!! I must admit that I was in a hurry so I simply installed BTSync on another Linux-VM in my network and configured it the way I wanted it to be. This was a matter of a couple of minutes so I chose to do it that way rather than fiddling around with permissions.....
Yes, shmixx, of course you are right! I was primary talking about the BSD permissions and the interference of the permissions between the jail and the host. The second step would have been talking about Samba shares.....

THX again!

 

[Shark88]

I am facing the same problem right now. I tried to get permissions to the mounted shares with the commands posted by shmixx:

1. pw groupadd <groupname> -g <GID>
2. pw usermod <user> -G <groupname>
3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)

As far as I understand it, the permissions from the inside of the jail need to be mapped with the FreeNas groups or users.
1. But which group name and which GID do I have to put in this command? The group created in the FreeNas group list which has access to the data share?
2. Which user should I add to this group inside the jail? btsync??
I hope somebody could clarify it for me again. Thanks!

 

[Joshua Parker Ruehlig]

I am facing the same problem right now. I tried to get permissions to the mounted shares with the commands posted by shmixx:

1. pw groupadd <groupname> -g <GID>
2. pw usermod <user> -G <groupname>
3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)

As far as I understand it, the permissions from the inside of the jail need to be mapped with the FreeNas groups or users.

1. But which group name and which GID do I have to put in this command? The group created in the FreeNas group list which has access to the data share?
2. Which user should I add to this group inside the jail? btsync??
I hope somebody could clarify it for me again. Thanks!

1. name doesn't matter, GID should match "The group created in the FreeNas group list which has access to the data share"
2. btsync

The files and directories would also need at minimum 660 permissions

 

[diedrichg]

For those who may have had the same issue, here are the steps I followed to get this working inside the jail;

1. Open the Jails view in FreeNAS GUI, select the jail (btsync_1 ing mcase) and click on the Shell button in the bottom right. Alternatively you can SSH into the FreeNAS box and enter into the jail interface this way.
2. In the shell window that opens run the following:
   1. pw groupadd <groupname> -g <GID>
   2. pw usermod <user> -G <groupname>
   3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)
3. Close the Shell window in the browser
4. Go to the plugin menu and turn the service for the plugin off
5. Select the Jails again, select the intended jail, and choose to Stop the jail from the lower toolbar
6. Once this has completed, choose to Start the jail
7. Finally go to the plugins section again, and start the service for the plugin

Thank you!!!

1. name doesn't matter, GID should match "The group created in the FreeNas group list which has access to the data share"
2. btsync

The files and directories would also need at minimum 660 permissions

Thank you!!!

 

[gjonm]

Joshua - THANK YOU!!!

This has been plaguing me for too long. I think you finally illustrated the piece I was missing. It's not about mimicking the user and UID from the jail in the FreeNAS system, it's about mimicking the group and GID inside the jail. Because I'm using group permissions on my dataset to grant access to users, and not wanting to specify the btsync user as owner, it's the GID that is essentially granting the permissions. Since this GID does not exist in the jail, and the btsync user is not part of said group (GID) then it was being denied access when attempting to touch the mount point. This makes total sense now.

For those who may have had the same issue, here are the steps I followed to get this working inside the jail;

1. Open the Jails view in FreeNAS GUI, select the jail (btsync_1 ing mcase) and click on the Shell button in the bottom right. Alternatively you can SSH into the FreeNAS box and enter into the jail interface this way.
2. In the shell window that opens run the following:
   1. pw groupadd <groupname> -g <GID>
   2. pw usermod <user> -G <groupname>
   3. tail /etc/group (this step is to verify that at the bottom of the list you see the group you just created with the proper GID, and the user that needs to be in that group listed next to it)
3. Close the Shell window in the browser
4. Go to the plugin menu and turn the service for the plugin off
5. Select the Jails again, select the intended jail, and choose to Stop the jail from the lower toolbar
6. Once this has completed, choose to Start the jail
7. Finally go to the plugins section again, and start the service for the plugin

Upon completing these steps, I was able to get my btsync to successfully get access to the datasets I needed it to.
Keep in mind this does not affect the security of the datasets from external access, but if someone was to gain access to one of the jails directly they would have backwards access into your dataset based on the permissions you granted the user in the jail. Just a thought on the security side to keep in mind using this workaround.

The pain is over! Thank you for posting.

 

[Bobbiek04]

Sorry to bring up an old thread, but I am having the same issue but only for a few of the datasets within a share that I have given the btsync user access to. Any ideas what is going on?