symbolic link across two drives

[Bin Jiang]

Hi, 

I set up my DNS323 to a "standard" file system ( no RAID 1).  I created symbolic links to folders in the second drive, in order to see them from the first drive. The links work fine in command line, but not when I access them through my PC.  Permission is denied. I've granted full access to the target folder.  Any suggestions on how to fix it?   Also is there any better way to combine two drives to one? Except RAID 0 because I don't want to touch existing files.

Thanks,

Bin

[Joao Cardoso]

On Friday, June 8, 2012 6:53:05 AM UTC+1, jben wrote:

Hi, 

I set up my DNS323 to a "standard" file system ( no RAID 1).  I created symbolic links to folders in the second drive, in order to see them from the first drive. The links work fine in command line, but not when I access them through my PC.

Your PC is using MS-windows?

 

 Permission is denied.

Using samba?

 

I've granted full access to the target folder.  Any suggestions on how to fix it?

You should better describe what you intend to do.

Create a folder /mnt/sda2/data1 and  /mnt/sdb2/data2, creating a link in  /mnt/sda2/data1 that points to  /mnt/sdb2/data2 and then create a samba share on /mnt/sda2/data1? Is that what you intend to do?

Why not create just a samba share for the second drive?

Regarding the symbolic link, you might have to edit /etc/samba/smb.conf and add in the Global section (the first one) or in the specific Share section a directive to allow this. Try one at a time, restarting samba after each modification (using 'rcsmb restart' or just 'rcsmb reload' from the comand line)

You might want to install the samba-doc package, to read the docs, and use 'swat' instead of the command line, hitting the "Advanced" button in the samba web page.

Excerpts from the smb.conf manual page (samba has 261 global (G) options and 132 share (S) options!!!):

       follow symlinks (S)

           This parameter allows the Samba administrator to stop smbd(8) from following symbolic

           links in a particular share. Setting this parameter to no prevents any file or

           directory that is a symbolic link from being followed (the user will get an error).

           This option is very useful to stop users from adding a symbolic link to /etc/passwd in

           their home directory for instance. However it will slow filename lookups down

           slightly.

           This option is enabled (i.e.  smbd will follow symbolic links) by default.

           Default: follow symlinks = yes

       wide links (S)

           This parameter controls whether or not links in the UNIX file system may be followed

           by the server. Links that point to areas within the directory tree exported by the

           server are always allowed; this parameter controls access only to areas that are

           outside the directory tree being exported.

           Note: Turning this parameter on when UNIX extensions are enabled will allow UNIX

           clients to create symbolic links on the share that can point to files or directories

           outside restricted path exported by the share definition. This can cause access to

           areas outside of the share. Due to this problem, this parameter will be automatically

           disabled (with a message in the log file) if the unix extensions option is on.

           See the parameter allow insecure wide links if you wish to change this coupling

           between the two parameters.

           Default: wide links = no

       allow insecure wide links (G)

           In normal operation the option wide links which allows the server to follow symlinks

           outside of a share path is automatically disabled when unix extensions are enabled on

           a Samba server. This is done for security purposes to prevent UNIX clients creating

           symlinks to areas of the server file system that the administrator does not wish to

           export.

           Setting allow insecure wide links to true disables the link between these two

           parameters, removing this protection and allowing a site to configure the server to

           follow symlinks (by setting wide links to "true") even when unix extensions is turned

           on.

           If is not recommended to enable this option unless you fully understand the

           implications of allowing the server to follow symbolic links created by UNIX clients.

           For most normal Samba configurations this would be considered a security hole and

           setting this parameter is not recommended.

           This option was added at the request of sites who had deliberately set Samba up in

           this way and needed to continue supporting this functionality without having to patch

           the Samba code.

           Default: allow insecure wide links = no

      unix extensions (G)

           This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as

           defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by

           supporting features such as symbolic links, hard links, etc... These extensions

           require a similarly enabled client, and are of no current use to Windows clients.

           Note if this parameter is turned on, the wide links parameter will automatically be

           disabled.

           See the parameter allow insecure wide links if you wish to change this coupling

           between the two parameters.

           Default: unix extensions = yes

 

  Also is there any better way to combine two drives to one?

JBOD RAID, Just a Bunch Of Disks. Your two disks will be concatenated and will appear as only one device with a capacity equal to the sum of each disk.

Read the online help in the RAID web page.

I don't like JBOD, but that's just me.

 

Except RAID 0 because I don't want to touch existing files.

If you already have data on both disks, then creating the JBOD might be problematic, as probably only the data on the first RAID component will be preserved -- read a topic about JBOD in this forum, but be aware that the second disk was not in use when the JBOD was created.

 

Thanks,

Bin