Tag Archives: config

Samba vfs_shadow_copy2 annoyance

Posted on by | 2 Replies

The Samba module vfs_shadow_copy2 is useful for shares hosted on snapshot capable filesystems/storage. This module allows previous “snapshot” versions of a share to be made visible to users.  This allows for self-service restore of files by end users. On a given share, in smb.conf, you configure something like

[data]
 vfs objects = acl_xattr btrfs shadow_copy2
 path = /btrfs/samba/data
 shadow:basedir = /btrfs/samba/data
 shadow:snapdir = ../data_SNAPS

Depending on your version of Samba, to use the above which includes the “../” link, you might need to add some/all of the below options:

unix extensions = no
wide links = yes
allow insecure wide links = yes

In the 4.3.x and 4.4.x releases there have been a few changes to the vfs_shadow_copy2 module meaning the above three options may or may not have been needed. The jump from 4.4.9 to 4.4.10 addressed Samba BUG 12531. This again involved changes to the vfs_shadow_copy2 module, again breaking the above config (with or without the three options listed). I’ve changed the above config on the share to be

[data]
 vfs objects = acl_xattr btrfs shadow_copy2
 path = /btrfs/samba/data
 shadow:basedir = /btrfs/samba/data
 shadow:snapdir = /btrfs/samba/data_SNAPS

which works without the three options above. Samba 4.4.13, 4.5.8, 4.6.2 also work with the above. Its frustrating since relative (which I assume includes “../”) directories are supposed to be supported with “shadow:snapdir”. Hopefully this configuration now works for all releases going forward.

I find it frustrating that minor releases can break working configs. It makes it difficult to quickly deploy security fixes as the required level of testing is much higher than one would expect for minor releases. This subtle change to the config option is not documented or mentioned in the release notes.  Anyway, more of a rant post than usual… apologies for that!

FTTC Broadband and MTU

Posted on by | 2 Replies

Just a quick note to remind folks who upgrade to FTTC Broadband that using an MTU of 1500 bytes (Ethernet standard size) is possible if your PPPoE router supports RFC4638 and supports “baby jumbo frames”.

In short – PPPoE needs 8 bytes of each Ethernet frame resulting in an effective MTU of 1492 for the IP layer between your modem/router and the DSL endpoint at your provider. These 8 bytes can be “reclaimed” if your router has the ability to transmit baby jumbo frames up to 1508 bytes excluding Ethernet headers. Andrews and Arnold has a good write up available describing this in further detail along with a specific PPPoE/FTTC page.

If you are using a Cisco router with appropriate hardware you can add something like the following to a working FTTC/PPPoE configuration.

conf t
bba-group pppoe global
tag ppp-max-payload minimum 1492 maximum 1500
int fa 0
mtu 1508
int dialer 0
mtu 1508

The ppp-max-payload min and max defaults are 1492 and 1500 respectively, so all you actually need to do is configure the MTU to 1508 on the FastEthernet 0 (assuming this is your PPPoE interface) and dialer 0 interfaces. Note that even though the Fa0 interface is used to connect to the FTTC modem, you do not appear to need to change its configured MTU size. You can check that it can support frames larger than 1500 by checking the maximum using “mtu ?” in the config mode.

Once these changes are made, you can do “debug ppp negotiation” to track the negotiated options, including the negotiation of a MRU of 1500 bytes. Once this is working correctly you will not need to do any fiddling to get pMTUd working or messing with client MTUs to avoid the inevitable odd browser hangs.

 

UPDATE: Just an FYI, you can check which BT cabinet serves your telephone/postcode along with expected FTTC speed uplift at http://fttc-check.alc.im/ or at http://www.dslchecker.bt.com/

UPDATE2: You do in fact need to set the Fa0 (or what ever your PPPoE interface is) MTU to 1508!