Firmware 17: Samba problems persist changes to smb.conf

[Frapl]

Hi!

I'm totally new to fvdw-sl and I installed the current version several days ago on my Lacie Network Space 2 (lite). At first it seems to be a good replace to the orginal firmware but now I have some problems I cannot resolve which worked with the original firmware out of the box.

I have two shares:
public
private

"public" is the standard guest share and "private" is tied to an user account with password.

When I connect a network drive using Windows the "public" share is always connected with the same user account as the "private" share. But when I store files on the "public" share the user of the "private" share is set as owning user in the Linux filesystem. When I try to access the files from another computer, which has only access to the "public" share, it is not possible.

I managed to fix this problem by adding the "force user" and "force group" options in the "/usr/var/smb.conf":

Code: Select all

[public]
comment = Default_share
path = /share/1000/public
writeable = yes
printable = no
public = yes
force user = nobody
force group = nobody


Here a test how the filesystem looks like before the change in the "smb.conf" (Test1) and after the change (Test2):

Code: Select all

root@lacie:/ # ls -la /share/1000/public/

drwxrwxrwx  14 root    root    4096 2018-08-23 20:09 .
drwxrwxrwx   6 root    root    4096 2018-08-22 19:01 ..
drwx------   2 private private 4096 2018-08-23 19:05 Test1
drwxrwxrwx   2 nobody  nobody  4096 2018-08-23 20:10 Test2


But after a reboot the "smb.conf" is missing these two lines.

How do I persist these changes to the "smb.conf" file?

Regards
Frapl

[fvdw]

The smb configuration file is rewritten at each boot. To add these lines the corresponding script must be adapted.
In principle linux permisions should not affect samba access, at least when using a windows pc to access the shares.
Are the pc's you are using running on linux?

Furthermore, the share public can be acessed by anyone but that doesn't necessary means that you can read or delete all content. It is a matter of choice to let different users set for instance readonly attribute to prevent that other user delete a file. But I agree with you that in a public share there should be no restriction like that. So we will discuss to include your change in the firmware. Thks for your feedback

[Jocko]

Hi Frapl,

:scratch :scratch :scratch
Maybe you made other changes, I do not have the same behaviour...

What I did :
- create a new public share
- create a folder Test1 from a laptop when no remote user account has been yet used
- create a folder Test2 from a laptop when a remote user account (Jocko) has been used previously

Then I got this linux permissions:

Code: Select all

root@Acrab:/ # ls -al /share/1100/shr_pub
total 16
drwxrwxrwx   4 root   root   4096 2018-08-24 11:18 .
drwxrwxr-x  38 root   sys    4096 2018-08-24 11:12 ..
drwxrwxrwx   2 nobody nobody 4096 2018-08-24 11:17 Test1
drwxrwxrwx   2 Jocko  Jocko  4096 2018-08-24 11:18 Test2


So you can see there is no user/group permissions limit on Test2 :scratch and then no issue later if I want to get an access on it from another environment...

[Frapl]

Hi!

Thanks a lot for the answers. :)

First of all, I use three PCs with Windows 10. My wife and I use the private share and the public share and my son has only access to the public share. After I copied all files to the NAS he complained not be able to access the files...

I tried Jocko's hint adding another public share and after that all worked well because the "group" and "other" permissions were set to "RWX" for directories and "RW" for files. So I can access each file on the public share even the private user created them.

Code: Select all

root@lacie:/ # ls -la /share/1000/public/

drwxrwxrwx  3 root    root    4096 2018-08-25 08:23 .
drwxrwxrwx  7 root    root    4096 2018-08-25 08:21 ..
drwxrwxrwx  2 private private 4096 2018-08-25 08:22 TestDir


This also worked even I deleted the addtional public share and use the default public share.

Strange...


But I also found the script which creates the "smb.conf" file and modified it. I feel more save when on the public share the forced user and group is "nobody". This works like a charm. :)

Code: Select all

nano /etc/finc/smbfunc_conf_commit.finc

Code: Select all

...
                        if (($share_ent['sharetype'] == 'public') && ($share_ent['protected'] == '0'))
                        {
                                /* generate share section */
                                $sambaconf .= <<<EOD
[{$share_ent['sharename']}]
comment = {$share_ent['desc']}
path = {$full_share_path}
writeable = yes
printable = no
public = yes
force user = nobody
force group = nobody

EOD;
...


Now I'm struggling to get the right user and group using the rsync daemon on the NAS because all files get "root" as user and group so noone can access the files after syncing files from Windows to the NAS. But I want to sync the files only once from Windows to the NAS, so I think I will go and edit the "rsync.conf" file temporarily and restart the daemon afterwards for the syncing session.

Code: Select all

nano /etc/rsyncd.conf
kill `cat /var/run/rsyncd.pid`
rsync --daemon


Code: Select all

...

[public]
        path = /share/1000/public
        comment = Default_share

        read only = no
        exclude =  /**/passwd* /**/rsyncd.secrets

        auth users = dummy

        uid = nobody
        gid = nobody

[private]
        path = /share/1000/private
        comment = Privates

        read only = no
        exclude =  /**/passwd* /**/rsyncd.secrets

        auth users = private

        uid = private
        gid = private


Code: Select all

rsync.exe -avh --chmod=ugo=rwX --password-file=pwd_dummy --progress --delete --log-file=rsync_local2lacie_public.log /cygdrive/d/Backups/LaCie_20180815/public/ rsync://dummy@192.168.178.50/public/

[Jocko]

Hi

Deepen the linux user permissions is not the right way on a nas (it is not a laptop).

On a nas, the users get access from servers (ftp, samba, nfs,...) and not directly on the fs level. So user access must be set on these servers and not on the fs level.