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

[unrman]

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!

[adam1v]

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?

[unrman]

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!

 

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 October 23, 2014 by unrman

[unrman]

  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 October 24, 2014 by unrman

[RomanZ]

@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.

[lastnick]

Hi teoky, did you advance in this issue? I exactly have the same problem and did not find a workaround yet.

[drego85]

Hi teoky, did you advance in this issue? I exactly have the same problem and did not find a workaround yet.

Visit My Blog and translate this article: http://www.oversecurity.net/2015/01/20/installiamo-bittorrent-sync-sul-nas-qnap/

Works well

[adam1v]

Has there been any updates towards the user permission replication on NAS devices?

[Shaav]

@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...

[teoky]

@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

[raidoh]

@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.