Lewis' Blog Tales from the trenches of information technology

Enabling Extended Attribute support in a Synology DiskStation DS212j

As small NAS devices go, the Synology DiskStation offerings are quite good. On the bang-for-the-buck scale, they rank well near the top, offering a diskless, 2-drive-capacity enclosure for right around $200 street price. I won't go into a litany of features here, and truth be told, Rosenthal & Rosenthal is not a Synology business partner, so I have no great axe to grind insofar as additional sales of these units is concerned. Detailed information on the hardware and software may be found on the net in various places. The focus of this post, however, is on getting support for EAs (extended attributes) on this device.

Extended Attributes

I've set up a couple of these units previously, but I needed to configure this particular one for a pure-OS/2 environment. For those not familiar with OS/2, this operating system makes extensive use of extended attributes for file meta-data. Unlike Windows (which, while supporting EAs as part of the OS/2 and Unix subsystems, does not utilize EAs for common purposes), OS/2 data files are not bound to their extension types in order for the desktop to determine which application should process them. They can be, of course, but it is just as easy to create an Acrobat file with no extension on the name and then set the file type EA to that of an Adobe Acrobat file. Opening the file from the Workplace Shell will properly hand the data off to whichever application has been designated as handling Acrobat files (Lucide, GhostView, Acrobat, etc.).

The problem with EAs, of course, is that once the system in question depends upon them, losing them can lead to a mess. Consider a situation where one has several directories of such Acrobat files, mixed with OpenOffice documents, HTML files, and such, all with varying (or no) extensions, the user instead depending upon the file type EA being set on each one to properly access it. Now imagine transferring those files to a shared storage medium which does not support EAs. In this situation, the meta-data will simply be lost, without warning (it is true that in some cases, such as when transferring files with long names to FAT12 floppies, the Workplace Shell will throw an error advising the user that the long names will be lost, but I've not seen this happen via a network transfer). The resulting situation is that neither the user nor the Workplace Shell knows how to handle each file.

Extended Attributes on the ext4 Filesystem

Spending most of my time in a Novell environment, I tend to take EAs for granted as NetWare volumes (traditioinal and NSS) have supported EAs practically since their inception. However, such is not always the case with Linux filesystems other than NSS or JFS (and even the latter requires kernel support for EAs, as do other *nix-based filesystems).

The DS212j uses ext4 as its native filesystem. While ext4 does support EAs (when the aforementioned kernel support is present), such support must be explicitly enabled at volume mount with the user_xattr option (e.g., -o <otheroptions>,user_xattr<,otheroptions>). On a "normal" Linux box, this is a fairly simple matter of editing /etc/fstab and adding the option, so that each time the volume is mounted, EA support is available.

Unfortunately, embedded Linux devices don't always follow the same set of rules as their full-sized cousins . In the case of the DS212j, editing /etc/fstab simply results in it being overwritten at the next boot. (I believe the volume configuration is stored in a Postgres database, but I frankly haven't taken the time to dig into it - or discover the Postgres user to even modify the db). Luckily, BusyBox (the distro apparently chosen by Synology for their devices - or at least this one) does support /etc/rc.local. By remounting the filesystem from /etc/rc.local with the user_xattr option, we gain EA support for the ext4 volume.

The Single Storage Volume Problem

The main stumbling block to the approach outlined above is that Synology stores (and loads) its Postgres database from the first (or only) storage volume. This makes unmounting and remounting the filesystem somewhat difficult, as the volume is in constant use. (Yes, postgres could be shut down, the volume remounted, and then Postgres brought back up, but as I've stated previously, I don't have all of the information - yet - to take that approach, and as time is of the essence - I really want to be able to ship this device to my client, so that I may bill for it and get paid - I decided to take a different route.)

The answer, then, is to create at least two volumes, with the second one used for shared file storage, and the first one used as a system volume. This allows us to unmount the second volume and remount it from /etc/rc.local without difficulty, adding the following to that file:

umount /volume2
mount -t ext4 -o usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,user_xattr /dev/vg1/volume_2 /volume2

(Don't ask me why the remount option doesn't seem to work on this device, but it doesn't. Thus, an explicit umount followed by mount appears to be required in order to remount the volume with the additional option.)

Enabling Extended Attribute Support in SAMBA

So much for the filesystem itself. The next hurdle is getting the transport mechanism itself (SAMBA, in this case) to properly handle the EAs. Normally, this is a simple matter of adding the "ea support=yes" parameter to smb.conf. However, as I've mentioned previously regarding /etc/fstab, the DS212j recreates /usr/syno/etc/smb.conf at each reboot. Again, we need to turn to /etc/rc.local to append this option to smb.conf and then reload SAMBA to enable it:

echo '        ea support=yes' >> /usr/syno/etc/smb.conf
/usr/syno/etc/rc.d/S80samba.sh reload

In this case, the single SAMBA share is listed last in smb.conf. Of course, we would need to get fancy if we had more than one share to be EA-enabled (or one or more out of several to be enabled), so a simple append statement to add a line to the bottom of the file would be insufficient. In those cases, I might suggest sed for this purpose, but this is beyond the scope of this post. Perhaps I'll expand on that at a later date.

A Matter of Timing

So far, so good. We have EA support enabled for the secondary ext4 volume and we've EA-enabled the SAMBA share. Now the problem is that while processing /etc/rc.local, specifically when we hit the portion concerning appending the "ea support=yes" directive to smb.conf, the system has not yet written smb.conf, thus our change is overwritten before it even gets put into motion. <sigh>

Again, there are likely many other more elegant ways to resolve this (essentially, to look for SAMBA to start up, then make the edit and reload the configuration). However, again, in the interest of "getting things done," I chose the more direct approach, using the sleep command, and inserting a 30 second pause before executing the smb.conf edit and reloading the SAMBA configuration. Thus, the entire /etc/rc.local looks like this:

umount /volume2
mount -t ext4 -o usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,user_xattr /dev/vg1/volume_2 /volume2
sleep 30
echo '        ea support=yes' >> /usr/syno/etc/smb.conf
/usr/syno/etc/rc.d/S80samba.sh reload

and it works.

Interesting EA Side-effects

I notice that now, every single file gets 37 bytes of EAs added to it upon transfer to the SAMBA share, and these 37 bytes are prepended to any existing EAs. This may be a SAMBA bug; I haven't looked closely enough to determine as yet. When I do, I'll add another post about this.

Postscript

I initially contacted Synology support to ask about enabling EAs, and was told that they don't currently ( as of DSM version 4.1-2647) provide this feature, but that if I could give a concise use-case, they would forward my RFE to development. I did indeed provide such a use-case, and received a cordial response from Ryan Kim at tech support that he would pass it along. With any luck, the procedure outlined here won't be necessary at some point in the near future.

Last Updated on April 20th, 2013 by LewisR