media share set to webroot after 4.2.19 upgrade

[super_poussin]

can you try http://www.readynas.com/contributed/sup ... 4.5.04.bin

It should prevent 4.2.19 to try to create a share in a dirty way

[Horpe]

Hmm, will it reset the dirty code? :shock:
What are the prerequisitions? Rename share? Uninstall previous instances of Subsonic?
Please tell us more...

Cheers /Horpe

[super_poussin]

It will add a webroot share declaration in samba config file

[super_poussin]

You can upgrade

[iernie]

How about other of your plugins? I did not have Subsonic installed, but I did have Transmission installed, which had a folder in webroot.

[ranko1]

Yep, I too do not have subsonic installed, yet I have your Transmission and the istat addon...

I'd like to go back to the latest frontview, rather than the older 4.2.17 which is what I am using to not get this issue.

[SergV]

I have the same problem after installing transmission add-on.
Problem - media share is c/webroot, but not c/media
Reason - file /etc/frontview/samba/Shares.conf was changed:

#diff Shares.conf old/Shares.conf.old
14c14
<   path = /c/webroot
---
>   path = /c/media
19,20c19,20
<   force directory mode = 0777
<   directory mask = 0777
---
>   force directory mode = 1777
>   directory mask = 1777

If I change Shares.conf and Shares.conf-sav to orignal and I stop and restart samba, the problem resolved. But after rebooting NAS the problem exists and the configuration files are modified. It is look like this configuration files are saved and they are restored on boot. Do somebody know how to resolve the problem?
I think it is some problem in add-in installation mechanism.

[jj89]

I updated Subsonic (and Transmission) and tried a reboot. The trouble came back. I checked Shares.conf in /etc/frontview/samba and found the media share was pointing to /c/webroot.

Super-poussin mentioned that the update would add a webroot share declaration in the samba config file. My Shares.conf only had backup and media shares, but I liked where super-poussin was going.

I copied and pasted the media share stanza in Shares.conf, then modified it into a webroot share (probably easier with the GUI), did a reboot, and everything was fine.

So it would seem as long as you have a webroot share, your media share is safe.

Jim

[super_poussin]

Can you take a look in addons subdirectory (in samba dir) and see if there's a webroot.conf ?

[super_poussin]

jj89 wrote:

I updated Subsonic (and Transmission) and tried a reboot. The trouble came back. I checked Shares.conf in /etc/frontview/samba and found the media share was pointing to /c/webroot. Super-poussin mentioned that the update would add a webroot share declaration in the samba config file. My Shares.conf only had backup and media shares, but I liked where super-poussin was going. I copied and pasted the media share stanza in Shares.conf, then modified it into a webroot share (probably easier with the GUI), did a reboot, and everything was fine. So it would seem as long as you have a webroot share, your media share is safe. Jim

the addon add it in samba/addons but I discover that the main problem on 4.2.19 is that samba no more read files in addons subdir 😞

[SergV]

super-poussin wrote:
Can you take a look in addons subdirectory (in samba dir) and see if there's a webroot.conf ?

There are some files in /etc/frontview/samba/addons with configurations data for webroot and addons-config (all name may be incorrect as I have not connect to my NAS now). There is not any problem with webroot and addons-config share. The problem is with media share.
I think you can easy repeat problem:
1) Do factory default
2) Reboot
3) copy some files to media share.
3) install transmission add-in
4) reboot
5) see on media share.

[super_poussin]

I can not reset my units to factory or You will not have addons for a long time 😛

I will try to create a ddon which write everything in Shares.conf instead of using sub directory, but I clearly hope regression introduced in 4.2.19 will be solved quickly by jedi

[super_poussin]

try Missing

[super_poussin]

SergV wrote:

I have the same problem after installing transmission add-on. Problem - media share is c/webroot, but not c/media Reason - file /etc/frontview/samba/Shares.conf was changed: #diff Shares.conf old/Shares.conf.old 14c14 < path = /c/webroot --- > path = /c/media 19,20c19,20 < force directory mode = 0777 < directory mask = 0777 --- > force directory mode = 1777 > directory mask = 1777 If I change Shares.conf and Shares.conf-sav to orignal and I stop and restart samba, the problem resolved. But after rebooting NAS the problem exists and the configuration files are modified. It is look like this configuration files are saved and they are restored on boot. Do somebody know how to resolve the problem? I think it is some problem in add-in installation mechanism.

It's not an addons problem it's a 4.2.19 regression 😛

[SergV]

super-poussin wrote:
It's not an addons problem it's a 4.2.19 regression 😛

Can you explain, what do you mean?

[super_poussin]

simple :

Samba is configured to read Shares.conf but also /etc/frontview/samba/addons/addons.conf

extract of /etc/samba/smb.conf

include = /etc/frontview/samba/smb.conf.%a
include = /etc/frontview/samba/Shares.conf
include = /etc/frontview/samba/Shares.conf.%U
include = /etc/frontview/samba/addons/addons.conf

All the addons are using /etc/frontview/samba/addons/addons.conf so the Shares.conf only contains default shares and shares created by frontview

example :

/etc/samba/addons/addons.conf

include = /etc/frontview/samba/addons/addons-config.conf

and /etc/samba/addons/addons-config.conf

[addons-config]
  path = /c/addons-config
  oplocks = 1
  force create mode = 0666
  create mask = 0666
  force security mode = 0666
  force directory mode = 0777
  directory mask = 0777
  force directory security mode = 0777
  admin users = "admin","Administrator"
  writeable = 1
  guest ok = 1
  vfs objects = recycle
  recycle:versions = 1
  recycle:repository = Recycle Bin
  recycle:subdir_mode = 777
  recycle:keeptree = 1
  recycle:directory_mode = 777

sonds like samba in 4.2.19 is not reading the addons.conf and do bad things at boot
by default the nas at boot take a look in /c/ and if a directory is not declared as share it add it in Shares.conf but with 4.2.19 it does silly things

[ranko1]

So, ideas on a fix or do we have to wait till 4.2.20 (or 4.2.21) is out for them to acknowledge the fault and fix it in later firmware patches, or will it be fixed by a third-party mod?

[super_poussin]

No real fix possible on my side regarding samba, the only thing I cand do is what Missin addon is doing :
recrete share in Shares.conf instead of addons/addons.conf

It's in my opinion a temporary fix , and if it's not solved in a new firmware I will be forced to rewrite all the addons 😞

[SergV]

super-poussin wrote:
simple : Samba is configured to read Shares.conf but also /etc/frontview/samba/addons/addons.conf ...... sonds like samba in 4.2.19 is not reading the addons.conf and do bad things at boot by default the nas at boot take a look in /c/ and if a directory is not declared as share it add it in Shares.conf but with 4.2.19 it does silly things

In my case:
1) Samba is reading the addons.conf. It is all OK with "webroot" and "addon-config" share
2) Error exists in Shares.conf. (line "path = /c/media" was changed to "path = /c/webroot" for [media] section)
3) I can fix Shares.conf, then restart samba daemon and all will be OK
4) Shares.conf is changed to error state during next reboot, so problem return.

It is look like copy of samba setting is archived somewhere. If samba setting was changed in conf files, but not throw Frontview, samba configuration restored to old value during next boot.

[super_poussin]

SergV wrote:

super-poussin wrote: simple : Samba is configured to read Shares.conf but also /etc/frontview/samba/addons/addons.conf ...... sonds like samba in 4.2.19 is not reading the addons.conf and do bad things at boot by default the nas at boot take a look in /c/ and if a directory is not declared as share it add it in Shares.conf but with 4.2.19 it does silly things In my case: 1) Samba is reading the addons.conf. It is all OK with "webroot" and "addon-config" share 2) Error exists in Shares.conf. (line "path = /c/media" was changed to "path = /c/webroot" for [media] section) 3) I can fix Shares.conf, then restart samba daemon and all will be OK 4) Shares.conf is changed to error state during next reboot, so problem return. It is look like copy of samba setting is archived somewhere. If samba setting was changed in conf files, but not throw Frontview, samba configuration restored to old value during next boot.

will try to find where but I do not understand why if a webroto share is declared and a media share is correctly declared the nas do such things at boot, before it was only adding things in Sahres.conf if they are not declared

[super_poussin]

a default config file is here : /etc/default/config/etc/frontview/samba/Shares.conf

but with correct default share : backup and media


at startup the nas is looking in :

/etc/frontview/samba/Shares.conf-sav

then try to restore missing shares

[SergV]

super-poussin wrote:
will try to find where but I do not understand why if a webroto share is declared and a media share is correctly declared the nas do such things at boot, before it was only adding things in Sahres.conf if they are not declared

Yes, I will try to find, but later.
There is 2 puzzle now:
1) where is "reference" samba setting. (I think I'll find it by using Frontview backup/restore of setting)
2) Who (and where) modify Shares.conf. It is quite possible that install of add-on do it.

[super_poussin]

Shares.conf is modified by the readynas startup file

[SergV]

super-poussin wrote:
Shares.conf is modified by the readynas startup file

I write my question not qute clear. Fixed version:
2) Who (and where) modify Shares.conf in first time and change "/c/media" to "/c/webroot". There was not any "webroot" before installation of transsnission, so it is quite possible that install of add-on do it.

[super_poussin]

I take a look onf startup file in 4.2.19 and 4.2.18 regarding samba shares

they are different but both produce good code on startup and correctly add missing shares in Shares.conf