teoky

Qnap & File Permissions (Can Not Resolve Using 'normal' Methods)

Recommended Posts

Great discussion, people!  Reading this post has given me some ideas, for I, too, would greatly appreciate a solution!  Currently my network uses Synology DS414 and DS214+ at separate locations.  My goal is to sync user home folders (just the Desktop, Documents, and Downloads folders) across these devices.  My users are set up as LDAP network users via the Directory Server package.

 

Scenario:

  • Equipment includes a disk station and a mac at each location.
  • Both disk stations have a network user called 'jdoe'.
  • The user's home folder is located on '/volume1/user-homes/jdoe' for both disk stations.
  • This user's Deskop, Documents, and Downloads folders are added as shared folders between the two disk stations via the btsync WebGUI.
  • If I create a simple 'test' file at location 1 and save it to either of the three folders, the file syncs appropriately but is 'locked', as in the owner is not the current logged-in user.

Is it possible to simply strip ownership of anything synced?  Or perhaps force any file/folder to inherit ownership/permissions from the parent folder?

 

Thanks!

Share this post


Link to post
Share on other sites

I have raised these issues with a number of BTSync developers/moderators and even some were surprised that the (intended) bug exists.

I'm amazed that the BTSync software has been developed to intentionally not copy permissions when syncing new files. Surely it's a fundamental flaw that if users cannot open/modify the copied file then there is no point in using this software?

Hopefully if enough people voice their concerns it might get addressed?

Share this post


Link to post
Share on other sites

I have raised these issues with a number of BTSync developers/moderators and even some were surprised that the (intended) bug exists.

I'm amazed that the BTSync software has been developed to intentionally not copy permissions when syncing new files. Surely it's a fundamental flaw that if users cannot open/modify the copied file then there is no point in using this software?

Hopefully if enough people voice their concerns it might get addressed?

  I agree, adam1v.  Although in their defense, I think this program was meant to be an alternative to cloud storage options like Dropbox or Copy and for a single person as apposed to multiple shared directories.  Using btsync prevents personal data from being stored in a potentially insecure place.  For the home user I don't imagine this being a huge concern, but it makes sense for businesses with sensitive information.  I don't want my employer's data to be on any kind of storage media unless I say so! :ph34r:

 

I know the ability to preserve or omit permissions is possible.  Synology's Cloud Station package actually includes both options when choosing a folder to sync!  I just can't choose to sync subdirectories...otherwise I wouldn't be here :) .

 

I have an idea that might sovle the problem, but requires decentralized configuration.  How about running a script that 'chown's every file or directory periodically or at login/logoff?

Edited by unrman

Share this post


Link to post
Share on other sites

  I have an idea that might sovle the problem, but requires decentralized configuration.  How about running a script that 'chown's every file or directory periodically or at login/logoff?

 

So to go along with my own suggestion, I found a way to 'fix' this.

 

 

Manually:

  1. Open a terminal window and 'su' into an administrative user.
  2. Use the command below, replacing 'user' and 'group' and entering the appropriate path.  This will surely work for my scenario, so hopefully it can be adapted to fit others needs.  This works for me because it avoids hidden files & folders, like the all important '.sync' folder.

    sudo chown -R [user]:[group] /path/to/directory/*
  3. Check file/folder ownership with ls -la.

 

Assuming this sequence can be scripted properly, there's a way to 'hook' a script upon login using the following terminal command:

sudo defaults write com.apple.loginwindow LoginHook /path/to/script

The downside, of course, is this would have to be done for every user or machine needing syncronization.

 

I hope I've helped some.

Edited by unrman

Share this post


Link to post
Share on other sites

@adam1v, @unrman,

Sync workflow is totally normal from POV of regular Linux app - it sets process owner as files owner and umask for permissions. Though, it makes it not very useful on real life products - like running on QNAP or other products.

 

You are definitely heard, we'll see what can we do here. Thanks for the feedback.

Share this post


Link to post
Share on other sites

@adam1v

 

Not as far as I am aware... but I'm not necessarily in the the loop either. Just didn't want to leave you completely hanging since there have been no other replies...

Share this post


Link to post
Share on other sites

@adam1v

 

We ended up having to connect all users to the NAS as the user 'admin' which isn't ideal. Have just upgraded to btsync version 2.0.105 and will test this again. Will post if there is any update.

 

Did anyone else test this with version 2.0.105?

 

Thanks

Share this post


Link to post
Share on other sites

@adam1v, @unrman,

Sync workflow is totally normal from POV of regular Linux app - it sets process owner as files owner and umask for permissions. Though, it makes it not very useful on real life products - like running on QNAP or other products.

 

You are definitely heard, we'll see what can we do here. Thanks for the feedback.

 

I see this is an old thread, but I'm having the same problem with the BT Sync Plugin (2.0.124) on FreeNAS (9.3) and wondered if there was any new information. I have several CIFS users accessing the files on the server but not all users have access to all datasets/directories, based on group permissions.

 

If the application is simply working according to a umask set in the plugin jail for the btsync user, can you suggest how I can modify/override that (and the syntax) to 0007 (rwx:rwx:---)? I've tried adding umask="0007" and umask=0007 to /etc/rc.conf without success, but perhaps it should be in /usr/local/etc/rc.d/btsync?

 

====== additional background details======

On the FreeNAS, I've setup the users, groups, and datasets, including btsync(UID817):btsync(GID817). On the BTSync plugin jail, I also created btsync (UID817):btsync(GID817), as well as all of the groups with access to the datasets using the same GIDs for each one and btsync is a member of each group. In the Jail's /etc/rc.conf, I set btsync_user="btsync" and btsync_group="btsync" . The datasets are shared with the Jail using "Add Storage". As with the OP, everything seems to work, except files added through the BT Sync application are 755 (dirs) or 644 (files) when they would be 770 or 660 if added through the CIFS interface. One thing that does seem to work is that each file and directory has the correct GID (name and numerical ID) I setup for the datasets using find . -type d -exec chmod g+s {} \; from the root of the dataset (also with -type f for files), just not the correct permissions.

 

Thanks.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.