Backing up to Asus RT-N56U attached hardrive

[stevech]

Opinion: file system software within a consumer router is not the way to go for a reliable file/backup server.

 

[Guz]

It's just not for backup's. Say you want to copy your music collection that is managed by MediaPlayer up to the USB so it can be shared via UPnP, and you use, say, ROBOCOPY to copy up the files. It will fail, and you're stuck scratching your head and eventually you have an extreme desire to throw the router against the wall.

That being said. Does anyone know how to modify the smb.conf file? I believe all that is needed is the setting:
store dos attributes = yes

The problem I've found is the smb.conf file is dynamically created as soon as a drive is connected, then deleted when you unmount the drive. And even though admin as rw permissions, you can't edit it

 

[NoorE]

where is smb.conf? I've done a search on the entire disc for it, with hidden files and system files toggled to show, and come up with nothing.

can you access smb.conf and edit it through FTP? as i said, I found that you have more permissions if you are accessing through FTP with it set to "share without account"

 

[Guz]

You have to enable Telnet (Administration --> System), then telnet into the router (you need firmware 1.0.1.7c).

From there it's /etc/smb.conf

With a drive connected, it contains:
[global]
workgroup = WORKGROUP
netbios name = RT-56U
server string = RT-56U
log file = /var/log.samba
log level = 0
max log size = 5
security = SHARE
guest ok = yes
guest only = yes
writeable = yes
directory mode = 0777
create mask = 0777
max connections = 5
encrypt passwords = yes
pam password change = no
socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=32768 SO_SNDBUF=32768
obey pam restrictions = no
use spne go = no
client use spnego = no
disable spoolss = yes
host msdfs = no
strict allocate = No
null passwords = yes
unix charset = UTF8
display charset = UTF8
bind interfaces only = yes
interfaces = lo br0 eth3
use sendfile = yes
[AiDisk_a1]
comment = ATCS04-0's AiDisk_a1
path = /media/AiDisk_a1
guest ok = yes
writeable = yes
directory mode = 0777
create mask = 0777

**********************************************************
BE VERY CAREFUL WHEN YOU TELNET INTO THE ROUTER.
You are in a Unix environment, if you don't know what your doing, don't do it **********************************************************

 

[NoorE]

lol, alright, beyond my expertise for sure.

Thanks all for the help on this forum, seems like me and the router have reached an uneasy truce. It will work until Asus can release a more permanent fix. Good luck with whatever else you are trying to do, thanks again, have a good one.

 

[Guz]

I had to resubmit my bug report.. they lost the first one.

I'm at a bit of a crossroads myself. I love how fast it is, as a wireless router. But this USB "feature" is getting to me.

You should be able to copy what-ever files you want, via any valid method available, without issues. i.e. It should just work.

If I can't get a resolution to this, I'm going to return the router and try another brand.

 

[stevech]

the USB file system mode of consumer WiFi routers will probably be unsatisfactory on all brands/models... unless all you want to do is plug in a FAT32 thumb drive and backup or share a relatively small amount of data.

 

[flintbomb]

Why?

Why would it be offered and advertised as a backup solution? I still have never been able to backup reliably although it is a great router in every other respect. USB pretty much not worth using for NAS.

the USB file system mode of consumer WiFi routers will probably be unsatisfactory on all brands/models... unless all you want to do is plug in a FAT32 thumb drive and backup or share a relatively small amount of data.

I am curious as to why you say that?

 

[Guz]

I agree. Especially if you stop and think about NAS appliances. They are essentially a Linux distro, running SAMBA/CIFS, just like this router. Granted, the NAS isn't doing any network routing, but it serves up files without any issues.

Further testing has shown that even if the drive is formatted as EXT3, you will still get access denied errors after trying to copy hidden, system files. Asus is fully aware of this bug now.

I'm slowly setting up a Linux box so I can personally experiment with various SMB settings. But only in my free time, which isn't that plentiful anymore.

 

[Shikami]

I found this to be a curious issue,and decided to test this for myself because I wanted test and perhaps use this feature of the router. I have found that I did not have an issue. I copied multiple files equaling 10GB in size and even one large 7GB with good performance via network share and FTP. Using FTP I created and deleted directories, and the upload automatically created without issue. The same with the network share.

The pop-up window did give a warning that if the AI Disk was not used that other features will not work properly. It advised to use this feature even if you are not to use FTP or the share. I used each individually, and then with AI Disk without issue. The only thing I did not test was FTP over the Internet.

The testing was done with a Maxtor 160GB external USB drive formatted with NTFS. I also streamed to the XBox360 and Windows Media Player without an issue. However, I was a bit perplexed that the ability to share seemed more oriented around network sharing rather than UPnP.

However, I did not get a chance to try a hidden file as of yet. This I will try tonight. If I am correct the issue you have is creating/deleting folders, and copying hidden files correct?

 

[Guz]

I don't know if the issue shows up when using FTP to copy files and set DOS attributes.

 

[Shikami]

I would copy folders and files that were part of the explorer pane in Filezilla to the FTP server. Everything was nominal in its operation. I am still curious what the problem could be for you two. Did you ever read the FTP logs to help ascertain the problem you were having with uploading? Should I try a larger single file or was it mixed with large and small files and still had the issue? Did the account have sufficient permissions for uploading?

To note Guz, I wouldn't call them DOS attributes; they are a file's attributes. So just attributes or file attributes, which are not many in Windows. In Linux it is files system permissions or a files permissions.

 

[Guz]

No, I call them DOS attributes, because that's what they are. Unix really doesn't like them.

DOS attributes are: Read-only, Archive, System, Hidden. Weird little bits that are from days of old, but are still used today in FAT, FAT32, NTFS file systems.

If I remember, FTP ignores the DOS attributes. So you wouldn't see the issue when transferring files this way.

The issue shows itself when you use SMB to copy files.

How to recreate the issue: Find a collection of files/directories on a windows system that has files that have various DOS attributes. I good example is if you use Windows Media player to manage your music collection. It creates a bunch of hidden/system files. Hidden jpg's for album art, desktop.ini files with System/Hidden attributes, etc.

Then use the ROBOCOPY command:
ROBOCOPY "%userprofile%\Music" \\192.168.1.1\AiDisk_a1\share\Music /s

This works in W7, but you need to adjust the source directory per O/S (XP, NT, Vista, Win2003 Server, etc).

Eventually it will error, and you will have permission issues. You will have to unmount the drive, disconnect it, then re-connect it to the router to clear things up (or reboot the router).

I use ROBOCOPY because it has an excessive amount of switches so I could test various scenarios.

Asus is aware of the issue, and have been able to recreate it. They are trying to find a solution.

P.S.
Using the following will avoids the issue:
ROBOCOPY "%userprofile%\Music" \\192.168.1.1\AiDisk_a1\share\Music /S /COPY: DT (remove the space after the colon)
ROBOCOPY "%userprofile%\Music" \\192.168.1.1\AiDisk_a1\share\Music /S /A-:RSH

Only because the /COPY: DT or /A-:RSH says to not copy the DOS attributes.

Other commands will also cause this, when you specify to copy the DOS attributes. Or other backup programs that keep the DOS attributes, example Microsoft SyncToy.

 

[Shikami]

No, I call them DOS attributes, because that's what they are.

This is not only incorrect, but also it is subjective. There is what something truly is, and then there is what a person perceives them as. Attributes are nothing but metadata, which is in relationship to the file system not the operating system. Your semantics imply that you are using DOS to handle file attributes which is, obviously, not as so. Any simple search will show who is actually correct. They are nothing but attributes or permissions-metadata

Now onto the problem. I seriously did not have an issue with my copies that I performed. FTP performed the best, obviously. However, the only issue that I had was the very fact that some files could not be copied over since they were system files and in use. I tried a few permutations (hence the error for a particular file) to see if I could invoke this issue, but I was copying 3.66 GB without issue.

I copied system files and hidden files without a problem. Except for those that are locked, or are in use. This is normal, and operated without a problem. Again, I am curious what is it that you two did to create a problem, and what is it that Asus supposedly acknowledges as an issue? Because , I do not experience one at all.

 

[Guz]

OK, fine. Metadata.

Unix metadata and DOS metadata don't match up. The metadata I'm referring to is commonly referred as "DOS Attributes". An explanation of the differences can be found here: SAMBA File Permissions and Attributes on MS-DOS and Unix Which is where I believe the errors is coming from, the translation and preservation of the "DOS Attributes".

As for recreating the error... see my previous post. I think I gave a rather detailed instructions.

 

[Guz]

As for not being able to recreate the issue via FTP, is because FTP discards the metadata (AKA DOS Attributes). It just transfers the data.

You can see this when you upload a file that has the Read-Only attribute set. Delete the file locally. Then download the file back and check the attributes. You will see that it is no longer marked as Read-Only.

 

[leeishom]

Sorry for being off-topic - After telnet'ing to the unit, how to change Login name?

 

[Shikami]

OK, fine. Metadata.

Unix metadata and DOS metadata don't match up. The metadata I'm referring to is commonly referred as "DOS Attributes". An explanation of the differences can be found here: SAMBA File Permissions and Attributes on MS-DOS and Unix Which is where I believe the errors is coming from, the translation and preservation of the "DOS Attributes".

In the very article you referenced, even the title (q.v. SAMBA File Permissions and Attributes on MS-DOS and Unix), has exactly what I said. Attributes and permissions, which are metadata for the file system. There are no "DOS" attributes, since DOS is the OS and not a files system. Semantically you are saying that the operating system DOS is being used to set attributes. I will use two examples in the publication.

E.g.:

"DOS files, however, have their own attributes that need to be preserved when they are stored in a Unix environment: the archive, system, and hidden bits"

"Figure 5.7 summarizes the Unix permission bits and illustrates how Samba maps those bits to DOS attributes. Note that the group read/write and world read/write bits do not directly translate to a DOS attribute, but they still retain their original Unix definitions on the Samba server."

Note, the latter example as being most important. There is no DOS attribute. DOS is a noun, and attribute is a noun. Multiple nouns are being used to create a distinction (e.g. district school corruption information center or Unix permission bits). DOS is used to make the distinction when talking about the difference with permissions (UNIX) and then attributes (DOS/Windows). So as to prevent ambiguity or confusion.

There are only attributes and permissions. Alone this will advise anyone with a formal education of computers of the possible operating system and file system. Attributes are metadata and metadata is data about data-used to give more information about the file. This includes extensions, and time stamp. It is like a patient file. You have stickers that are used to give the first few characters of the name for organization and identification, then you have a sticker for the full name to identify the patient, you may have a med-alert sticker to advise the nurse, etc. Those simple stickers are metadata because it is data about the data inside the record (file).



The original problem was that a backup could not be performed. Issue(s) with copying a file from multiple users in the forums. Which you then later hypothesized was in relation to attributes and permission.

I was not able to confirm the issue at all with myself,and I have tested this a lot and researched this a lot. Matter of fact as I type this robocopy is copying my whole %userprofile%. However, I do know a little bit more and did make a modification to the syntax. I added the /e switch to copy subfolders properly, and /r:0 so that it will not retry a locked file that are many in the %userprofile%. And, to note, is also full of hidden set bits for many files. The only problem I note is that the attributes are not preserved at all when copied.

Now as for preserving the attributes, I never checked the files afterwords because the copying problem never surfaced for me. However, it could be important that the attributes are preserved, and I did experiment to see if that can happen. Of course the FTP server handles permissions so the bits will not obviously be preserved. When using network sharing the attributes were not preserved. When using robocopy I cannot preserve, nor can I modify. I tried a /copyall to see if all the NTFS information can be preserved, which will error. Trying to preserve with /copy:dat does not perserve but will copy the files fine as before.

I believe the problem is with the NTFS driver, not SAMBA. SAMBA is part of the application and presentation layers and is in part of the execution but is not what is used to write the files. So what do I think you all should do if you want to preserve the attributes? Encapsulate the data.

Use a compression or a backup utility and then copy the files necessary for that backup. Also, this would be better, IMO, to use Windows 7's Backup for it does a full backup first then differential automatically. This not only will lessen time, consolidate the data, but I think will technically resolve the issue till it is actually resolved.

 

[Guz]

Well after 2 months, and 2 custom firmware files. Asus has backed down. We got things somewhat working with an EXT2 formatted drive, but not on FAT32 or NTFS drives. But it lost NTP functionality along the way.

The fun part was I setup a Linux box and was able to get things to work on FAT32 and NTFS perfectly, but not on a EXT2/3/4 formatted drive. Weird. I now know enough about SAMBA to be really dangerous.

So I'm back to 1.0.1.7c firmware, and my old W2k server with the USB drive attached to it, and searching for another router.

 

[Guz]

OOps, I figured out my NTP issue.

If in the WAN settings, you de-select "Connect to DNS Server Automatically", you need to enter a valid DNS server manually (either a local or a remote DNS server).

Live and learn.