NSS6000 - lost access to some folders and files on a share

Unanswered Question

We are using the NSS6000 and created shares and everything worked fine.

However now access to a few (but important) files and folders is lost. Reentering user/password information doesn't help. Adding new users with full rights to the share doesn't help, It seems that no changes on the share level are being forwarded to these files and folders. Problems occur on CIFS and FTP protocol.

I upgraded to firmware 1.16 from 1.14, but this didn't fix it.

I reset it several times, didn't help.

Due to the problems of the backup (see other threads), I don't have backup yet.

In general the NAS seems to be very slow. The internet explorer sometimes has time out errors, after having changed settings.

Who knows what to do?

Regards

Joachim

Log:

this might help ...

Nov 21 17:42:11 CISCONAS1 smbd[7489]: [2009/11/21 17:42:11, 1] smbd/service.c:close_cnum(1231)
Nov 21 17:42:11 CISCONAS1 smbd[7489]: sq-srv (192.168.10.11) closed connection to service projekte
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] smbd/server.c:main(944)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: smbd version 3.0.28a started.
Nov 21 17:43:34 CISCONAS1 smbd[7898]: Copyright Andrew Tridgell and the Samba Team 1992-2008
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_administrators(792)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_administrators: Failed to create Administrators
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_users(758)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_users: Failed to create Users
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_administrators(792)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_administrators: Failed to create Administrators
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_users(758)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_users: Failed to create Users
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_administrators(792)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_administrators: Failed to create Administrators
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 0] auth/auth_util.c:create_builtin_users(758)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: create_builtin_users: Failed to create Users
Nov 21 17:43:34 CISCONAS1 smbd[7898]: [2009/11/21 17:43:34, 1] smbd/service.c:make_connection_snum(1034)
Nov 21 17:43:34 CISCONAS1 smbd[7898]: sq-srv (192.168.10.11) connect to service projekte initially as user SQ\uk (uid=11121, gid=10513) (pid 7898)
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alejandro Gallego Sun, 11/22/2009 - 20:03

I will start from the end of your post and work my way back up.

The log that you posted unfortunately is not very helpful, as all the log is saying is that the user "uk" which belongs to the domain "SQ" was able to log in. All the other stuff prior says that the NSS was not able to map user "uk" to the local user database.

One caviat to adding users to shares which have already been defined is, it doesn't change the originally defined CIFS permissions of that share. For example if you make a share called 'SQL' and you assign 'Domain Users' and 'Domain Admins' to the read/write groups; those permissions are set for the life of the share. Adding individual users to that share may help matters if you find yourself not being able to access it.

Now for some questions to get a better idea as what is going on:

1. Was the new FW update applied twice; back to back?

2. When you find that you are not able to access the share, what is the error that is being returned?

3. Have you checked the NTP settings on the NSS and made sure that the time servers are pointing to your DC?

4. Have you tried to use another browser, like Firefox instead of IE; and does the problem remain?

Please download and post your log files, or post the 'boot' log, 'dmesg' and 'smb' logs. Also to make sure we get a good history, from the logs page ensure that "Store Logs Locally" is enabled.

Keep us posted.

It seems, that the creator of the folder has still access to the files. Is there no possibility to rebuild the rights for "old" files. I had expected to do so, when resetting the NSS6000.

The response time is a problem regardless of the browser. I also think, that some access problems relate to a to busy NSS6000. Acronis reports, that the device becomes unaccessable during backup. Retry helps, but ...

I have cleard all logs, rebooted the device. started a backup and will post the logs when it is finished. May be it is not busy, but looses connectivity.

The load from users should be very little.

The firmware was uploaded only once.

Information on the NSS6000:


Serial Number7PJ00G402163

Firmware Version1.16-3 (Mon, 08 Jun 2009 14:10:09 +0000)

Joachim

Alejandro Gallego Tue, 11/24/2009 - 14:16

Since the NSs is joined to a domain (i believe it is joined, correct?) after the factory default and then reconfiguring the NSS, once it is rejoined all the permissions will be written back.

As for the responsiveness, here is some information we should look at. The following are exerpts of the log file:

Boot Log: (interesting events)

=========  Sun Nov 22 10:46:16 PST 2009 ==========

*** part of log that shows drive initialization ****

ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-8, max UDMA/133, 3907029168 sectors: LBA48 NCQ (depth 0/32)
ata3.00: ata3: dev 0 multi count 0
ata3.00: configured for UDMA/133
scsi3 : sata_promise
ata4: SRST failed (status 0xFF)
ata4: SRST failed (err_mask=0x100)
ata4: softreset failed, retrying in 5 secs
ata4: port is slow to respond, please be patient
ata4: port failed to respond (30 secs)
ata4: COMRESET failed (device not ready)
ata4: hardreset failed, retrying in 5 secs
ata4: port is slow to respond, please be patient
ata4: port failed to respond (30 secs)
ata4: COMRESET failed (device not ready)
ata4: hardreset failed, retrying in 5 secs
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATA-8, max UDMA/133, 3907029168 sectors: LBA48 NCQ (depth 0/32)
ata4.00: ata4: dev 0 multi count 0
ata4.00: configured for UDMA/133
  Vendor: ATA       Model: WDC WD20EADS-00S  Rev: 04.0
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: WDC WD20EADS-00S  Rev: 04.0
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: WDC WD20EADS-00S  Rev: 04.0
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: WDC WD20EADS-00R  Rev: 01.0
  Type:   Direct-Access                      ANSI SCSI revision: 05

*** it had a hard time starting ***

*** below shows RAID is good ***

raid5: measuring checksumming speed
   8regs     :   475.000 MB/sec
   8regs_prefetch:   460.000 MB/sec
   32regs    :   930.000 MB/sec
   32regs_prefetch:   872.000 MB/sec
raid5: using function: 32regs (930.000 MB/sec)
          **************

raid5: device sdc operational as raid disk 0
raid5: device sdd operational as raid disk 3
raid5: device sdb operational as raid disk 2
raid5: device sda operational as raid disk 1
raid5: allocated 4212kB for md0
raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
--- rd:4 wd:4 fd:0
disk 0, o:1, dev:sdc
disk 1, o:1, dev:sda <== un-mounts XFS again at Nov 22 11:17:47 then drive is restarted at 12:40:19
disk 2, o:1, dev:sdb
disk 3, o:1, dev:sdd <== Lazy drive

*** all good ***

*** Interesting part ***

Filesystem "dm-1": Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-1
Ending clean XFS mount for filesystem: dm-1

------------------------------------------------------

the above comes after the raid is mounted and the NSS begins to mount the drives. The part that is interesting is that we see this process again (see the attached screechots and above notes).

The long of it is that it appears we are starting to see HDD problems or the tables are becoming currupt. Take a look at admin logs to see if we are reporting any RAID problems. This may be the cause of slow access and Acronis reporting accessability problems.

One this that is very important is the installation of the Firmware, it has to be installed TWICE back to back to ensure all old data is removed. Have you opened a case with SBSC yet? If not send an IM with contact info so we can get this started.