AGAIN unable to change any folder access rights

[trejder]

Hi all,

Exactly as in this, three years old thread. I can't change access rights to any of my shares, neither newly created, nor existing ones.

Everything as in above. ACL enabled, after change is made and applied, system informs about changing rights process, then that it is finished. System logs includes information, that rights were changed, which is (in this case) un-true. After re-entering access rights section or accessing share itself, I can clearly see that no change has been made. System up to date, with newest firmware installed.

Is there any workaround for this or new information after THREE YEARS? Or do we still deal with the same problem, though an era in IT has passed during that 36 months? Do we finally know, what can "corrupt" smb.conf file and how to fix it? Was three years enough time for QNAP support, to introduce any security or anything that will prevent this file from being corrupted?

Manually editing smb.conf or deleting it and manually recreating all my shares is not an option. Do I have any other solution?

In mentioned old thread, someone wrote, that after calling support corrupted file was fixed within seconds. How that was possible? I recall, that when I contacted support three years ago, about exactly the same problem, there wasn't even a reply and I have to help myself.

Any idea or advice here would be very warm welcomed.

Cheers,
Trejder

[QNAPPatrick]

Greetings,

It takes all of 5 minutes to restore the smb.conf file. And another few minutes to remap the share folders. I am not sure why the file gets corrupted or what causes it. If you would like to open a support ticket someone should be able to assist you with this.

QNAP is investing in expanding the support group and providing more access and available technicians than ever before. QNAP realizes that this is an important step to providing superior service and quality support.

Thank you.

[schumaku]

Hi QNAPPatrick,

Five minutes are pretty optimistic...and depends on the amount of shares and the complexity of the environment. To limit the work required - ...:

if all data if in place, let's see if the /etc/smb.conf (resp, effectively /etc/config/smb.conf) has been backed-up. This file contains - at least it should - all the information required to create the shares, the symlinks to the storage volume(s).

So either you have to edit/fix this file, or ask QNAP support to give you a hand.

Assuming you have not removed the config backup script from crontab, you find a tar archive on the first storage volume - taken every wedensday. Here the backup folder on a system using a RAID as the first volume:

[~] # ls -ls /share/MD0_DATA/.@backup_config/
8 -rw-r--r-- 1 admin administ 7043 Jun 13 03:04 0_20120613_0304.tar.gz
8 -rw-r--r-- 1 admin administ 7043 Jun 6 03:04 1_20120606_0304.tar.gz
8 -rw-r--r-- 1 admin administ 7043 May 30 03:04 2_20120530_0304.tar.gz
...

From there you should be able to restore the lost file. Any admin changes to the NAS or it's shares since the last wednesday need to be redone in case.

For safety, I suggest to restore to an alternate place, and compare:

[~] # cd /
[/] # cd /share/Public
[/share/Public] # mkdir restore
[/share/Public] # cd restore/
[/share/Public/restore] # tar -xvzf /share/MD0_DATA/.@backup_config/0_20120615_0631.tar.gz
etc/config/apache/apache.conf
etc/config/iscsi_trgt.conf
etc/config/smb.conf
etc/config/smb.conf.cksum
etc/config/uLinux.conf

Now, let's compare date and file size:

[/share/Public/restore] # ls etc/config/smb.conf
etc/config/smb.conf
[/share/Public/restore] # ls -ls etc/config/smb.conf
4 -rw-r--r-- 1 admin administ 3436 Jun 13 04:19 etc/config/smb.conf
[/share/Public/restore] # ls -ls /etc/config/smb.conf
4 -rw-r--r-- 1 admin administ 3436 Jun 13 04:19 /etc/config/smb.conf

Here it's the same ... for a restore to the one from the backup use something like that (carefully check the slashes in case):

Assuming it's reeally the smb.conf that was messed up:

[/share/Public/restore] # cp etc/config/smb.conf /etc/config/smb.conf

Once done so, restart te services:

[/share/Public/restore] # /etc/init.d/services.sh restart
...

Hope this does help curing.

Would you mind sharing the current smb.conf - before the restore?

TIA,
-Kurt.

[trejder]

Hi,

I have followed your instruction step-by-step (thank you for it). I have compared my current smb.conf file (smb.conf.this-was in attachement) with the one, stored in latest backup. I have restored file from the backup (smb.conf.this-is) and restarted services, but it brought no results -- I still can't set permissions. I'm attaching both.

smb.conf.zip

The only difference I see, is the old one contains this part in [global] section:

Code: Select all

kernel oplocks = no
mangled names = no

while, restored one from the backup, is missing this. And the old file contained doubled the same user:

Code: Select all

invalid users = "guest","guest"

for two of my shares, while in new one (restored from backup) there are no such doubles neither for these two nor for any else section (share).

At this point, I don't know, what else I could do?

[schumaku]

The only difference I see, is the old one contains this part in [global] section:

Code: Select all

kernel oplocks = no
mangled names = no

while, restored one from the backup, is missing this.

Should exist in my opinion - might lead to odd issues otherwise. Have updated the firmware since last Wednesday - or since whenever the backup copy is dated?

And the old file contained doubled the same user:

Code: Select all

invalid users = "guest","guest"

for two of my shares, while in new one (restored from backup) there are no such doubles neither for these two nor for any else section (share).

Don't know if this is causing any issues - but does not make much sense either.

At this point, I don't know, what else I could do?

Somewhat clueless for the moment, too.

Probably worth to have an eye on the other backup'ed files, like uLinux.conf for example.

[trejder]

Can other config files (except smb.conf) affect Samba / share access management?

If not, then I don't want to touch them, as my Linux knowlegde is limited. I was able to figure out smb.conf structure (very similar to Windows's INI files), so I can edit it manually. Don't know about other files congiruation.

I'll try to restore some older smb.conf files. If this does not help, I'll use old-crappy solution, three years old, with complete delete and recreate of empty smb.conf and then restore manually all system and my private shares.

BTW: How it is working about giving QNAP Support access to my NAS, so they can take a look / try to fix my problem? Should I give them login and password to my admin account (sounds very risky, after all) or is there any other support-limited access to the device (as on many routers, with limited access acounts designed directly for outer, remote support).

I don't know how does it work, because I haven't been using QNAP support much. Most problems were resolved by using this forum (mostly your answers! :]) and those three or four support request were either resolved by getting instruction (do this, there, yourself) or by no answer at all.

[schumaku]

If not, then I don't want to touch them, as my Linux knowlegde is limited.

Hard to quantify. Other config part might cause some interferences of course, too.

[quote="trejder"BTW: How it is working about giving QNAP Support access to my NAS, so they can take a look / try to fix my problem? Should I give them login and password to my admin account (sounds very risky, after all) ...[/quote] Remote desktop (i.e. TeamViewer) you can monitor, on a restricted Windows account. I would _never_ ask anyone for access credentials.

[quote="trejder"...or is there any other support-limited access to the device (as on many routers, with limited access acounts designed directly for outer, remote support).[/quote] Pretty much impossible here - considering there is only one admi (root) account.

[quote="trejder"I don't know how does it work, because I haven't been using QNAP support much. Most problems were resolved by using this forum (mostly your answers! :]) and those three or four support request were either resolved by getting instruction (do this, there, yourself) or by no answer at all.[/quote] Glad to be of some help sometimes, thank you

[strger]

Had the same troubles: can create shares, but there are no permissions set and I can´t set them afterwards.

Compared two smb.conf file with a "good" smb.conf from another nas-system.

The corrupt smb.conf file looked like this:

map hidden = no
[global]
passdb backend = smbpasswd
workgroup = WORKGROUP
security = ADS
....

The solution was to delete the first line (map hidden = no), somehow the rest wasn´t interpreted after this line.
Don´t know, where´s the line from.

Everything is ok now.

[schumaku]

The solution was to delete the first line (map hidden = no), somehow the rest wasn´t interpreted after this line.
Don´t know, where´s the line from.

That's a good discovery. What NAS model and firmware are we talking of here?

[tmt]

The solution was to delete the first line (map hidden = no), somehow the rest wasn´t interpreted after this line.
Don´t know, where´s the line from.

You actually want to move that line into the [global] section. Looks like it got misplaced by some configuration update, and being outside of any [] section confuses the samba config parser.

The QNAP configuration sets "map hidden" by default, at least in some firmware versions, to use the Unix execute bit to reflect the Windows hidden attribute. It might not break much either way, though - depends on your needs. http://www.samba.org/samba/docs/man/man ... #maphidden

[strger]

model was ts-860 pro (latest firmware), but I also had it on some other devices (ts-559).

First solved it by factory reseting the device - problem was gone.

Seems to me, QNAP isn´t much interested in solving this problem, since it is known a long time...

e.g.

http://forum.qnapclub.de/viewtopic.php? ... 1&start=10

[schumaku]

Seems to me, QNAP isn´t much interested in solving this problem, since it is known a long time...

There had been a lot of issues addressed leading to corrupted NAS config files over all the years, so "not interested" is certainly not true.

... e.g. http://forum.qnapclub.de/viewtopic.php? ... 1&start=10

This might be a caused by the lack of critical mass (very few hits on the support channels), a question of priorities, and the fact that QNAP PM unlikely follow all local language forums.

From an install base of many customer NAS, any platform, I never had this issue. However: From other effects, there might be some side effects under unknown conditions probably caused by /sbin/setcfg on older, probably corrupted, or previously manually edited config files.

[trejder]

Had the same troubles: can create shares, but there are no permissions set and I can´t set them afterwards.
map hidden = no
[global]
passdb backend = smbpasswd
workgroup = WORKGROUP
security = ADS
....

The solution was to delete the first line (map hidden = no), somehow the rest wasn´t interpreted after this line.
Don´t know, where´s the line from.

strger (and schumaku), thank you so much, for contributing this solution, as moving this line into [global] section actually saved my ** from factory-reseting entire device! :] Thank you! :]

[schumaku]

Another possible cause ... concurrent updates of the same file from two processes, i.e. after boot when detecting external devices _and_ while starting SAMBA probably?